Also keep in mind that you can't change parent property after you create an object.
On 19 July 2010 13:26, Blixt <[email protected]> wrote: > Thanks Nick. > > The reason I use entity groups is not for any kind of performance > reasons – I really need to make sure that the Parent entity is updated > in combination with a Child entity being added, and the values being > set are related to the order of entity insertions, so entity groups > feel like the right thing to do to ensure data atomicity. > > My only thought is that I'd rather add redundancy (by adding a > ReferenceProperty that can be inferred from the key) than lose > performance. If the performance difference is negligible however, I'd > rather not add an unnecessary property. > > /Blixt > > On Jul 19, 1:21 pm, "Nick Johnson (Google)" <[email protected]> > wrote: > > Hi Blixt, > > > > > > > > > > > > On Mon, Jul 19, 2010 at 12:15 PM, Blixt <[email protected]> wrote: > > > Imagine the following models: > > > > > class Parent(db.Model): > > > name = db.StringProperty() > > > count = db.IntegerProperty() > > > > > class Child(db.Model): > > > number = db.IntegerProperty() > > > value = db.StringProperty() > > > > > Whenever a new Child is added, it is added with a Parent as its parent > > > entity in a transaction which also updates some values on the Parent. > > > > > My question is this: To get a list of children that belongs to a > > > Parent, is it more efficient to add a ReferenceProperty to the Child > > > model and filter by that, than it is to use the ancestor filter in > > > queries? > > > > > To clarify in code: > > > > > # Using ancestor > > > Child.all().ancestor(parent_key).fetch(10) > > > # Using filter on a new ReferenceProperty called 'my_parent' > > > Child.all().filter('my_parent', parent_key).fetch(10) > > > > These two should have roughly the same performance. > > > > Bear in mind, though, that if you don't need entity groups for > transaction > > purposes, you should avoid using ancestor relationships. Given that, the > > second approach is a better one - just not for query performance reasons. > > > > -Nick Johnson > > > > > > > > > -- > > > You received this message because you are subscribed to the Google > Groups > > > "Google App Engine" group. > > > To post to this group, send email to [email protected] > . > > > To unsubscribe from this group, send email to > > > [email protected]<google-appengine%[email protected]><google-appengine%2Bunsubscrib > [email protected]> > > > . > > > For more options, visit this group at > > >http://groups.google.com/group/google-appengine?hl=en. > > > > -- > > Nick Johnson, Developer Programs Engineer, App Engine Google Ireland Ltd. > :: > > Registered in Dublin, Ireland, Registration Number: 368047 > > Google Ireland Ltd. :: Registered in Dublin, Ireland, Registration > Number: > > 368047 > > -- > You received this message because you are subscribed to the Google Groups > "Google App Engine" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]<google-appengine%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/google-appengine?hl=en. > > -- *— Vladimir Prudnikov, ToBeeDo* -- You received this message because you are subscribed to the Google Groups "Google App Engine" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.
