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: local policy)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1077)
Subject: Re: Comment tree design in CouchDB?
From: Lennart Melzer <l.melzer@tu-bs.de>
In-Reply-To: <4B03D94D.9080409@gmail.com>
Date: Tue, 24 Nov 2009 13:48:16 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <19F72458-23ED-4DC5-AA85-47652E001D22@tu-bs.de>
References: <4B03D09A.8020408@gmail.com> <4B03D94D.9080409@gmail.com>
To: user@couchdb.apache.org

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"}
>=20
> 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?)
>=20
> To create a new comment under an existing one, take its "hierarchy" =
array value, and add a new ordering number to the end.
>=20
> To use this, write a view that uses hierarchy as a key - it will sort =
all the values into lexicographical order.
>=20
> 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,{}]
>=20
> Write some display code to manage proper indentation, and you're done. =
:-)
>=20
>=20
>=20
> 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?
>> =46rom 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