couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ciprian Dorin Craciun <>
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:06:25 GMT
On Sun, Dec 23, 2012 at 11:06 AM, Robert Newson <> wrote:
> It's been my view for some time that this option should be removed.
> BigCouch doesn't support it, so unless some extraordinary effort is
> made during the merge, it'll go away at that point.

    Couldn't the CouchDB team adopt a little different approach to
such "items" (the (B) choice from below):

    (A) One direction which I feel CouchDB is going towards is going
for the "common denominator" between most possible CouchDB-like
implementations. That is because some things are hard to be
implemented in a distributed environment (like BigCouch), or some
other things might be hard to implement in an embedded environment
(like TouchDB), such options are gradually being "eliminated" from the
CouchDB API.

    (B) Another option -- one that I would prefer -- is going with
something like "capabilities", where for some operations the user
explicitly asks what "capabilities" to be enabled or disabled, and if
a particular implementation doesn't support them it should fail the
request. This would allow some implementations to expose more (or
less) functionality than others. (Of course such a "solution" should
be applied with care, or it'll generate a miriad of possible

    Thus strictly related with the bulk operations atomicity, I would
see it like this:
    * the `all_or_nothing` option should be kept;
    * its default value should be the most generic one -- the one
giving the least promises;
    * each CouchDB implementation could choose to disallow certain values;

    (This is because in my particular case I want to use only the
"standard" single-instance / no-replication CouchDB.)


View raw message