Using parent child relationship where a parent can have children while each child has only one parent, does using Children.all().ancestor(parent.key) a good solution where a child is constructed by setting parent=parent.key in the constructor? Is the 1000 limit applies with this kind of query?
views:
75answers:
1
A:
The query returns what you'd expect, all Children which have the specified parent anywhere in their ancestry. The query expresses exactly that, so I doubt there's a simpler way of doing the same thing. But App Engine does keep adding features and surprising me :-)
Possibly you need parent.key(), I think it depends whether you're in Python or Java.
Btw, it's not recommended to use ancestor-parent-child to model relationships in your data. Entity groups exist to enable transactions, not for use as a "free" ReferenceProperty. parent-child should be a low-level implementation detail, meaning either "these two entities may need to be modified in a single transaction", or perhaps "I am playing an optimization trick which allows me to use list properties without having to load the list into memory when I get the entity". As a rule of thumb, if the entities don't all "belong" to the same user, then they shouldn't be parent-child related, because relating them in that way introduces contention when different users try modify them via different datastore nodes:
Steve Jessop
2010-03-25 12:40:08
This talk gives a different perspective on your entity group rule of thumb with 'relational index entities': http://code.google.com/events/io/2009/sessions/BuildingScalableComplexApps.html but I do understand your design philosophy.
dar
2010-03-25 15:02:26
Yes, relation index entities are what I characterised as "an optimization trick to use list properties". I guess an ancestor filter is the natural way to find all the index entities for a given Message (or whatever), knowing that your hierarchy is only one level deep anyway?
Steve Jessop
2010-03-25 17:32:32
using the list properties, is it possible to create a list of not just strings but a list of entities?Like in java`Class Message{` `Long id;`` List<Users> users;``}``Class Users{`` Long id;`` String userName;``.... ``}`
M.A. Cape
2010-03-26 01:38:52
No, list types must be one of the datastore value types: http://code.google.com/appengine/docs/java/datastore/dataclasses.html#Core_Value_Types. You can have a list of keys, or a list of Google account users, but not a list of your own User entity.
Steve Jessop
2010-03-26 02:27:04
just some clarification, when you said "As a rule of thumb, if the entities don't all "belong" to the same user, then they shouldn't be parent-child related,..." do you mean that in order to use ancestor-parent-child, all entity B should belong to one and only parent entity A and the parent entity A should be one and only of its kind?...... or I could have different instance of entity A that has its "own" entity B.
M.A. Cape
2010-03-26 08:06:34
No, by "user" I mean what Google means in the link I gave, a human user of your app. It's not compulsory, but bear in mind that the way GAE distributes apps is to run them simultaneously on multiple nodes, migrate data around as needed, and use optimistic locking. Putting objects in the same entity group "ties them together", so that they share a lock, and that's how transactions can work. This limits how far your app can scale, and the whole point of GAE is to scale apps. A user is a good rule of thumb, because one user doesn't normally access the app from different nodes simultaneously.
Steve Jessop
2010-03-26 16:17:05
...so yes, you can (and should) have multiple A's each owning one or more B's. Just don't give all the A's a common parent, because if you do then every A and every B will all be in the same entity group.
Steve Jessop
2010-03-26 16:41:52