couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Lennart Melzer <>
Subject Re: Comment tree design in CouchDB?
Date Wed, 25 Nov 2009 08:14:10 GMT
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.

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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message