Sounds like you pretty much understand the parameters of the problem. The key bits of experience-derived information you're missing:
* Due to eventual consistency of queries on the HRD, parented entities are much more useful than they were before, so you will use them quite a bit. * Once your data model reaches a certain complexity, passing around a series of Longs to represent a key becomes very difficult to maintain. I have done this both ways; in apps with an unsophisticated data model and minimal use of parented entities, using Long ids works fine. On the other hand, my latest project has a enormously complicated data model with heavy use of parents to guarantee query consistency and keep 2pc transactions to a minimum. This app would be wholly unmanageable (for me at least) without heavy use of Objectify's generic-typed Key<?>. So I have Key<Person>, Key<Organization>, and dozens more like that. The typechecker is my best friend. Jeff On Tue, Jan 24, 2012 at 10:06 AM, AndyD <[email protected]> wrote: > What are the pros/cons of using the datastore native "key" property type for > storing a reference to another entity, vs. using the Long property type to > hold the other object's ID? > > A few differences come to mind immediately, but I'm not sure if they're > significant. > > keys are longer and take up more space on disk, in memory, on the wire, etc. > With Long properties, whenever you want to fetch the related object, you > first need to generate its Key using a KeyFactory. I haven't timed it, but > my assumption is that the key generation performance overhead is trivial, > since it's just a string formatting exercise. > With Long properties, if the referenced object is parented and the parent ID > of the referenced object is not implied or otherwise available from context > (e.g. known to be the same parent as the referencing object), it would be > necessary for the referencing object to store the parent ID of the > referenced object also. So in that case, two properties would be needed > instead of one. Is that significant (assuming they're not indexed)? > > In all my use cases, I know the type of the related object (and thus its > kind), so generating the key is trivial and can be pushed out of sight into > helper methods in base classes, so I'm not concerned about the boilerplate. > Parented object references don't seem to present a problem, either, since > you could just as easily store the parent Id in a Long field also, if it is > not implied by the context of the referencing object. > > In a nutshell, it seems to me that a Key is just a formatted string that > encapsulates the reference information, but there's no magic there. > > Are there benefits to using the Key property type that I'm overlooking? > > -AndyD > > P.S. some other discussion on this subject: > http://stackoverflow.com/questions/5312904/key-or-long-for-id-in-google-app-engine-jdo > http://stackoverflow.com/questions/5553702/app-engine-identifier-key-vs-id > > -- > You received this message because you are subscribed to the Google Groups > "Google App Engine" group. > To view this discussion on the web visit > https://groups.google.com/d/msg/google-appengine/-/d-OUIqZ7ua0J. > 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.
