> 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 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.
