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 joerlend.schinstad@gmail.com
 designates 74.125.83.52 as permitted sender)
Message-ID: <4F021A1D.4010502@gmail.com>
Date: Mon, 02 Jan 2012 21:57:01 +0100
From: Jo-Erlend Schinstad <joerlend.schinstad@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:9.0) Gecko/20111229 Thunderbird/9.0
MIME-Version: 1.0
To: user@couchdb.apache.org
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>
 <4F01E3A1.2080402@gmail.com>
In-Reply-To: <4F01E3A1.2080402@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Den 02. jan. 2012 18:04, skrev Kevin R. Coombes:
> 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.
>

That was my original thought. I  wanted to do something like key [0, 5, 
4,2] which would mean the sixth child of the first top-level node, and 
the fifth child of that node and the third of it.

This would work well, and I would get the tree in one go, organized and 
nice. The problem is that the tree must be reorganizable. In that model, 
if moved one node, then I would have to update all the following 
documents. If there's a million rows in the tree, then I would need 
something like 999.990+ http requests... :)

Further, one of primary goals is replication. It could never work. The 
internet janitor would hit me in the back of the head with a wrench. 
However, for something like a family tree or a blog, where something 
will forever be a response to something else, that would work nicely.

So what I'm doing now, is that I'm just retrieving the data from the 
database and organising it on the client. It's not a comfortable 
solution, I think. It's not elegant, but if it's the only possible 
solution, then it doesn't really matter if it's elegant or not. :)

In other words, I'm still very much looking for a good way to model a 
flexible tree in a couchdb. Any suggestions are highly welcome.

Jo-Erlend Schinstad