12

I have been playing around with google app engine and its datastore recently and created a datamodel and relationships using reference properties.

However I am unclear about the concept of ancestors wrt the datastore. What is their purpose and why should I use them? How do they relate to reference properties of datastore entities?

Dan McGrath
  • 41,220
  • 11
  • 99
  • 130
deltanine
  • 1,166
  • 1
  • 13
  • 25
  • 2
    Do these help? [here](http://stackoverflow.com/questions/1011814/storing-hierarchical-data-in-google-app-engine-datastore) and [here](http://stackoverflow.com/questions/2490261/what-does-ancestor-mean-in-the-google-app-engine-datastore) – StuartLC Oct 11 '12 at 05:34
  • 1
    The second link was illuminating. "Transactions in GAE only exist within ancestor-descendant groups." So, it seems if I want to use transactions then I should care about ancestors. My noodlings in GAE datastore are not quite so advanced yet, but it's good to know! – deltanine Oct 11 '12 at 09:57

3 Answers3

17

Another benefit of entity groups/ancestors is to create islands of strong consistency (as opposed to eventual consistency).

For instance, you could have a project and its tasks. Without ancestors, you could 'close' a task, go back to the tasks list screen for the project, and do a query for open tasks. The task you just closed could still show up because of eventual consistency. The query may have been resolved against a server where the update still hasn't been replicated.

However, with ancestors you get strong consistency. So, instead of a simple foreign key from task to project, you make the the project the ancestor for the project tasks. Now, when querying for tasks, you make it an ancestor query by also providing the project key. The result will be strongly consistent and the task you just closed won't ever be part of the result.

Starman
  • 426
  • 3
  • 6
  • 2
    Note that using ancestors is not enough to ensure consistency. you must also use transactions where appropriate... – epeleg Jan 08 '14 at 11:20
  • Please note, as of 2019, Datastore has been upgraded to 'Firestore in Datastore mode` and some of these constraints listed here are no longer there. Datastore now can support strong consistency for all types of queries. https://cloud.google.com/datastore/docs/firestore-or-datastore#in_datastore_mode – user482594 Jul 03 '19 at 10:25
9

The example usually used is an author and their books.

Each book is stored in the datastore as a separate entity, with it's name and it's author stored as fields in the model.

If you want to know all books by a single author, you can run a query such that

book.author == desired_author

But with ancestors you can also save each book and set a model (a new author model) to be it's parent (it's ancestor).

So now you can simply say "show me all books that have this author as parent".

Or rather "show me all children of this ancestor" and all books by that author are returned.

It might not seem that useful in this example, but if you imagine instead of "author" you have "user" and instead of "book" you have "message board message" and tens of thousands of messages and suddenly it becomes very handy to be able to find all messages by user (e.g. show me my own messages).

https://developers.google.com/appengine/docs/python/datastore/queryclass#Query_ancestor

ancestor (ancestor)
Adds an ancestor filter to the query. The query will return only entities with the specified ancestor.

There are also benefits in costs for finding each record I expect.

Paul Collingwood
  • 9,053
  • 3
  • 23
  • 36
2

Providing an ancestor makes your (new) entity part of the same entitygroup as the ancestor provided. Hence all entities with a common root entity as an ancestor get stored in the same datastore node, this 'locality' permits numerous actions to be performed on all these entities (in the same entitygroup) all within a transaction. Then to any query which contains an ancestor query (such as only return entities which are children the common root entity) , these actions will appear to occur simultaniously (atomically) or not at all.

Ref: http://www2.mta.ac.il/~kirsh/download/MTA%20NoSQL%20Seminar/Lectures/GAE.pdf

andrew pate
  • 3,833
  • 36
  • 28