Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Received-SPF: pass (nike.apache.org: domain of paul.joseph.davis@gmail.com
 designates 209.85.220.180 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CABvT1DFKqt-=NWiBDULenOd8HHa9VFSrCWsdia_3_PmpONwL1Q@mail.gmail.com>
References: 
 <CAB5u=zXX0pKiBOfg+UcYopGbeE53=Npp+-vX8rNOqQOi1ty77Q@mail.gmail.com>
 <CABvT1DGdn+ib9Tc6-9Rb-11KDgo-_-eE6QBo_zPy=ZdwY2Wk1A@mail.gmail.com>
 <D60E7255-46AA-4B4E-AC94-15F6801AE50D@yahoo.com>
 <CAB5u=zX7ufhEb_7_+dhWS29=PQAeBiBYsPpzi8g6k+xo0MEPkg@mail.gmail.com>
 <CABvT1DFKqt-=NWiBDULenOd8HHa9VFSrCWsdia_3_PmpONwL1Q@mail.gmail.com>
From: Paul Davis <paul.joseph.davis@gmail.com>
Date: Thu, 22 Dec 2011 13:49:33 -0600
Message-ID: 
 <CAJ_m3YAWSeL5YowuG59tN2Tbjr56y9NgWVEO1mK4Z9tO-HTLDQ@mail.gmail.com>
Subject: Re: Is it possible to bring back optional old all-or-nothing
 behaviour?
To: dev@couchdb.apache.org
Content-Type: text/plain; charset=ISO-8859-1

On Thu, Dec 22, 2011 at 11:31 AM, Robert Newson <rnewson@apache.org> wrote:
> In my opinion, and I believe the majority opinion of the group, the
> CouchDB API should be the same everywhere. This specifically includes
> not doing things on a single box that will not work in a
> clustered/sharded situation. It's why our transactions are scoped to a
> single document, for example.
>
> I will also note that all_or_nothing does not provide multi-document
> ACID transactions. The batches used in bulk_docs are not recorded, so
> those items will be replicated individually (and in parallel, so not
> even in a predictable order), which would break the C and I
> characteristics on the receiving server. The old semantic would abort
> the whole update if any one of the documents couldn't be updated but
> the new semantic simply introduces a conflict in that case.
>

Slight nit pick, but new behavior just returns the error that the
update would *cause* the conflict. (Assuming default non-replicator
_bulk_docs calls.)

> B.
>
> On 22 December 2011 16:48, Alexander Uvarov <alexander.uvarov@gmail.com> wrote:
>> And can become much easier with multi-document transactions as an option.
>>
>> On Thu, Dec 22, 2011 at 10:43 PM, Pepijn de Vos <pepijndevos@yahoo.com> wrote:
>>> But not everyone needs a cluster. I like CouchDB because it's easy, not because "it scales", and in some situations, all_or_nothing is easy.
>>>

Robert mentions it in passing, but the biggest reason that we dropped
the original _bulk_docs behavior doesn't have anything to do with
clustering. It was because the semantics are violated as soon as you
try and replicate. Since there's no tracking of the group of docs
posted to _bulk_docs then as soon as your mobile client tried to move
data in or out you'd lose all three of ACI in ACID.

The follow up question that I had spent some time on was trying to
think of a way to *add* these bulk group indicators to solve this in
the replicator. As it turns out, the way our update_seq indices work
is fairly at odds with this grouping. When documents are updated, they
are moved to the new update_seq position. Without some major
reengineering of the core of couchdb (that directly relates to
replication) there isn't much that we can do here.

Generally speaking, my rule of thumb is that if you find yourself
wanting this feature then you're probably going to want to rethink
your application's architecture. When we went through this discussion
back in the 0.9 days I found myself spending a lot of time trying to
think of new designs that would save it. Then I slowly realized that I
just hadn't completely groked the replication/distribution model in
CouchDB.