couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Davis <>
Subject Re: Making conflicts first class citizens
Date Wed, 18 Apr 2012 15:42:38 GMT
On Wed, Apr 18, 2012 at 9:49 AM, Paul Hirst <> wrote:
>> 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.
> I disagree. While I think dealing with conflicts properly, often happens too late in
development (and I'm guilty of this myself) I think being forced to deal with it from the
start is unhelpful.
> I think it's fair and right to start out with 'strong consistency on one site' and then
move onto 'full master/master replication across sites with eventual consistency and powerful
conflict resolution'. For many use cases you don't need anything other than 'one site' so
you can keep it simple. Surely that's more relaxing?

The issue here is that what most people don't completely understand
right away is that even a single site doesn't have strong consistency
guarantees once you get to replication. Regardless of multi-master or
whatever configuration, any use of replication can introduce conflicts
and what ends up happening is that people never realize this until its
a problem.

While we would be introducing a different default behavior, the old
version is a simple If-Match header away which would provide the same
behavior we currently have in a more standard HTTP model.

Also I should point out that until people have concurrent writers on a
single doc, this will behave much more like people have asked. Ie,
don't specify a revision and we'll automatically use the previous
value so that people don't have to GET the current doc just to
forcefully overwrite with a PUT.

> The 'strong consistency' message of Couchbase is actually rather compelling but when
you introduce cross site replication they don't have 'powerful conflict resolution' plus they've
thrown out most of CouchDB coolness. I fully understand the technical reasons for this but
as a developer I'm left thinking +2 for strong consistency and crazy performance but -10 for
loosing Couchapps, _changes, revisioning, REST, etc.
> Anyway I didn't write this to have a moan about Couchbase because I think it's pretty
awesome product when you view it as something completely different to CouchDB. The point I'm
really arguing is that strong consistency is simpler. In many cases CouchDBs current behaviour
provides strong consistency out of the box, but if you need to move into multi master replication
then CouchDB has the perfect tools to rescue you from what would otherwise be a world of pain.
> However, I agree that the developer should be able to choose the behaviour and be able
to write conflicting documents without having to use confusing options in the bulk API to
achieve it.
> Paul
> Sophos Limited, The Pentagon, Abingdon Science Park, Abingdon, OX14 3YP, United Kingdom.
> Company Reg No 2096520. VAT Reg No GB 991 2418 08.

As an aside, all_or_nothing as discussed earlier is not correct. This
setting is ~never used from my experience and even those of us that
know about it have a hard time describing what its for. It was only
ever added for non-technical reasons related to a different feature
that had to be removed.

The new_edits:false option is the option that allows writes without
calculating a new revision though which may or may not be necessary
given the new behavior.

View raw message