incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ciprian Dorin Craciun <ciprian.crac...@gmail.com>
Subject Re: Regarding `_bulk_docs` atomicity [Was: Re: How to find the change sequence of a document's revision]
Date Sun, 23 Dec 2012 10:43:06 GMT
On Sun, Dec 23, 2012 at 12:33 PM, Robert Newson <rnewson@apache.org> 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.

Mime
View raw message