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] > <javascript:>> wrote: > >> > On Mar 21, 2018, at 10:55 AM, Traun Leyden <[email protected] >> <javascript:>> 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/38fb2cb8-0558-4747-9a2c-a9dc7fb30a00%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
