The couchbase lite 2.x docs say it automatically resolves conflicts, will it automatically handle docs from older versions of couchbase lite that have conflicts in them already? Currently we are on couchbase lite 1.3.1 and sync gateway 1.3.1. Our couchbase data server is getting OOMs because we have some docs that have over 1000 revisions and over 1000 conflicts, and when one of these docs gets updated or retrieved from CBL sync gateway uses up a ton of CPU and mem doing something. Sync gateway should be limiting docs to 1000 revisions but for some reason it is not doing that, and CBL 1.3.1 is supposed to auto-resolve conflicts by just going with the longest branch and last updated, but it doesn’t seem to be doing that either and we end up with conflicting branches that are 100’s of revisions long even though we have no custom conflict handling code or logic. We are about to evaluate upgrading to CBL and sync gateway 2.x and the latest couchbase server, but I wanted to confirm that would actually solve our major issues with the current version of CBL and sync gateway.
Sync gateway should be limiting docs to 1000 revisions but for some reason it is not doing that
It limits the depth of the tree to 1000 revisions. But if there are large numbers of conflicts (branches), the number of revisions in the tree can grow beyond that.
CBL 1.3.1 is supposed to auto-resolve conflicts by just going with the longest branch and last updated
CBL 1.3 doesn’t automatically resolve conflicts. What you’re describing is the way that it chooses which is the ‘current’ revision, when there’s a conflict.
It’s up to the app to resolve conflicts, by deleting the other leaf revision(s).
You should fix conflicts before upgrading. When CBL 2 imports a CBL 1 database it only preserves the current revisions, not conflicts. I am not sure what Sync Gateway does, but I believe it will not resolve conflicts either (@adam?)
Thanks! So if we don’t write custom conflict handling code in our app it will keep all conflicting branches? Before we upgrade we should write custom conflict handling code to delete all leaf revisions from the losing branch and then when we upgrade it will be sort of a clean slate and we can remove the custom conflict handling code?
Right. Just iterate over all the conflicting revisions (there’s a special mode for it in the doc enumerator) and add a deletion to each one. Or you can do it on the SG side using the REST API (I forget the GET modifiers to list all the leaf revisions; ?open_revs=true or something like that.)
Thanks! This will really help us with OOM issues on production.