> On Mar 21, 2018, at 10:55 AM, Traun Leyden <[email protected]> wrote: > > You are correct in your assumptions that all conflict resolution in 2.0 will > be wallclock-based "last write wins", since there is no longer an API to > plugin custom conflict resolvers. (previous 2.0 beta versions did have this > feature)
What prompted its removal? > Basically there appears to be a very small minority of users that will > actually need to implement custom conflict resolvers based on their use case, > and including this into the API raises the complexity quite a bit. What sort of complexity? We're still building with DB021 at the moment (due to the need to target Sync Gateway 1.5 since we're not yet in a position to deploy SG beta to our server environment), but there it's been possible to register a conflict resolver with the replicator. I presume that if/when a conflicting rev comes down in a pull, the resolver would be called, and I could return an appropriate rev (be it A, B, or a new merged C). Granted, our development on this app is still in early enough stages that we haven't gotten to the point of implementing or exercising conflict resolution logic yet, but the principle seemed straightforward. I wonder what I'm missing. > Also, if you are able to post details on your particular use case that > highlights the need for custom conflict resolvers, that will help make a case > for re-adding it. Priya wrote me directly asking for a similar case, so I'll reiterate here the explanation I gave her, for the benefit of you and others: Our application (iOS, Android, and web) services financial accounting for small-business customers. The main area under development is mobile capture and classification of financial documents (e.g. expense receipts, tax forms) both in the field and at a computer. Typically, one or more users might be making different edits to a particular document at any given time. For example, a person might purchase some supplies at a shop and file the expense immediately from her phone. An hour later while at a coffee shop she might supplement the record with some more details (e.g. notes on items purchased). Meanwhile, in the interim or afterwards, a data-entry clerk might transcribe some fields from the attached image into well-formed data fields (e.g. price, date, invoice number). An accountant back at the office might start to act on the expense and enter it into the general ledger. A project manager might also concurrently assign some of the bought items to a project. All of these actions would involve making changes (additions, edits, deletions) to a variety of fields in a particular Couchbase document that embodies the purchase. In several of our document types, for auditing purposes, changes and additions made by various users are added to an "annotations" array. At any given time the app's business logic examines the array in order to create a current picture of the represented data. This array is expected to be appended to at random. As you should now intuit, it is crucial that additions to the "annotations" array be coalesced from sibling revisions in the face of a conflict, rather than one particular set chosen at random. Couchbase Lite is extremely well-suited to our application both for its use of non-structured documents and its offline performance. However, a lack of control over conflict resolution makes offline use dangerous and unreliable; even online use would become unpredictable if more than a single client expects to manipulate the same document (via SG). cheers, -ben -- You received this message because you are subscribed to the Google Groups "Couchbase Mobile" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/mobile-couchbase/339CD153-1D3A-40A1-B19C-BD59837FCFEA%40kashoo.com. For more options, visit https://groups.google.com/d/optout.
