My problem with this kind of design is that you can't really use any relational constraints. Or constraints between columns in a given table because each column is independently merged
This works assuming everyone has the same clock or performs changes causually distant from each other. It fails to work if, say, 1000 people all make a change around the same time. This also applies to lamport timestamps.
Yeah, I implemented a vector clock a few years ago, and I never really found an elegant way to deal with conflicts like this. My very-much-inelegant solution was every item attached an epoch time in milliseconds which was used in a tiebreaker, and if both timestamps were the same I would hash something and choose the smaller one of those.
It seems wrong to rely on NTP for a distributed system like this, but I couldn't really figure out a better way at the time.
If a thousand people all made a change at the same time in a totally deterministic, always online system a single one of those writes would arbitrarily win in exactly the same way.
In practice "1000 people edit same thing at same time" is not a problem that needs to be solved via software, the users are just doing silly things and getting silly results.
If it isn’t handled correctly, you’ll eventually end up with parallel histories on different devices. Even if it isn’t 1000 people, people will share documents with entire classrooms, offices, etc., which increases the probability of this situation tremendously.
We handle this in Fireproof with a deterministic default algorithm, in addition to having a hash-based tamperproof ledger of changes. Fireproof is not SQL based, it is more like CouchDB or MongoDB, but with cryptographic integrity. Apache 2.0 https://use-fireproof.com
In practice during CouchDB's heyday, with lots of heavy users, the conflict management API almost never mattered, as most people can make do with deterministic merges.
We are saying the same thing. I was pointing out that the article missed one of the hardest parts of actually implementing this, where your algorithm architecture can totally fuck you over if you didn’t plan for it. I just think it’s interesting that they missed pointing it out. Either they got it right on the first try or they haven’t realized the issue with the schema they’re proposing.
> Here’s a polished section you can insert into your article (it fits naturally after the Sync Phase section):
It seems wrong to rely on NTP for a distributed system like this, but I couldn't really figure out a better way at the time.
In practice "1000 people edit same thing at same time" is not a problem that needs to be solved via software, the users are just doing silly things and getting silly results.
In practice during CouchDB's heyday, with lots of heavy users, the conflict management API almost never mattered, as most people can make do with deterministic merges.
It doesn't need to make sense, or be the most recent change, only that given the same inputs, everyone independently agrees on the same output.