Jens Einstein :-)
That's one advice I won't forget... 2014-02-07 Jens Alfke <[email protected]>: > > On Feb 6, 2014, at 4:03 PM, Jo-Erlend Schinstad < > [email protected]> wrote: > > > Right, but those strategies seem ... wrong. :) > > They just don't work the way you're used to, because they're optimized for > different things. > > > 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. > > I don't think this will work correctly if (a) two clients are trying to > move nodes at the same time, or (b) two instances of the database with > different changes to the same nodes replicate with each other. (In general, > whenever an algorithm calls for "ordering things by time", alarms go off in > my mind. Distributed systems are similar to Special Relativity in that > there's no unique consistent notion of time.) > > —Jens > >
