Make sure you understand the concepts of natural vs synthetic keys. Then, you may also consider using a String instead of a Long as your synthetic primary keys.
Using the string representation of a UUID as a synthetic key will also allow you to do things like you mentionnned, eg creating relation before you commit a new entity. If you are willing to forgo a little in terms of performance and storage, UUIDs are great. Other advantages include: - no collisions on import/merge of schema data - no need to reserve ids to store sourcing data - secure urls as those uuids cannot be guessed - ids can be generared at the service layer instead of relying on the datastore - more portable externally as a datastore agnostic pk representation. You don't want the caller to have to know about a GAE Key. - the namespace and parent hierarcky (entity groups) can be encoded in the string key R. On Jun 2, 12:06 pm, Jeff Schnitzer <[email protected]> wrote: > This is the classic "synthetic key vs natural key" debate, and the > general consensus is that synthetic keys are almost always the way to > go. For exactly the reasons you describe. Yup, I think you answered > your own question :-) > > Jeff > > > > On Thu, Jun 2, 2011 at 4:21 AM, Drew Spencer <[email protected]> wrote: > > Hi coders, > > I have a little quandary here - I'm in the early stages of developing an app > > that in essence, manages the details of companies. The 'main' objects as it > > were, are accounts (ie a client of ours - it's a bit like a CRM system) > > I decided to use the company name as the unique ID, but now this is causing > > problems for when I want to change the name of the company (this does happen > > quite a lot). > > I have been modifying Chris Ramsdale's Contacts MVP tutorial with some > > success over the last couple of days, but I find that when I try to update a > > contact by changing the company name or phone number, it simply adds in a > > new one and leaves the old one there (because the IDs are different the put > > doesn't overwrite the old one, whereas if they both had the same Long ID > > they could have different details on the name and phoneNumber fields but > > still the same unique identifier (@Id)). > > Now I COULD hack it and pass in the old account name, delete that one and > > create a new account, but that seems like it's going to cause all manner of > > problems. > > Anyone got any suggestions, or am I answering my own question here? Long IDs > > seem the way to go, but I like the fact that when I use my company name > > string I don't have to perform a put() before I start adding lists of keys > > to it, or is this just a minor thing? > > Thanks > > > -- > > You received this message because you are subscribed to the Google Groups > > "Google App Engine for Java" group. > > To view this discussion on the web visit > >https://groups.google.com/d/msg/google-appengine-java/-/UVJrWjhNODVqdW9K. > > 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-java?hl=en. -- You received this message because you are subscribed to the Google Groups "Google App Engine for Java" 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-java?hl=en.
