couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matthieu Rakotojaona <matthieu.rakotoja...@gmail.com>
Subject Re: Making conflicts first class citizens
Date Wed, 18 Apr 2012 19:28:29 GMT
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

Mime
View raw message