couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Hirst <>
Subject RE: Making conflicts first class citizens
Date Wed, 18 Apr 2012 14:49:53 GMT
> 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 '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


Sophos Limited, The Pentagon, Abingdon Science Park, Abingdon, OX14 3YP, United Kingdom.
Company Reg No 2096520. VAT Reg No GB 991 2418 08.

View raw message