问题
The Google App Engine Datastore allows each entity to have a parent entity, essentially a way to form an entity hierarchy. For example, an Employee can be addressed as:
Company#521/Department#5/Employee#3
The entity id is only unique among entities with the same parent, so the full entity path is required to uniquely address it.
So far, so good.
But when should I model a parent-child relationship this way, rather than relying on a basic reference property within an entity, as I would in a traditional database?
The only reason I can think of is to get around the lack of joins in a Datastore query. I can only filter a query using properties from the entity whose kind I am retrieving -- and by any entity that is a parent at any level in the entity's hierarchy.
Any other reason to use this feature?
The Datastore documentation says that entities that belong to the same hierarchy are treated as an entity group, and that entities in the same entity group have serialized write access. What exactly does that mean? Does it mean that if one thread of my app is updating Department#5, another thread that is writing to Employee#3 will have to wait for this update to finish?
Thanks!
回答1:
You should use entity groups only where required to define transactional domains. On App Engine, transactions can only modify entities within a single entity group - that is, entities with the same parent. If you don't need transactional integrity between two entities, they should not be in the same entity group.
If you absolutely need global transactions, you can implement them yourself - see my blog post on the subject for an example. In reality, a relatively small proportion of apps actually need global transactions.
回答2:
A typical usage of Parent feature instead of ReferenceProperties is for transactions.
Google App Engine allows transactions just on entities in the same entity group, ie a set of entities with the same parent.
来源：https://stackoverflow.com/questions/4232816/please-help-me-understand-entity-hierarchies-in-gaes-datastore