Solve conflicts in the Bigcouch layer.
"Bigcouch is based on Amazon Dynamo":http://bigcouch.cloudant.com/. Amazon dynamo "implements":http://www.allthingsdistributed.com/2007/10/amazons_dynamo.html "eventual consistency":https://en.wikipedia.org/wiki/Eventual_consistency, and objects may have conflicted versions.
U1DB is a conceptual noSQL database layer which may also have objects in conflicted state after syncs between 2 replicas.
For Soledad, we built a U1DB backend on top of CouchDB, which means that we have 2 potential layers of conflicts:
- U1DB object conflict: If the same U1DB object is updated in distinct devices and synced to the same Soledad server, that U1DB object may end up in a conflict state.
- Bigcouch object conflict: If the same U1DB object is updated in distinct devices and synced to distinct Soledad servers, the underlying bigcouch object may end up in a conflicted state.
Those two layers of conflict have to be trated separatelly.
U1DB objects conflicts have to be dealt with by the application that manipulates them. For example, if a certain email message is marked as flagged in one device and as deleted in another device, and both devices sync with the same server, then that message object will be marked as conflicted in the U1DB layer and the email application has to solve that conflict somehow.
Bigcouch objects conflicts have to be dealt with by the Soledad layer. In the example above, if the devices sync to distinct Soledad servers, then the message objects may end up in a conflicted state in the bigcouch layer, and that conflict has to be somehow handled before the object is made available to the U1DB layer.
(from redmine: created on 2014-03-12)
- Relations:
- blocks #3308