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 ciprian.craciun@gmail.com
 designates 209.85.215.180 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CABvT1DFMpryhr3w05xW_6hgbJXODSehcLCVPGMU_DoAh+pMyTA@mail.gmail.com>
References: 
 <CA+Tk8fx+g+F1wDbF4xmSK9TDG6cEYkunNGhUB2nTUDosHREBDw@mail.gmail.com>
	<14FC9F1D-8CD8-46B5-BC84-703EEC4128C3@couchbase.com>
	<CABvT1DFgTaqHxG_pov8ftXtC3PCTpu3UqmRgBXXJ5-L=5tz7Cw@mail.gmail.com>
	<FD792861-7B0B-4FE7-9B07-2E1ED6CB6BCE@couchbase.com>
	<CABvT1DFTpzXGRPRXh8rw02hdF1tNL0f84rQJyDF1nLkPbMYCpg@mail.gmail.com>
	<CABvT1DFMpryhr3w05xW_6hgbJXODSehcLCVPGMU_DoAh+pMyTA@mail.gmail.com>
Date: Sun, 23 Dec 2012 12:06:25 +0200
Message-ID: 
 <CA+Tk8fzQ9cOY-J8-8reTP=y5wxTA5dC3qy4-3oN_6FWRbNh88g@mail.gmail.com>
Subject: Re: Regarding `_bulk_docs` atomicity [Was: Re: How to find the change
 sequence of a document's revision]
From: Ciprian Dorin Craciun <ciprian.craciun@gmail.com>
To: user@couchdb.apache.org
Content-Type: text/plain; charset=UTF-8

On Sun, Dec 23, 2012 at 11:06 AM, Robert Newson <rnewson@apache.org> 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
semantics.)

    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.)

    Ciprian.