Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: pass (athena.apache.org: domain of jens@couchbase.com designates
 206.225.164.31 as permitted sender)
From: Jens Alfke <jens@couchbase.com>
To: "user@couchdb.apache.org" <user@couchdb.apache.org>
Date: Thu, 23 May 2013 17:13:12 -0700
Subject: Re: using POST _bulk_docs with ?edits=false
Thread-Topic: using POST _bulk_docs with ?edits=false
Thread-Index: Ac5YE3sSnwVcSdNKQXGtAmQkHVwYjw==
Message-ID: <7BAA2E80-6B36-43AB-BEC3-10915D2719B5@couchbase.com>
References: <116DF3F19DB44CF9AB36993A20398CBA@martynus.net>
In-Reply-To: <116DF3F19DB44CF9AB36993A20398CBA@martynus.net>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0


On May 23, 2013, at 1:28 PM, Gregor Martynus <gregor@martynus.net> wrote:

> I'm using the edits=3Dfalse flag to push changes from the browser to the =
couch, to prevent that data can get lost.

Are you _sure_ you want to do that? It can create conflicts. Regular PUTs w=
on=92t lose data; the 409 Conflict error is to alert the client that there=
=92s a newer revision on the server, so the client can do the necessary con=
flict resolution and then retry. It=92s generally better to handle conflict=
s before they=92re saved, rather than afterwards, because you=92re more fle=
xible in how to interact with the user.

> My current implementations randomly generates a _rev number and adds the =
_revisions attribute with the current _rev and the newly generated _rev num=
ber. But that leads to conflicts. I was told that the _rev number has to be=
 calculated based on the objects.

Don=92t make up your own revIDs! If you really, really want to create confl=
icts on the server, use the all_or_nothing mode of _bulk_docs instead:
	http://wiki.apache.org/couchdb/HTTP_Bulk_Document_API#Transactional_Semant=
ics_with_Bulk_Updates

=97Jens=