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
