Hi Ben The automatic conflict resolution process in 2.0 was designed as such based on feedback we received from a number of our customers on 1.x. Hence, it is not listed as a bug or as a known issue because it is "working as designed" !
That said, we understand that the automatic conflict resolution may not be applicable in some instances. To that end, we are are consolidating use-case feedback from users such as yourself to determine the optimal way to design the system. So this would be a future enhancement - it wouldn’t make the 2.1 release (in couple months) but stay tuned . Again, appreciate your feedback and details on your use case. -Priya On Thursday, April 12, 2018 at 3:28:40 PM UTC-4, Ben Kennedy wrote: > > Congratulations to the CBL team on the GA release of 2.0! > > Unless I have missed it, nothing further has been said on the subject of > this replication design flaw. Given Couchbase [Lite]'s reputation for data > integrity, and considering the expectations of those planning to migrate > from 1.x, I am surprised that there isn't any allusion or mention of this > in the release notes or getting-started docs. (The latter even includes a > list of “bugs” and “known issues” at the bottom; wouldn't this type of > thing warrant an entry?) > > -b > > > On Wednesday, March 21, 2018 at 4:40:03 PM UTC-7, Traun Leyden wrote: >> >> >> >> On Wed, Mar 21, 2018 at 12:02 PM, Ben Kennedy <[email protected]> >> wrote: >> >>> > 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? >>> >> >> Sorry but I don't know the exact reason. It may have been related to >> assessing the testing/documentation effort. >> >> >>> > 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? >>> >> >> Maybe "surface area" is a better way to put it. Any feature has to be >> thoroughly tested and documented. Rather than delay the release, sometimes >> features need to be removed and postponed until (potential) future releases. >> >> >>> >>> 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. >>> >> >> I don't think you're missing anything, and yes the principle is >> straightforward. >> >> >> >>> >>> > 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). >>> >> >> Ok thanks. If you have a hard requirement to keep the annotations >> together in a single document, this seems like a perfectly reasonable case >> where you'd need to merge the annotations w/ some custom business logic. >> >> >> >>> >>> 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/e5ef3755-5d5f-42d3-bc59-0e2cc3ddc4c0%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
