Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: pass (athena.apache.org: domain of mrtrick@gmail.com designates
 209.85.218.218 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:user-agent:mime-version:to:subject:references
         :in-reply-to:content-type:content-transfer-encoding;
        b=YYhXO+0mgA/MUoLFKokgopLLNYfljD9LIgIB7pdEpX9+2PgDohsALclGH7tQkTD06W
         KXnb/UWT+o8rNX4fTzWIRPAjfiArcnA9AriaBJGUDNzJBkrSGFy9x3ltfeK+stdd6+aw
         ZUeti0rWCSvxBTsoyK2PGwBz6juFvrDIC9GI0=
Message-ID: <4B0C58D0.8000602@gmail.com>
Date: Wed, 25 Nov 2009 09:06:08 +1100
From: Patrick Barnes <mrtrick@gmail.com>
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: user@couchdb.apache.org
Subject: Re: Comment tree design in CouchDB?
References: <4B03D09A.8020408@gmail.com> <4B03D94D.9080409@gmail.com>
 <19F72458-23ED-4DC5-AA85-47652E001D22@tu-bs.de>
In-Reply-To: <19F72458-23ED-4DC5-AA85-47652E001D22@tu-bs.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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