Re: storing and rendering comment threads

[Anthony]

You could use ancestors & entity groups to maintain your threading,
not sure how this would impact the overall performance but it makes
querying for children easy. But, this would mean a query with the root
comment as ancestor would pull back all children and all the
children's children etc.. you might not want this so might want to
maintain a depth count and add it to the query maybe?


Or, stick with the lexical path but use the full byte rather than
decimal to store the number.. then just 2 bytes give you a max of 64k
comments per depth and 200+ deep.




On Oct 18, 10:07 pm, jeremy <jeremy.a...@gmail.com> wrote:
> How would "you" approach storing and rendering comments in a reddit
> like forum? The naive approach i think would be to store comments with
> references to their parent comment, then recursively build the forum
> tree by retrieving children. I'm sure that would timeout for larger
> threads.
>
> One interesting alternative i found was here:http://github.com/DocSavage/bloog/tree/master/models/blog.py#L137
> basically each comment stores it's "genealogy" in a string, making
> comments lexically orderable. But that has a number of limitations -
> the genealogy string is limited to 500 bytes so there's suddenly a
> maximum thread depth, and the ids may exceed the fixed size padded
> space.
>
> At first i thought i could solve this by using list properties to
> encode the genealogy - then i realized that datastore lists have weird
> set-like sorting :\ .. Not sure whether i can salvage this approach.
> Can custom properties define their own sorting rules?
>
> Any suggestions/insights would be great.

[jeremy]

hmm, some how it didn't occur to me that the string could be treated
as 500 raw bytes. thanks for pointing that out!