On Wed, Apr 18, 2012 at 9:49 AM, Paul Hirst <[email protected]> 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.
