When evaluating using email addresses as keys I have to weight the pros and cons. When I evaluate your approach verses avoiding using email addresses as keys altogether my brain is wired to avoid their use in favor of a solution that provides an immutable value, one that wont require cascading deletes and cascading writes when an email address changes.
I guess we will have to agree to disagree on this one. Jeff On Thu, Feb 3, 2011 at 1:43 PM, Ikai Lan (Google) <[email protected]<ikai.l%[email protected]> > wrote: > 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] <ikai.l%[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]<google-appengine%[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]<google-appengine%[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]<google-appengine%[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]<google-appengine%[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]<google-appengine%[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]<google-appengine%[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]<google-appengine%[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.
