Client-side conflict resolution

[rafamel]

Adding this for future reference.

With the current architecture of RxDB, immediate interception of conflicting revs for eventual conflicts doesn't seem possible.

There are two strategies to consider:

• Resolving conflicts when pull changes from a replication fire: Currently, RxDB sets replication for the inner PouchDB instance of each collection, meaning, when changes come in they fire both the PouchDB replication change event, and therefore also the RxDB change$ observable (source), but the replication flow cannot be interrupted. Meaning, whatever we do when handling the change, we cannot stop that change from going in, we can only perform an additional update to the doc if desired. If conflicts were handled here, there would be a timespan (milliseconds, but enough for the view to get re-rendered) in which the server winner for the revision would appear first, causing several updates for the same doc (worst case). This is a viable but not ideal implementation.

• Resolving conflicts when docs are queried for: The only way to prevent rendering of docs would be to intercept them and check for conflicts before they are returned from RxQueries (find, findOne). These use pouchdb-find, which doesn't allow to fetch conflicts, as we would with PouchDB's get() and bulkDocs(). If that was implemented, and there was no significant overhead on the queries performance when returning conflicts (which I would assume would hold true for queries with docs with no conflicts), then we could retrieve documents with their conflicts via find, and use RxDB's own methods for RxDocuments update (so we don't have to iterate over all the docs on the query twice) to check whether conflicts exist, and if so, handling them accordingly. Until pouchdb-find allows for conflicts to be fetched, this is not a viable implementation.

Relevant: pouch-resolve-conflicts, deconflict, PouchDB docs on eventual conflicts, CouchDB find docs, Cloudant docs on conflicts

[motin]

What is the rationale for reporting this against rxdb-utils as opposed to rxdb directly?

[rafamel]

I was planning on implementing this on this library - @pubkey had suggested for it to be implemented as a plugin. Other than that, it's just rather a note to self of sorts, just in case I had the same idea again, so I could quickly take a look at the rationale I had when thinking about this.

[MentalGear]

Automatic Conflict resolution would be a great addition for rxdb. Since @rafamel already seems to have worked out a way to add this, I wanted to tip you a great library which could handle conflicts automatically: ttps://github.com/automerge/automerge.