Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1278)
Subject: Re: Atomicity with _update handlers?
From: Robert Newson <rnewson@apache.org>
In-Reply-To: 
 <CAJY4aWGHwGeS4xiv9fvXNqL0K=SGpOk1PSA0NA0a4XdJT_6LtQ@mail.gmail.com>
Date: Thu, 19 Jul 2012 23:20:59 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <5FC64674-B32F-4B60-8EA0-E4F34480DC18@apache.org>
References: 
 <CAJY4aWGHwGeS4xiv9fvXNqL0K=SGpOk1PSA0NA0a4XdJT_6LtQ@mail.gmail.com>
To: user@couchdb.apache.org


An update to a couchdb document is atomic, whether done directly or via =
an update handler. An update handler can fail with a 409 just the same =
as a direct update can. The only difference between the two update =
methods is where the logic runs. The update handler is merely returning =
the new document to couchdb, the actual update occurs after the function =
has returned (and can fail).

B.

On 19 Jul 2012, at 22:09, Andrew Melo wrote:

> Hello all,
>=20
> The documentation is a bit unclear on this, but basically I was
> wondering what sort of atomicity guarantees exist for _update
> handlers. Suppose I have documents that look like this
>=20
> { 'states' : [ { 'oldstate' : 'created', 'newstate' : 'new' } ] }
>=20
> And an update handler that looks like this (probably not the exactly
> right syntax)
>=20
> function (doc, req) {
>  // check that the requested old state equals the previous new state
>  if doc.states[ len(doc.states) ]['newstate'] =3D=3D =
req.query['oldstate'] {
>     // update the document, adding a new state to the end of =
doc.states
>  } else {
>     // barf back to the user
>  }
> }
>=20
> Is there a guarantee that concurrent requests to the same instance
> can't end up with a garbled ordering of states?
>=20
> Thanks,
> Andrew
>=20
> --=20
> --
> Andrew Melo