Use two kinds, one for the actual user info and the other for the uniqueness check. Implement 'cross entity group transactions' using some type of 'roll-forward' semantics so that you can continue creating / updating the proper user entity should an error occur.
Robert On Mon, Jan 24, 2011 at 19:59, Dave Peck <[email protected]> wrote: > I have a User model and I've placed the email address in the key_name. > This makes it easy to ensure uniqueness without race conditions. > > _Changing_ emails becomes a problem. It involves creating a new > account and switching all references. Which makes me wonder if the > email address really should be key. > > How have others approached this simple problem? You want transactions > on all sides if you can get them... > > Cheers, > Dave > > -- > You received this message because you are subscribed to the Google Groups > "Google App Engine" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/google-appengine?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Google App Engine" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.
