incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Goodall <matt.good...@gmail.com>
Subject Re: Making conflicts first class citizens
Date Wed, 18 Apr 2012 09:59:23 GMT
On 18 April 2012 10:03, Robert Newson <rnewson@apache.org> 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 <paul.hirst@sophos.com> 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.

Mime
View raw message