Search code examples
couchdbreplicationconflictmerge-conflict-resolution

CouchDB prevent replication on conflict

I want to be able to prevent a 'push' (or replication) to the central CouchDB instance from a user's local instance (where there are many users) if there are any conflicts - essentially copying the functionality from something like Git or Mercurial, where users have to resolve conflicts on their local copy before pushing to the central server (so the server can remain 'clean').

As far as I can see, there are two options; preventing a user from committing if there are conflicts (although I can't see any way to do this without actually completing the replication), or completing the replication, seeing if there are any conflicts, and then deleting the pushed replication (and the associated documents) if there are conflicts (though this could also result in undesirable behaviour if a pull is completed before the documents are re-deleted, as well as being a bit inefficient).

So to boil that down, ideally, I would like a replication to roll back if there is a conflict, and to inform me that a conflict has occurred (I don't care about the nature of the conflict, because then I can initiate a pull request replication to replicate the central db on the local db).

Is there any way to achieve either approach that I've missed?

Solution

  • Although it might not be the best solution, I did something a bit more convoluted;

    1. Issue a replication pull request to the central db, specifying the replication id as [RequestingMacAddress].[Guid].
    2. When issuing a replication push request to the central db, I check for the last pull request ID (on the central db), using a custom view (using the same MAC address).
    3. I pull the _changes in descending order, and ensure that the most recent changes on the DB was either the [RequestingMacAddress].[GUID] specified above, or was another pull request (to a different machine), and that no tasks are currently active (e.g. a push replication is in progress from another machine).
    4. If everything is good - allow the push replication to continue, else error out.

    Will lookout for any better solutions if available.