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 gcdcu-couchdb-user@m.gmane.org
 designates 80.91.229.12 as permitted sender)
Mail-Followup-To: user@couchdb.apache.org
Reply-To: user@couchdb.apache.org
To: user@couchdb.apache.org
From: Ted Zlatanov <tzz@lifelogs.com>
Subject: Re: Modeling a tree in couchdb.
Date: Wed, 28 Dec 2011 19:33:05 -0500
Organization: =?utf-8?B?0KLQtdC+0LTQvtGAINCX0LvQsNGC0LDQvdC+0LI=?= @
 Cienfuegos
Lines: 30
Message-ID: <87ehvoqkse.fsf@lifelogs.com>
References: <4EF45C4A.5080902@gmail.com> <87zkeet1or.fsf@lifelogs.com>
	<4EFB9341.1090607@gmail.com>
Mime-Version: 1.0
Content-Type: text/plain
Mail-Copies-To: never
User-Agent: Gnus/5.110018 (No Gnus v0.18) Emacs/24.0.90 (gnu/linux)
Cancel-Lock: sha1:FUX7s02RCZobSR6B+clY7dCJ740=

On Wed, 28 Dec 2011 23:08:01 +0100 Jo-Erlend Schinstad <joerlend.schinstad@gmail.com> wrote: 

JS> Den 27. des. 2011 17:32, skrev Ted Zlatanov:
>> How big is this document?  If it's like the TreeModels I've used, maybe
>> you can simply keep the whole connectivity data (the edges of the graph)
>> in one document, and the nodes have one document each.  That way you can
>> load or update the graph in one shot; replication is simpler;
>> consistency is better (at worst, a node is missing).  Renumbering is
>> easier as well, since you just load a single document, rewrite it, and
>> save.
>> 
>> If this is a huge tree or you expect multiple clients to update the
>> connectivity graph this is not a great solution.
>> 
JS> Thanks for the suggestion. Interesting idea. The problem is that I
JS> want this to be a general solution, which means I don't know how big
JS> it will be or whether it'll be accessed simultaneously by different
JS> users.

One suggestion...  If you don't expect elements and subtrees to move
around much (if it's mostly append activity), you can break the
connectivity document into pieces when it gets big enough.  It can be
better than storing the full list of edges, which for a large tree will
be huge, or implicitly creating edges based on node child/parent
attributes, which is expensive.  But it's not general, of course:
rebalancing the tree will be painful and moving a node can require 2
rewrites instead of 1, so you could end up with the node in two
locations temporarily.  And you have to write code to do it :)

Ted