incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Lennart Melzer <l.mel...@tu-bs.de>
Subject Re: Comment tree design in CouchDB?
Date Tue, 24 Nov 2009 12:48:16 GMT
I'm having difficulties with your approach when trying to build a tree of Documents.

I want to be able to represent some kind of threaded view upon documents, where each branch
is sorted by the creation date.

currently I am storing the hierarchy in the descends_from field of a document. It contains
the uuids of the posts this document descends from. The problem (as you already pointed out)
is that i cannot use these uuids as keys for a view, since it will not order them correctly
(by a timestamp), but lexicographically by their id.

Right now I can either have those documents sorted by their creation date, or hierarchically
correct, but not both.

I don't want to use incrementing ids, since I'd like to stick with the uuids ( or at least
with ids, that do not tell anything about the ordering).

What I thought about is to use the uuids and the creation date of each parent as the key (this
is bloat, i know)
Something like

["root_id","timestamp of the first level","first_level_id","timestamp of the second level",
"second_level_id"....]

So if C was created today and C descends from B and B has been created yesterday and B descends
from A, then the key in a view-row for A's children should look like
[A,yesterday,B,today,C]


that way the resulting rows would be hierarchically correct and each branch sorted by timestamps.
The problem would be to store the data for producing such complex keys inside each document
and still keep them in the correct order.

Any suggestions on how to solve this? Perhaps I really think way to complex, or there's something
wrong with the view logic I am thinking of.

Greetings,

Lennart
On Nov 18, 2009, at 12:23 PM, Patrick Barnes wrote:

> I would suggest that each comment has a 'hierarchy' attribute, like an OID...
> For instance: ('.'s for padding)
> [
> {"hierarchy":[1], "id":1, "data":"foo"}
> ...{"hierarchy":[1,2], "id":2, "data":"foo"}
> ...{"hierarchy":[1,3], "id":3, "data":"foo"}
> ......{"hierarchy":[1,3,5], "id":5, "data":"foo"}
> ......{"hierarchy":[1,3,16], "id":16, "data":"foo"}
> {"hierarchy":[4], "id":4, "data":"foo"}
> ...{"hierarchy":[4,6], "id":6, "data":"foo"}
> ......{"hierarchy":[4,6,8], "id":8, "data":"foo"}
> ...{"hierarchy":[4,7], "id":7, "data":"foo"}
> ......{"hierarchy":[4,7,9], "id":9, "data":"foo"}
> .........{"hierarchy":[4,7,9,10], "id":10, "data":"foo"}
> 
> You needn't necessarily fill the hierarchy tree with ids, but the values should represent
the order that you want the items to be displayed. (Perhaps a timestamp value?)
> 
> To create a new comment under an existing one, take its "hierarchy" array value, and
add a new ordering number to the end.
> 
> To use this, write a view that uses hierarchy as a key - it will sort all the values
into lexicographical order.
> 
> To get all the items that a particular item is parent of...
> eg:
> All the children of comment {"hierarchy":[1,3], "id":3, "data":"foo"}
> can be found by querying the view with startkey:[1,3] and endkey:[1,3,{}]
> 
> Write some display code to manage proper indentation, and you're done. :-)
> 
> 
> 
> 7zark7 wrote:
>> Bit of a design question, hope you can provide some guidance:
>> I'm writing an internal wiki-like web application, and one of the use-cases is to
comment on a document.
>> Domain model is simple:
>> a Comment class with text, date, and a collection of child comments.
>> My first implementation stores the comment tree in a single document, since it is
very easy to serialize and deserialize, and the comment tree itself can be thought of as a
holistic "document".
>> This works great, but now running into an issue on how to best support revision conflicts
when multiple people are commenting at the same time.
>> If I were to keep the tree stored in a single document, I would have to load the
two conflicting versions in code, manually combine the trees, and then save a new version,
correct?
>> From a storage-perspective, it seems it would be simpler then to store each comment
as its own document, with a "foreign key" of sorts pointing to a parent comment, which would
be much less likely to have conflicts.
>> But then it seems I'm forcing a relational model into a document-based DB.
>> Any thoughts on this?
>> Thanks,
>> Z


Mime
View raw message