views:

35

answers:

2

Assumptions: 1) Google AppEngine has the concept of Entity Groups. 2) Entities in an entity group form a tree. However, as far as I understood, every put() to any entity in that tree will lock the whole tree (not just the immediate parent) for a while. 3) Users are allowed to write ca. 5 times per seconds to the tree. 4) There is no way to have a non-locking behaviour (i.e. by making them unindexed properties)

Would it be a smart idea to come up with my own parent-child model that does not use the built-in Key-functions (as those would create entity groups) but instead use some snytax convetions that I made up? This would allow me to retrieve a "child" entity via a query an compute the parent key.

+1  A: 

You can use a reference property:

class Parent(db.Model):
    x = db.IntegerProperty()

class Child(db.Model):
    parent = db.ReferenceProperty(
        reference_class = Parent, 
        collection_name = 'children')
    y = db.IntegerProperty()
Saxon Druce
Sorry, I am from the Java world using only the low-level API. I have some trouble translating your Python example. Essentially, you would give "Parent" and "child" entities an additional key number (x and y). And you store in each parent a list of its children? That would not scale beyond 5000 children.
xamde
Why do you introduce new identifiers (x and y) or are these just examples for some kind of data within your example entities?
xamde
Storing an ID of the parent in each child would scale better but still suffer from some concurrency issues (datastore and indexes not updated in one atomic operation, resulting in sometimes stuff in datastore and not in index as well as stuff in index but not in datastore).
xamde
@xamde: Yes, x and y were just to show data stored on those classes. Also I was assuming that the parent and child classes would be of different types, so the structure is only 2 levels deep. Or do you have a general hierarchy of entities, which could be any number of levels deep? The general idea though was for each item to store a single reference to its parent.
Saxon Druce
@Saxon Thanks for explaining. I guess this is the smartest solution if you need to ask the parent for all of its children - which is possible in your code via a query.
xamde
+1  A: 

The ancestor relationship used by entity groups can be modeled in your own code by using a list of references/keys to parent entities. Root entities will have none, children of roots will have just the root entity in their list, their children will have the root and their immediate parent, and so forth. This is how ancestors are implemented in App Engine for indexing purposes, and it'll permit you to make the same sorts of queries.

Nick Johnson
@Nick Could I improve your suggestion by putting additionally a structure in the way I create my key names? I.e. encoding the parent-path right into the key name itself? Is this idea smart or bad?
xamde
You could do that, yes. As long as you use a suitable delimiter, you could then do range requests on a range of key names to find everything with a given ancestor.
Nick Johnson
xamde
@xamde That bug has been fixed for a while now.
Nick Johnson