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 < joerlend.schins...@gmail.com> 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 >
