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
, we first create
entries for those properties, and if all goes well, we can save the new entry
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
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.
source to share