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 <ben.k...@kashoo.com> >> wrote: >> >>> > On Mar 21, 2018, at 10:55 AM, Traun Leyden <traun....@gmail.com> >>> 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 mobile-couchbase+unsubscr...@googlegroups.com. 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.
