If I understand things well, the `all_or_nothing:true` parameter does 2 things :
* ensure that all the updates pass the validation, push them one after the other to the db, and if any of them fails, 'rollback' to before the try * store all the conflicts I see 2 problems with that : First, the parameter name is misleading : it makes a newcomer think that all the documents will be stored, or nothing will be, which is the 1st point. But storing the conflicts seems out of the scope; it would be more logical to use something like "everything_or_nothing" to care about documents AND conflicts, or "all_or_none" to care only about documents. After all, this is called with the `_bulk_docs` resource. Second, the storing of all the conflicts by default only happen when using `aIl_or_nothing`. In the CAP triangle, couchDB sacrifices Consistency to provide Accessibility and Partition Tolerance. If you sacrifice Consistency, you WILL generate conflicts; It is the rule, not the exception, just like in the gist. At the moment, if one wants to (properly) modify a doc, he has to get the current version of a document before storing it (by specifying the correct _rev he wants to update). But as the db might not be consistent, the version he gets might not even be a correct one. Moreover, it requires 2 operations for a write (althought I couldn't tell if this is an actual standard in other db usage). So even if he thinks there is no conflict with the server he is writing to, there might be conflicts with other nodes. >From this point of view, I think that couchDB should store conflicts on every modification, and tell the client if there are conflicts after a write, for instance by adding a `has_conflicts:true` parameter to the returned json if needed. When the application receives this, the user can be immediately informed and a process can be started to choose the right revision, but only if needed : other conflicts might occur when he replicates from an other database. -- Matthieu RAKOTOJAONA
