I think there are solutions that will make email addresses work as unique keys: one way is to create additional entities that act as pointers to the original emails. This is a "lazy engineering" way of solving the problem and assumes a very small percentage of changes. One of the reasons this type of solution can work is because if you change email addresses, it is very, very, very unlikely someone will want to take your old email address, so you can, essentially, let an email address live on in your system forever and just have N new emails pointing to the "canonical" email created for your user. It's also nice because it's a system that can more or less be tacked on with minimal changes to existing code, so as long as you wrap your lookup code correctly. The tradeoffs here are that this can create a world of bugs depending on how you use emails, but I don't think it's anything solid testing can't minimize the impact of.
I saw an earlier post in this thread about my solution being the "Google recommended way" and I want to clear any misconceptions that the "Ikai Lan way" is a "Google way". I believe in favoring immediate problems over potential directions your software can take simply because you really can't know where your project will go in the future. Backwards compatibility and filling holes created by early design decisions are just something that'll happen no matter what, and it's up to you to judge what's worth eager solving and what isn't. I think that's one of the best things that comes with experience: learning how to not overdo things. -- Ikai Lan Developer Programs Engineer, Google App Engine Blogger: http://googleappengine.blogspot.com Reddit: http://www.reddit.com/r/appengine Twitter: http://twitter.com/app_engine On Thu, Feb 3, 2011 at 4:59 AM, Jeff Schwartz <[email protected]>wrote: > Hi Ikai, > > While an email address can be considered a natural key it is still subject > to change and more frequently than you suspect I am afraid. Take changes in > internet service providers for example - I have done so twice in the last 4 > years and those in my small circle of friends (I am mostly a hermit lol) the > frequency is even higher due to Verizon's gradual introduction of FIOS into > the NYC/metropolitan area. > > Therefore I respectfully disagree with your assertion that this is more of > an edge case. I would be more inclined to agree with you had you said that > email changes fall into corner cases but even here I believe corner cases > need to be addressed. In short I believe that there are many better options > than email addresses for keys including synthetic keys (auto generated, for > example) that will guarantee stability and uniqueness. > > BTW, thank you and the rest of the Googlers for your great support and > contribution to this group. I've greatly enjoyed reading you here. > > Jeff > > > > > > On Wed, Feb 2, 2011 at 5:14 PM, Ikai Lan (Google) < > [email protected]> wrote: > >> That sounds like an edge case to me that you'd be overengineering for >> unless you had a specific use case. How often have you changed your email >> address? I think the last time I changed mine was when Gmail launched in ... >> 2003? 2004? The only exception is if you are building something business >> related and you need work emails - those will change each time you change a >> job. >> >> -- >> Ikai Lan >> Developer Programs Engineer, Google App Engine >> Blogger: http://googleappengine.blogspot.com >> Reddit: http://www.reddit.com/r/appengine >> Twitter: http://twitter.com/app_engine >> >> >> >> On Wed, Feb 2, 2011 at 1:21 PM, Jeff Schwartz <[email protected]>wrote: >> >>> If the user changes their email address then all entities using it as >>> their part of their key would have to be deleted from the datastore (you can >>> not update an entities ID) and then saved again using their new email >>> address. That's doable but very expensive and IMHO something to be avoided >>> at all costs and I'd look to use something else. >>> >>> >>> On Wed, Feb 2, 2011 at 2:34 PM, Robert Kluin <[email protected]>wrote: >>> >>>> No but to implement a unique constraint, I find key_names are usually >>>> the easiest way. But you're right, the email can change so he might >>>> need to add a second kind used to track the uniqueness of that field. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> On Wed, Feb 2, 2011 at 12:58, Jeff Schwartz <[email protected]> >>>> wrote: >>>> > Since email addresses can change it isn't a good idea to use them in >>>> an >>>> > entity's id. >>>> > >>>> > On Feb 2, 2011 12:41 PM, "dudu" <[email protected]> wrote: >>>> >> No solution folks? Any idea? >>>> >> How do you configure your unique fields? >>>> >> >>>> >> How can I use the email property to be part of the "Key". >>>> >> If is generated by* IDENTITY strategy*, do I need to interfere? >>>> >> >>>> >> Could someone just post some working code with a Key, and some unique >>>> >> fields? >>>> >> >>>> >> -- >>>> >> 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. >>>> > >>>> >>>> -- >>>> 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. >>>> >>>> >>> >>> >>> -- >>> *Jeff Schwartz* >>> >>> -- >>> 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. >> > > > > -- > *Jeff Schwartz* > > -- > 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.
