couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ciprian Dorin Craciun <>
Subject Regarding `_bulk_docs` atomicity [Was: Re: How to find the change sequence of a document's revision]
Date Tue, 18 Dec 2012 22:15:07 GMT
On Tue, Dec 18, 2012 at 11:58 PM, Robert Newson <> wrote:
> I'll also note that there's no atomicity to a _bulk_docs request (even
> with all_or_nothing:true) except at the individual document level (as
> usual).

    Ok... This is troublesome...

    I understand the implications with replication and all, but there
could have been a third option "atomic" which rejects a write if
conflicts exist, but which should have a documented "unpredictable"
behaviour when used in conjunction with replication...

    But still there is a way to achieve an "almost-atomic" variant via
a validation hack:
    * I use "all-or-nothing" mode;
    * I make a design doc which requires that that the developer puts
in a fiel of the new JSON object, `$prev_rev`, which must be equal
with the `_rev` field of the previous document already stored;

    Thus conflicts could appear only if there are multiple write
requests targeting the same document, and they happen alsmost at the
same time. (As such if the updates are at a slower pace, the
probability of conflicts should be small.)

    Anyhow for my particular use case write atomicity is less
important than being able to have a "stable" "view" of the database.


View raw message