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 -~----------~----~----~----~------~----~------~--~---
