couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Newson <>
Subject Re: Regarding `_bulk_docs` atomicity [Was: Re: How to find the change sequence of a document's revision]
Date Sun, 23 Dec 2012 11:10:31 GMT
Writes to a couchdb database are serialized, yes. There's one process
per database which holds the file descriptor itself. Obviously that
doesn't apply when you move up to BigCouch. The evaluation order of
the validation function is document id order, but all docs will be
validated before the decision is made to abort the write.

A meta-point, is that the precise semantics of all_or_nothing:true,
and uses of it, are at least partially stepping away from a core
notion in CouchDB, that we're document-oriented, that we consciously
don't provide group update semantics, knowing that they are difficult
to scale.

Anyway, Xmas lecture over. :) I think, as long as you avoid
replication, then your hack will work with current all_or_nothing:true
behavior, I just worry that you're avoiding embracing the document
model by doing so.


On 23 December 2012 10:43, Ciprian Dorin Craciun
<> wrote:
> On Sun, Dec 23, 2012 at 12:33 PM, Robert Newson <> wrote:
>> The above output confirms that doc1 is not created because doc3 failed
>> validation. So, this is atomic across the group. But note that this
>> only applies to validation. If doc3 had not caused the commit to
>> abort, then doc1 and doc2 would both have been updated as well, even
>> if this introduces a conflict.
>> So, to take this back to the first post in the thread, all_or_nothing
>> doesn't provide the semantics you need, because it will introduce
>> conflicts rather than abort. The 0.9 and earlier behavior did provide
>> the semantics you need.
>     On the contrary, as I've written in my initial email, if the
> validation is able to abort the entire commit I could do the following
> "hack" (citing from my first email):
> ~~~~
>     * I use "all-or-nothing" mode;
>     * I make a design doc which requires that that the developer puts
> in a field of the new JSON object, `$prev_rev`, which must be equal
> with the `_rev` field of the previous document already stored;
> ~~~~
>     Shouldn't this work? (To my understanding it should achieve what I
> want as long as I control both the documents put in and the design
> document.)
>     But still there is the question of concurrent bulk writes:
>     * are they executed sequentially?
>     * or is the document validation function executed sequentially for
> the same document?
>     Because if there is a race condition for the same document
> validation my "hack" won't work...
>     Thanks,
>     Ciprian.

View raw message