On 18 April 2012 10:03, Robert Newson <[email protected]> wrote: > Hi Paul, > > I expanded on it here: https://gist.github.com/2387973 > > (As an aside, the all_or_nothing:true setting for bulk_docs is being > deprecated.) > > The motivation for all these changes is that knowledge of conflicts, > and how to handle them, with the current API ends up happening very > late in the development cycle and, frequently, *post* development and > into production and maintenance. We think it better to make the > multi-master model, and its consequences, clearer and simpler to all > up front. It's a great model but you need to understand it, hiding > portions of it by default is a hindrance.
I'm really hoping this change goes ahead (I voted for it). Assuming multi-master replication from the start is definitely a better approach with CouchDB in my experience. (I've seriously considered using _bulk_docs with all_or_nothing:true for *every* update to achieve a similar effect.) Another item in the giant todo list that will reduce the chance of conflicts happening is partial updates of documents. In fact, I would love to see the following implemented together: * Conflicts as first class citizens * Partial updates of documents (single doc and bulk docs API please ;-)) * all_or_nothing:true removal - Matt > > This is not to say that you won't be able to hide these things with a > setting. The full discussion and design of these items has not yet > taken place, so it's too early to say. > > B. > > On 18 April 2012 09:51, Paul Hirst <[email protected]> wrote: >> I saw this idea on allourideas.org: >> >> "Conflicts as first class citizens: Surface the conflict on read, and always >> accept a write, assuming it passes validation." >> >> I was wondering if anyone could expand on this? >> >> On write, conflicts will be rejected at the moment which is really handy >> from a simplicity point of view and in many use cases it's a good enough >> solution. If you use the all_or_nothing:true option through the bulk API >> then you can currently write conflicting documents and this is (as I >> understand it) exactly what replication does. >> >> So, is this idea, about changing the default behaviour to act as the >> all_or_nothing option? Does it get rid of the ability to detect and reject >> conflicts at write time? Lastly, why does anyone want it when we seem to >> have the best of both worlds at the moment? >> >> ________________________________ >> Sophos Limited, The Pentagon, Abingdon Science Park, Abingdon, OX14 3YP, >> United Kingdom. >> Company Reg No 2096520. VAT Reg No GB 991 2418 08.
