You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@couchdb.apache.org by 7zark7 <7z...@gmail.com> on 2009/11/18 11:46:50 UTC
Comment tree design in CouchDB?
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
Re: Comment tree design in CouchDB?
Posted by 7zark7 <7z...@gmail.com>.
On 11/18/09 3:45 AM, Jan Lehnardt wrote:
>
> On 18 Nov 2009, at 11:46, 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?
>
>
> Christopher Lenz has a great discussion about this very problem:
>
> http://www.cmlenz.net/archives/2007/10/couchdb-joins
>
> Cheers
> Jan
> --
>
Perfect, thanks Jan
Re: Comment tree design in CouchDB?
Posted by Jan Lehnardt <ja...@apache.org>.
On 18 Nov 2009, at 11:46, 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?
Christopher Lenz has a great discussion about this very problem:
http://www.cmlenz.net/archives/2007/10/couchdb-joins
Cheers
Jan
--
Re: Comment tree design in CouchDB?
Posted by Chris Anderson <jc...@apache.org>.
On Tue, Dec 1, 2009 at 10:28 AM, Anh <7z...@gmail.com> wrote:
> BTW, I coincidentally noticed that the "CouchDB: The Definitive Guide"
> online version has a hidden link that is commented-out link to a
> chapter that discusses comments via a small example:
>
> http://books.couchdb.org/relax/example-app/accepting-comments
>
> I found it useful as well, curious if there was anything "wrong" with it :-)
>
nothing wrong with it. we just didn't have the time to bring it to
publishing quality.
>
> Thanks again
>
--
Chris Anderson
http://jchrisa.net
http://couch.io
Re: Comment tree design in CouchDB?
Posted by Anh <7z...@gmail.com>.
BTW, I coincidentally noticed that the "CouchDB: The Definitive Guide"
online version has a hidden link that is commented-out link to a
chapter that discusses comments via a small example:
http://books.couchdb.org/relax/example-app/accepting-comments
I found it useful as well, curious if there was anything "wrong" with it :-)
Thanks again
Re: Comment tree design in CouchDB?
Posted by Anh <7z...@gmail.com>.
On Mon, Nov 30, 2009 at 6:36 PM, Chris Anderson <jc...@apache.org> wrote:
>
> I'd store a comment per document, otherwise users will be stepping on
> each other's toes which will kill your concurrency.
>
Good point, thanks
Re: Comment tree design in CouchDB?
Posted by Chris Anderson <jc...@apache.org>.
On Mon, Nov 30, 2009 at 5:56 PM, Anh <7z...@gmail.com> wrote:
> I've been thinking about it, and related to my original question on storing
> the comment tree in a single doc, does anyone see a problem with this
> approach?:
>
> When a comment is added and a revision conflict is detected, you deserialize
> the latest version of the comment tree and merge the two versions
> programmatically, and then reattempt the update.
>
> In my case, seems this would suffice due to the comment tree size likely
> being small, and also not having to worry about deleted/removed comments.
>
> Thoughts?
I'd store a comment per document, otherwise users will be stepping on
each other's toes which will kill your concurrency.
Chris
--
Chris Anderson
http://jchrisa.net
http://couch.io
Re: Comment tree design in CouchDB?
Posted by Anh <7z...@gmail.com>.
I've been thinking about it, and related to my original question on storing
the comment tree in a single doc, does anyone see a problem with this
approach?:
When a comment is added and a revision conflict is detected, you deserialize
the latest version of the comment tree and merge the two versions
programmatically, and then reattempt the update.
In my case, seems this would suffice due to the comment tree size likely
being small, and also not having to worry about deleted/removed comments.
Thoughts?
Thanks
Re: Comment tree design in CouchDB?
Posted by Brian Candler <B....@pobox.com>.
On Wed, Nov 25, 2009 at 11:27:45AM +0200, Metin Akat wrote:
> Hmm, could you explain how to configure CouchDB to generate such uuids please?
Judging by share/www/script/test/uuids.js, it looks like you just add
[uuids]
algorithm = utc_random
to your local.ini.
Full history is at
http://issues.apache.org/jira/browse/COUCHDB-465
and implementation in src/couchdb/couch_uuids.erl
Re: Comment tree design in CouchDB?
Posted by Lennart Melzer <l....@tu-bs.de>.
yup, good question. I see that you, Brian, have some kind of timebase-uuid-generator in your couchtiny lib. But that doesn't use couchdb's internal features.
Is there some undocumented feature we don't know of, yet?
On Nov 25, 2009, at 10:27 AM, Metin Akat wrote:
> Hmm, could you explain how to configure CouchDB to generate such uuids please?
>
>
> On Wed, Nov 25, 2009 at 11:14 AM, Brian Candler <B....@pobox.com> wrote:
>> On Tue, Nov 24, 2009 at 01:48:16PM +0100, Lennart Melzer wrote:
>>> 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).
>>
>> CouchDB can generate time-based UUIDs, where the top part of the uuid is the
>> time and the bottom part is essentially random.
>>
>> I think this would work very well for you:
>>
>> - you get documents with equal keys naturally sorted by insertion time
>>
>> - you don't even need to add a created_time field, since you can parse it out
>> of the uuid when you need it
>>
>> Regards,
>>
>> Brian.
>>
Re: Comment tree design in CouchDB?
Posted by Metin Akat <ak...@gmail.com>.
Hmm, could you explain how to configure CouchDB to generate such uuids please?
On Wed, Nov 25, 2009 at 11:14 AM, Brian Candler <B....@pobox.com> wrote:
> On Tue, Nov 24, 2009 at 01:48:16PM +0100, Lennart Melzer wrote:
>> 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).
>
> CouchDB can generate time-based UUIDs, where the top part of the uuid is the
> time and the bottom part is essentially random.
>
> I think this would work very well for you:
>
> - you get documents with equal keys naturally sorted by insertion time
>
> - you don't even need to add a created_time field, since you can parse it out
> of the uuid when you need it
>
> Regards,
>
> Brian.
>
Re: Comment tree design in CouchDB?
Posted by Brian Candler <B....@pobox.com>.
On Tue, Nov 24, 2009 at 01:48:16PM +0100, Lennart Melzer wrote:
> 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).
CouchDB can generate time-based UUIDs, where the top part of the uuid is the
time and the bottom part is essentially random.
I think this would work very well for you:
- you get documents with equal keys naturally sorted by insertion time
- you don't even need to add a created_time field, since you can parse it out
of the uuid when you need it
Regards,
Brian.
Re: Comment tree design in CouchDB?
Posted by Lennart Melzer <l....@tu-bs.de>.
Yup, stored the timestamps (still Date string) and the uuid in the tree. Works!
I have to ensure that the hierarchy is now of odd length in a way following this scheme [root_id, (timestamp, descendant_id)*]
I am working with couchrest and made a view with a bit of wrapping to handle the data correctly.
Here is the map function for the hierarchy and here the necessary code for handling it when querying for a certain document.
When adding a document to another document you just simply take the parent's 'descends_from' value and push it's timestamp followed by it's uuid into and set the result as the child's descends_from value. In the case of adding a child to a toplevel post you just set 'descends_from' to a new array containing only the parent's uuid.
It doesn't work with non-toplevel documents I think, but right now I don't need that functionality, perhaps one could add that easily.
The whole code is taken from a small project of my building upon a fork of scanty using couchdb as the backend. As soon as this is "kind of usable" I can put it up to github.
Greetings
On Nov 24, 2009, at 11:06 PM, Patrick Barnes wrote:
> Why not just store timestamps in the tree? Use the unix time format to make comparison faster, and as long as no two posts are made at *exactly* the same time, no problem.
>
> Hmmm, guess the uuid would be needed to avoid that issue.
>
> [10:00:47, 123] : id:123
> ..[10:00:47, 123, 10:05:00, 126] : id:126
> ..[10:00:47, 123, 10:06:23, 127] : id:127
> [10:00:47, 124] : id:124
> ..[10:00:47, 124, 10:03:11, 125] : id:125
>
> A little bit cumbersome, true... but it should work.
> (Of course, 1259103826 is easier to sort by than "2009/11/25 09:04:12")
>
> ------
>
> The other option might simply be to use an incrementing number for your document key, rather than a UUID.
> * On creation of a document, pull the largest current key from _all_docs, increment it, and create the document.
> * If the document creation fails because another process has beaten it to the ID, reincrement and retry until an unclaimed ID is found.
>
> That should work as long as the write frequency isn't very high, and would give you a much neater tree.
>
> ------
>
> Let us know what you end up doing. :-)
> -Patrick
>
> Lennart Melzer wrote:
>> 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
Re: Comment tree design in CouchDB?
Posted by Patrick Barnes <mr...@gmail.com>.
Why not just store timestamps in the tree? Use the unix time format to
make comparison faster, and as long as no two posts are made at
*exactly* the same time, no problem.
Hmmm, guess the uuid would be needed to avoid that issue.
[10:00:47, 123] : id:123
..[10:00:47, 123, 10:05:00, 126] : id:126
..[10:00:47, 123, 10:06:23, 127] : id:127
[10:00:47, 124] : id:124
..[10:00:47, 124, 10:03:11, 125] : id:125
A little bit cumbersome, true... but it should work.
(Of course, 1259103826 is easier to sort by than "2009/11/25 09:04:12")
------
The other option might simply be to use an incrementing number for your
document key, rather than a UUID.
* On creation of a document, pull the largest current key from
_all_docs, increment it, and create the document.
* If the document creation fails because another process has beaten it
to the ID, reincrement and retry until an unclaimed ID is found.
That should work as long as the write frequency isn't very high, and
would give you a much neater tree.
------
Let us know what you end up doing. :-)
-Patrick
Lennart Melzer wrote:
> 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
>
>
Re: Comment tree design in CouchDB?
Posted by Lennart Melzer <l....@tu-bs.de>.
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
Re: Comment tree design in CouchDB?
Posted by Patrick Barnes <mr...@gmail.com>.
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
>
>
>