Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: pass (nike.apache.org: domain of kevin.r.coombes@gmail.com
 designates 209.85.161.180 as permitted sender)
Message-ID: <4F01E3A1.2080402@gmail.com>
Date: Mon, 02 Jan 2012 11:04:33 -0600
From: "Kevin R. Coombes" <kevin.r.coombes@gmail.com>
Organization: UT M.D. Anderson Cancer Center
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
 rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: user@couchdb.apache.org
CC: Walter Werner <wernwa@googlemail.com>
Subject: Re: Modeling a tree in couchdb.
References: <4EF45C4A.5080902@gmail.com>
 <A9DC438D6CAFFF4BBB299581444408810120AA27A379@VS-EX-01.intra.vpro.nl>
 <CAP1T3-W4LTsGHAkOd7Mpb7Akr-iQ-6p=MrOAawuiXAQW6HVpNw@mail.gmail.com>
 <4F0164FE.7050207@gmail.com>
 <CAP1T3-V0PZQPZ57Ai8HnWMr9DhqcpxqAo8JvQzL+L38ABQPRmA@mail.gmail.com>
In-Reply-To: 
 <CAP1T3-V0PZQPZ57Ai8HnWMr9DhqcpxqAo8JvQzL+L38ABQPRmA@mail.gmail.com>
Content-Type: multipart/alternative;
 boundary="------------000507030209030101020609"

--------------000507030209030101020609
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Take this suggestion with a grain of salt, since I haven't actually 
tried it and am just making things up....

If your structure is really a tree, then the location of every node is 
characterized by a unique path back to the root node, You could save the 
entire path in each object as a list:
     [parent, grandparent, great-grandparent, ..., rootnode]
One view would simply return this entire list for each object.
A second view would just give back the parent node.
Either view can be used (with appropriate logic in the client) to 
reconstruct the entire tree. However, you could also easily create 
auxiliary views (e.g., grandparent) depending on your needs.

This organization makes querying the tree relatively easy.  However, it 
will have _terrible _performance if you do a lot of surgery on the tree, 
lopping off branches and reattaching them in different places.

Best,
     Kevin

On 1/2/2012 2:33 AM, Walter Werner wrote:
> 2012/1/2 Jo-Erlend Schinstad<joerlend.schinstad@gmail.com>:
>> Den 02. jan. 2012 08:58, skrev Walter Werner:
>>
>>> How about if every document get a parent attribute?
>>>
>>> root document
>>> id: 123
>>> parent: undefined
>>>
>>> child document
>>> id: 768
>>> parent: 123
>>>
>>> child child document
>>> id: 991
>>> parent: 768
>>>
>>>
>>> etc.
>>>
>>> You need then a view with the parent as a key. With one request you
>>> can get all his children (only 1 level) of a document. Then you
>>> proceed with the children-documents and ask again whether they have
>>> children. Maybe it will be a performance Issue, if your 'object' has
>>> too many levels. The advantage is, that you don't have to think about
>>> how the id's of your documents should look like.
>>>
>>>
>> That is almost what I'm currently trying. I Have a topmost_parent attribute,
>> then a parent attribute and a next_sibling attribute. That way, I can get
>> all elements with one request. I still have to process on the client, but I
>> think it should work. The optimal solution would allow me to get it ordered
>> correctly from the database, but I see no way of achieving that.
>>
>> Jo-Erlend Schinstad
> Did you think about of using 2 keys in your view? One key for the
> parent attribute and the other for ordering
>
> [doc.parent, doc.timestamp]
>
> I take timestamp as an example.
>
> Walter

--------------000507030209030101020609--