incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Patrick Barnes <>
Subject Re: Comment tree design in CouchDB?
Date Wed, 18 Nov 2009 11:23:57 GMT
I would suggest that each comment has a 'hierarchy' attribute, like an 
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...
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

View raw message