3 ms·
By definition they don't have conflicts in the technical sense of the word, but they can easily get into bad states after a merge. It's not technically a confl
by xnorswap 2y ago
By definition they don't have conflicts in the technical sense of the word, but they can easily get into bad states after a merge.
It's not technically a conflict since there is a path forward, but the resulting output can be nonsensical.
For example you could employ a strategy where given two concurrent edits, the merge "randomly*" picks one of the two edits for each property/fact, and abandons the other.
That's a construction of a conflict free replicated data type, but it says nothing of the quality of the final result.
Ultimately, the quality comes down to how well you can produce merge strategies for your domain.
* "Randomly" in a deterministic way, e.g. by comparing a hashes of transaction IDs or similar.
- kiitos 2y ago> By definition they don't have conflicts in the technical sense of the word... ...which is the sense that we're talking about, when we talk about CRDTs.
- Dylan16807 2y agoWhen someone goes into detail about correct versus convergent, they are explaining how the technical sense is not what people really want, and you bluntly replying that it's solved (because it's technically solved) is unhelpful at best and misleading at worse.
- kiitos 2y agoA CRDT is a purely technical construct! Correctness (in terms of merge conflicts) is well-defined in that context and it's orthogonal to any kind of semantic/application definition! This is a bonkers conversation. It's like claiming integer division isn't correct because 5/2 should be 2.5 instead of 2.