Why does the webapp2 auth model use a unique table?

I am implementing webapp2 auth in my codebase and wanted to understand this quirk:

In models.py , I can see that it indicates:

To ensure that properties are unique when creating a new one User

, we first create      Unique

entries for those properties, and if all goes well, we can save the new entry User


It seems to me that this is a very difficult way of testing for uniqueness and to be honest, I don't quite understand what the "create_multi" function does .... what could be, that's why I'm a little confused here, My thought process:

Just do a quick query to see if the username (auth.id) exists in the datastore. If not, then put ().

I know I am missing something, can someone please explain this to me? I have a suspicion that perhaps the code was put in there to make it easy if people wanted to have a few unique features?


ps Apparently the webapp2 code was inspired by this piece of code .


source to share

1 answer

This model has two unique values: username and auth_id.

So, since all users do not belong to the same entity group, we cannot check for uniqueness using transactions. And that's why there is a unique model: to ensure that these two properties are unique.

I agree, it's very difficult. But how else do you do it? (honest question)

Update more about why uniqueness is checked this way.

There are only two ways to (safely) enforce a unique datastore constraint: transactions or using an entity key. Transactions are limited to 5 entity groups, and using a key, you are limited to one unique property. If you don't want to use a key (because, say, a property might be mutable, for example by email), or you really need more unique properties for the same, you need to create a specialized view just for uniqueness checks. More or less what is being done there in the link you posted.



All Articles