@Anthony Very nice method that seems to work better than storing the hierarchy in a string. I'll have to look into that.
@Marzia Thanks for the advice =) It doesn't suit my particular use case, since my layout displays nested comments that are ~10-20 deep, but I'm sure many people will find the lazy-loading style useful. @Steve I've been experimenting with pickling a highly nested tree. Seems like I ran into a problem with the recursion limit in the pickle module. The way I solved this was to flatten the tree, however, you could also use a patched pickle which uses generators instead of recursion. It's posted at: http://gist.github.com/22217 On Nov 1, 7:31 am, "Steve Schwarz" <[EMAIL PROTECTED]> wrote: > On Fri, Oct 31, 2008 at 5:41 PM, Chris Tan <[EMAIL PROTECTED]> wrote: > > > Hi Steve, > > > I was thinking along the same lines. Having the root comment or > > thread hold a > > cache of the whole tree, which would be updated whenever an entity is > > updated, added > > or removed seems like the most efficient way for large hierarchies. > > > You could have your cached tree represented using nested dictionary > > objects on your root > > object using a PickleProperty (see: > >http://groups.google.com/group/google-appengine/msg/8433525107a8bb92) > > to be converted to XML as required. > > > The comment class could have a path property (e.g. "id1/id2/id3") > > which could be > > quickly traversed to retrieve or update child comments. Since it > > doesn't need to be indexed, > > it can be a TextProperty() which isn't limited to 500 bytes. > > > CRUD operations could be overridden in your Model class: > > > class Comment(db.Model): > > path = TextProperty() > > def put(self): > > # update root comment > > super(Comment, self).save() > > > def delete(self): > > # update root comment > > super(Comment, self).delete() > > > Pros: > > - Reads only need to fetch 1 (root tree) or 2 entities (look-up child > > path & return sub-tree from root) > > - Not limited by depth > > > Cons: > > - Writes update 2 entities. > > - Pickling/Unpickling could be resource intensive > > Chris, > Now that I've read Marzia's comments and rewatched the video the saving > grace for a comment system where you get "too many" comments to grab in one > go you could switch to paging. Whatever the GAE limiting factor is once you > near it you could introduce paging to keep each request under the limit. If > that was 200 or 1000 comments would anyone really want to scroll through > them all on a single page? > > On the other hand if you are providing a data feed or a big XML doc like I'm > contemplating then getting only a portion of the data wouldn't be useable. > But now that I think of it there is no reason the tree couldn't be > partitioned and at the cost of some additional gets (which could be cached) > this becomes as sharded assembly of the larger XML document. Just like > comments could be put in entity groups based on user, I could split the XML > doc based on the values of a discriminant attribute and work with smaller > entity groups. The assembly of those entities into the final document would > involve a relatively small number of gets (a couple dozen). I'll have to > look into pickling vs. storing XML fragments from a speed/space tradeoff > perspective. > > Thanks for your assistance, > Steve --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
