couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jo-Erlend Schinstad <joerlend.schins...@gmail.com>
Subject Re: CouchDB transactions?
Date Fri, 07 Feb 2014 00:03:05 GMT
On 7 February 2014 00:19, Jens Alfke <jens@couchbase.com> wrote:

>
> There are other ways to model trees. The simplest is to just store a
> "parent" reference in each document. This results in unordered sibling
> nodes, though. If you need ordering, you can add an "order" property to
> each node, and then sort siblings by its value. To move a node in the
> sibling order, you change its "order" property to something in between its
> new left and right siblings'. The obvious types of values to use are
> floating-point numbers, but eventually you run out of precision. I've also
> heard people propose strings -- if you need to move a node between siblings
> "a" and "ab" you can give it the order value "am"


Right, but those strategies seem ... wrong. :)

I have had the idea of using a kind of journal. That is, when I want to
move a node, then I first create a "transaction document" with references
to the involved nodes. Then I update the NextNode's reference so that it
points to the PreviousNode. This means that there are now two nodes that
points to the PreviousNode, which is wrong. But if I order these nodes
based on time, and always use the newest, then in effect, that means that
the CurrentNode is now out of the tree. I can now update CurrentNode's
"prev" field, which will be without any side effects. Finally, I can insert
CurrentNode by updating the MoveBeforeNode's "pref" field to point to
CurrentNode.

In effect, this should work like a cut and paste mechanism. Then, if the
connection is broken before the transaction is complete, then other nodes
will be able to detect that by the fact that there are two nodes pointing
to the same node. The oldest node can be looked up from the journal and
moved to the right place.


What do you think about this approach? Does it make sense?

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