datastore: key properties vs. Long ID properties for storing references to other entities

[AndyD]

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.

1. keys are longer and take up more space on disk, in memory, on the wire, etc.
2. 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.
3. 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 

[Jeff Schnitzer]

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

> --
> 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 google-a...@googlegroups.com.
> To unsubscribe from this group, send email to
> google-appengi...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/google-appengine?hl=en.