couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Keith Gable <>
Subject Re: Modeling a tree in couchdb.
Date Mon, 02 Jan 2012 21:53:05 GMT
The method I use is to have a field called "path", which contains a list of
IDs, and the last item in the list/array is the current document's ID. The
downside is that you have to assign the IDs yourself, but the upside is
that it's easy to query.

Keith Gable
A+ Certified Professional
Network+ Certified Professional
Web Developer

On Mon, Jan 2, 2012 at 2:57 PM, Jo-Erlend Schinstad <> wrote:

> 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

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