incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Goodall <matt.good...@gmail.com>
Subject Re: Update conflicts?
Date Wed, 06 Apr 2011 12:20:41 GMT
On 5 April 2011 22:46, Luis Miguel Silva
<luismiguelferreirasilva@gmail.com>wrote:

> Dear all,
>
> I'm trying to play around with updates and i'm bumping into some problems.
>
> Let's image we have to clients that poll a document from the server at
> the same time and get the same _rev.
> Then one of them updates the doc based on the _rev it got:
> [root@xkitten ~]# curl -X PUT -d
> '{"_rev":"3-0d519bcf08130bf784f3c35d79760740","hello2":"fred2"}'
> http://localhost:5984/benchmark/test?conflicts=true
> {"ok":true,"id":"test","rev":"4-03640ebafbb4fcaf127844671f8e2de7"}
> Then another one tries to update the doc based on the same exact _rev:
> [root@xkitten ~]# curl -X PUT -d
> '{"_rev":"3-0d519bcf08130bf784f3c35d79760740","hello3":"fred3"}'
> http://localhost:5984/benchmark/test?conflicts=true
> {"error":"conflict","reason":"Document update conflict."}
> [root@xkitten ~]#
>
> Is there a way to avoid this?! (like...make the update just create a
> new _rev or something)??
>
> Ideally, we would be able to update without specifying the _rev, just
> posting (or, in this case PUTting) to the document...
>
> Thoughts??
>
>
I hope I haven't missed this suggestion in the thread, but here goes ...

Another option, depending on your application, is to "force" the update to
the document through and worry about conflicts later.

If you use CouchDB's bulk update facility with the all_or_nothing=true
option then your document will always be stored but may be marked as a
conflict in the database. When a conflict does happen CouchDB chooses a
winning version and stores the rev(s) of the loser(s) in the document's
_conflicts attribute. But whatever happens, the update will not return an
error to your application.

Depending on the application conflicts can then be ignored or require
intervention to fix. Sometimes the fix can be automated. Conflicts are easy
to find: either poll a view that emits any doc with a _conflicts attribute
or watch a _changes feed with a filter that returns only the docs with
_conflicts.

Finally, once you know the id of a document containing conflicts you can
find out exactly when the conflicts happened by GET'ing it with a
conflicts=true option and inspecting the _conflicts attribute.

I realise there's a lot to take in there so the following wiki pages are
probably essential reading:

* Bulk update API, http://wiki.apache.org/couchdb/HTTP_Bulk_Document_API.
Specifically the "Transactional Semantics with Bulk Updates" section.

* Document API, http://wiki.apache.org/couchdb/HTTP_Document_API. Contains
information on the conflicts=true option and the attributes in a document
that describe the conflicting versions.

* Changes API, http://wiki.apache.org/couchdb/HTTP_database_API#Changes.


Note: One advantage of using CouchDB like this is that once you start using
replication these conflicts can happen anyway. However, you've already
solved the problem of resolving conflicts so it doesn't really make any
difference because your application was written to expect conflicts from the
start.


Hope that all makes some sense!


- Matt

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message