4

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!

Tony the Pony
  • 40,327
  • 71
  • 187
  • 281

2 Answers2

3

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.

systempuntoout
  • 71,966
  • 47
  • 171
  • 241
Nick Johnson
  • 100,655
  • 16
  • 128
  • 198
1

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.

systempuntoout
  • 71,966
  • 47
  • 171
  • 241
  • "Google App Engine allows transactions just on entities in the same entity group" -- but what if my app moves money from User A's BankAccount to User B's BankAccount? The 2 entities don't share a parent, but I sure would like them to be in a transaction...?! – Tony the Pony Nov 20 '10 at 16:40
  • @Jen Nothing prevent you to define a common parent model for the different BankAccounts. – systempuntoout Nov 21 '10 at 09:13
  • @systempuntoout That's a terrible idea, and will immediately lead to contention issues. – Nick Johnson Nov 22 '10 at 02:12
  • 1
    Because there is a limit on the rate at which you can update entities in the same entity group. Putting all entities in the same group limits your update rate for all of those entities, which makes scalability pretty much impossible. – Nick Johnson Nov 30 '10 at 01:38
  • @Nick thanks.. so, what you are saying is that we need to avoid transactions among different entities? I thought it was a common transactions use case. I must read your transactions article :). – systempuntoout Dec 01 '10 at 08:19
  • No, I'm saying that you should make entity groups as small as possible - which having one entity group for all accounts emphatically is _not_. – Nick Johnson Dec 02 '10 at 00:21
  • @Nick Ah ok I see the misunderstanding . My advice in using a common parent for the different Models to "enable" transactions was more a general advice than something specific to the Bank accounts. – systempuntoout Dec 03 '10 at 13:43