views:

299

answers:

2

From what I understand, the parent attribute of a db.Model (typically defined/passed in the constructor call) allows you to define hierarchies in your data models. As a result, this increases the size of the entity group. However, it's not very clear to me why we would want to do that. Is this strictly for ACID compliance? I would like to see scenarios where each is best suited or more appropriate.

+2  A: 

The only purpose of entity groups (defined by the parent attribute) is to enable transactions among different entities. If you don't need the transactions, don't use the entity group relationships.

I suggest you re-reading the Keys and Entity Groups section of the docs, it took me quite a few reads to grasp the idea.

Also watch these talks, among other things they discuss transactions and entity groups:

Alexander Kojevnikov
Thanks for the links.
JamesC
+4  A: 

There are several differences:

  • All entities with the same ancestor are in the same entity group. Transactions can only affect entities inside a single entity group.
  • All writes to a single entity group are serialized, so throughput is limited.
  • The parent entity is set on creation and is fixed. References can be changed at any time.
  • With reference properties, you can only query for direct relationships, but with parent properties you can use the .ancestor() filter to find everything (directly or indirectly) descended from a given ancestor.
  • Each entity has only a single parent, but can have multiple reference properties.
Nick Johnson
Worth also noting that you can create entities with the same parent key, even if that parent doesn't actually exist, so you can put things in the same group even without specifying one of them to be the parent. I can't say I can think of a good reason to do this though!
Danny Tuppeny