ancestor vs ReferenceProperty

[Emmanuel Mayssat]

I am having difficulties understanding the benefits of using ancestors for an object.

What is the difference with using instead a ReferenceProperty called _parent ?

--

Emmanuel

[Igor Kharin]

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.