Best rule of thumb is "never form child-ancestor relationships if you don't have a strong need to." (and understand why you need it)
They are not interchangeable. Use ReferenceProperty or better yet just ID's as either strings or integers as they are shorter/smaller than Keys and easier to use in case of schema migration. What are benefits? Well, each entity in Datastore has it's own path, or a Key. Path is roughly comprised of AppID/KindName/EntityID. What we need to know here is that entities are obviously sharded across different machines (based on its path), so your entities may be really lying on different servers. When you put an entity with ID '1000' and ancestor 'foo' its path would be: AppID/KindName/foo+1000 Consequences are: 1. Entity's ID is no longer '1000' but '1000' with ancestor 'foo', so you can't db.get() it solely by its ID--you have to know its ancestor. 2. All entities with ancestor 'foo' would end up saved somewhere near, most likely on the same server. That's why ancestors are used (or even useful) for transactions and strong consistency across HR Datastore. In terms of documentation, entities that share the same ancestor are called entity group. Entity groups are useful for faster/parallizeable writes, strong consistency and transactions, but you have to keep them small. Also, ancestor may be anything really, not just some real entity in the Datastore. -- 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.
