couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adam Kocoloski <>
Subject Re: Making conflicts first class citizens
Date Wed, 18 Apr 2012 13:11:52 GMT
On Apr 18, 2012, at 4:51 AM, Paul Hirst wrote:

> I saw this idea on
> "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.

I wouldn't completely remove the ability to reject conflicts on write.  When I proposed this
idea I was thinking first and foremost about surfacing them on reads.  On writes I want a
new option that looks a lot like all_or_nothing:true but without the transactional bit where
if any document in the batch fails validation the whole batch is rejected.  Probably too early
to say whether that new option would be the default.  I definitely agree with the other responses
that planning for conflicts from the start is a better approach to working with CouchDB.

As an aside, replication does something related but slightly different -- in addition to creating
a new edit branch if required, it uses new_edits:false to bypass the generation of a new _rev.

View raw message