Custom Pull Replication Conflict Resolution CBL 2.x

I have an application where multiple users make significant changes to documents while offline. When those users sync up, large bodies of conflicts must be resolved in a way that retains most of each user’s work. I’ve been following conversations related to automatic conflict resolution, and how there is currently no built-in way to customize conflict resolution when conflicts occur during pull replication (see here, and many related posts on this forum). Quick note: I’m aware that customizable save-induced conflict resolution exists, but I need to customize pull-replication-induced conflict resolution.

I see that this issue was recently put into the backlog (which I think means it’s scheduled for the next release?), but I’m not sure exactly what the deliverables are here. Will the next release include a way to customize pull replication conflict resolution?

Either way, I need to design a workaround in the meantime. I’m currently exploring the idea of making “local” copies of documents that the user wants to change, and merging with the “true” document (the one affected by pull replication) upon document save and/or a change to the pull-replicated document.

Assuming this sounds feasible at all (does it?), here are the implementation pieces I’m fuzzy on:

To make a copy of a document, I’m hoping to use:

var copy = new MutableDocument(other.ToDictionary());

If I save copy to the database, it will have a unique document id, correct? I.e copy.Id != other.Id?

I don’t want to replicate these “local” copies. To do this, I’m planning to use “global” Pull replication, and document-specific PushPull replication. I plan to maintain my own list of modified-document ids, and to use this feature to control which documents get pushed up from the local database (I would only replicate changed documents, and only the non-local copy).

There are of course other implementation details, but these are currently my biggest questions.

Thanks for reading!

Hi Andy,
Yes, we are exploring custom conflict resolution. We’ve had many requests.

I don’t completely understand the algorithm you are suggesting but it sounds a little bit like a 3-way merge: keep the original and then diff it with the merged document. In general, something like that should work.

Merge algorithms are well understood. It might make sense for you to start by reviewing the common ones, at a high level, choosing one that is sufficient for your requirements (will 2-way work), and then figuring out how to implement it with the available tools.

Could you use document change events for this?

@blake.meike Yes that’s generally what I am thinking. Once I get into the implementation a little more I can describe my thoughts more quantitatively.
As for merge strategies, I’m currently using a timestamp based method to resolve .Save induced conflicts, so I’m planning to just port that logic over to this.

@daniel.petersen Yes, I’m thinking document change events will trigger the “merge”. When a local copy is updated, I’ll need to diff it with the replicated copy. When the replicated copy is updated, I’ll need to diff it with the local copy. I’ll need to take care here to avoid infinite update loops.

1 Like