On Wed, 28 Dec 2011 23:08:01 +0100 Jo-Erlend Schinstad <joerlend.schins...@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
