couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sean Copenhaver <>
Subject Re: Update conflicts?
Date Wed, 06 Apr 2011 15:11:30 GMT
I thought list and show functions could return whatever format of data you
wanted? Not just HTML.

So you could split out the document into pieces to avoid the conflicts and
use a view to retrieve the related bits, then a list function to generate
out the final json document. At least that's my understanding.

Also I would be careful about the forcing conflicts. The document you want
may not be picked as the winner and if you are quickly relying on it that
could cause some undesirable effects. I would suggest understanding how
conflict "winners" are picked by couch. I personally only have a high level
understanding of this whole conflict resolution and the effects of such, but
the wiki has some information. You may want to check out the "View Map
Functions" and the following sections:

I honestly think you might want to tackle the problem with document design
and transformation with show/list functions first though.

On Wed, Apr 6, 2011 at 8:20 AM, Matt Goodall <> wrote:

> On 5 April 2011 22:46, Luis Miguel Silva
> <>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,
> Specifically the "Transactional Semantics with Bulk Updates" section.
> * Document API, Contains
> information on the conflicts=true option and the attributes in a document
> that describe the conflicting versions.
> * Changes API,
> 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

“The limits of language are the limits of one's world. “ -Ludwig von

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