incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dennis Clark <dbfcl...@gmail.com>
Subject Re: Update conflicts?
Date Tue, 05 Apr 2011 23:56:06 GMT
I believe (speaking somewhat out of turn here; I don't really know with
certainty) that update handlers can run in parallel. My understanding is
that they save documents in exactly the same way clients do, that is,
wholesale with a _rev -- it just happens that the update function gets the
old document complete with _rev when it's called. As such, if hypothetically
you had two updates, super_quick and takes_forever, and hit the second one
before the first one, the first one might finish first, leaving
takes_forever with a stale _rev by the time it tries to save.

I can't easily think of a use case where this actually matters, though,
given that update handlers tend to be computationally light.

On Tue, Apr 5, 2011 at 7:47 PM, Sean Copenhaver
<sean.copenhaver@gmail.com>wrote:

> Very cool. I honestly haven't had the need for updates yet so I only know
> that they exist. Good to know that you could basically do your own merging
> in an update.
>
> You mentioned that the first update function could finish during the
> second? I thought the writes in CouchDB were serial, so do update functions
> actually run in parallel and then the new/updated doc is put in the write
> queue?
>
> --
> Sean Copenhaver
>
> On Tuesday, April 5, 2011 at 7:32 PM, Dennis Clark wrote:
> > Actually no -- if you put to an update handler with an existing docid,
> the
> > handler gets a full copy of the then-current doc, _rev and all. As such,
> the
> > version conflict doesn't happen before the update function unless the
> first
> > update function completes during the operation of the second. This means
> > that you can use them for a counter (say) without requiring your clients
> to
> > know document _rev's, as in:
> >
> >
> http://stackoverflow.com/questions/2972068/couchdb-document-update-handlers-in-place-updates
> >
> > On Tue, Apr 5, 2011 at 7:19 PM, Sean Copenhaver
> > <sean.copenhaver@gmail.com>wrote:
> >
> > > Keep in mind that besides both being doc db's they are very different
> > > products.
> > >
> > > Also I'm not positive how far update functions can go. I believe the
> > > version conflict happens before your update function.
> > >
> > > You should evaluate if you are trying to use couchdb too much like the
> > > average relational db. Also think about if you can break up the docs in
> an
> > > appropriate way to avoid the conflicts.
> > >
> > >
> > >
> > > On Apr 5, 2011, at 7:12 PM, Dennis Clark <dbfclark@gmail.com> wrote:
> > >
> > > > What's your actual function? Update functions should work fine for
> your
> > > use case, but can be a little finicky to get working, particularly the
> first
> > > time.
> > > >
> > > > On Apr 5, 2011, at 7:01 PM, Luis Miguel Silva <
> > > luismiguelferreirasilva@gmail.com> wrote:
> > > >
> > > > > Thank you! I'll probably have to evaluate it then...
> > > > >
> > > > > I've looked at the update handlers but i can't get them to work
> :o\...
> > > > > I'm creating a _design document with a "updates" field with an
> update
> > > > > function inside but i can't seem to get it to work.
> > > > >
> > > > > Either way, i think it's time i evaluate MongoDB :o((... (this was
> > > > > unexpected, i was completely sold on CouchDB :o|).
> > > > >
> > > > > On Tue, Apr 5, 2011 at 4:50 PM, Sean Copenhaver
> > > > > <sean.copenhaver@gmail.com> wrote:
> > > > > > Ah, the problem is that couchdb does not do partial updates.
It
> writes
> > > the whole doc. MongoDB I believe does support partial updates though.
> No
> > > experience with it.
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Apr 5, 2011, at 6:41 PM, Luis Miguel Silva <
> > > luismiguelferreirasilva@gmail.com> wrote:
> > > > > >
> > > > > > > More or less!
> > > > > > >
> > > > > > > The most common scenario will be:
> > > > > > > - two or more processes writing to the same document, but
only
> to a
> > > > > > > specific attribute (not overwriting the whole document)
> > > > > > >
> > > > > > > If, by any chance, two processes overwrite the same field,
i'm
> ok with
> > > > > > > the last one always winning.
> > > > > > >
> > > > > > > Thanks,
> > > > > > > Luis
> > > > > > >
> > > > > > > On Tue, Apr 5, 2011 at 4:26 PM, Robert Newson <
> > > robert.newson@gmail.com> wrote:
> > > > > > > > "Ideally, we would be able to update without specifying
the
> _rev,
> > > just
> > > > > > > > posting (or, in this case PUTting) to the document..."
> > > > > > > >
> > > > > > > > So you want to blindly overwrite some unknown data?
> > > > > > > >
> > > > > > > > B.
> > > > > > > >
> > > > > > > > On 5 April 2011 22:57, Zachary Zolton <
> zachary.zolton@gmail.com>
> > > wrote:
> > > > > > > > > Luis,
> > > > > > > > >
> > > > > > > > > Checkout _update handlers:
> > > > > > > > >
> > > > > > > > > http://wiki.apache.org/couchdb/Document_Update_Handlers
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > Cheers,
> > > > > > > > >
> > > > > > > > > Zach
> > > > > > > > >
> > > > > > > > > On Tue, Apr 5, 2011 at 4:46 PM, 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??
> > > > > > > > > >
> > > > > > > > > > Thank you,
> > > > > > > > > > Luis
> >
>

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