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 antony.blakey@gmail.com
 designates 209.85.198.234 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:from:to:in-reply-to:content-type
         :content-transfer-encoding:mime-version:subject:date:references
         :x-mailer;
        b=OMPzwyD/hUWtKEcOCPRMoG6IslaKTm8fn6JwgPmRzwXcKStclFda1VwgX5jgyOCH2d
         MbQ03CPsezYxs9wHyTco5MCF5ivJ4BStDc5b4hvgjRdQAbkGLYMZt/MDuRBo/mV64/R+
         jID2l7+wbFud2Y0mzSW5eMViI3HBm7FE0UBGs=
Message-Id: <D90811EC-ED32-4C7A-9E77-9A0408CCCC30@gmail.com>
From: Antony Blakey <antony.blakey@gmail.com>
To: dev@couchdb.apache.org
In-Reply-To: <e2111bbb0902052113p54b5bd8tc8610a20be3b610e@mail.gmail.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v930.3)
Subject: Re: Transactional _bulk_docs
Date: Fri, 6 Feb 2009 16:40:42 +1030
References: <BC4993A1-5DE9-43B6-AA57-4D2362EA72CE@gmail.com>
 <11E11144-004D-45B8-A503-88FD471953D7@apache.org>
 <9C8B5F07-856F-495D-AD91-FCA5AB5E31FF@pobox.com>
 <4E507D2E-88F9-4591-B721-F4343ACA9A9E@apache.org>
 <393666B7-8444-4D23-A2BA-AD59652A96AE@sauria.com>
 <BF0132C0-ACC7-4A5C-BE68-4E41AE20373C@apache.org>
 <0D17D25F-7E88-4F19-96A9-62FC81E2DFC5@pobox.com>
 <D89DB717-DAF3-4120-A36B-85EE489A0388@apache.org>
 <e282921e0902051150g2aeda88fr2789f9f19468b30c@mail.gmail.com>
 <AD2B7889-803E-4ABF-AA23-3DBA9337A834@gmail.com>
 <e2111bbb0902052113p54b5bd8tc8610a20be3b610e@mail.gmail.com>

I'm not keen on prolonging this agony, but I am going to respond to  
these points.

On 06/02/2009, at 3:43 PM, Paul Davis wrote:

> A brief history:
>
> 1. The mythical IRC conversation on 'removing' the feature: (roughly  
> quoted)

It wasn't mythical - Damien has stated that is what happened. Why do  
you use the word 'mythical'?

> Damien: I don't think we can support transactional commits in the face
> of multiple nodes. We can do ACID writes to disk so that updates
> aren't lost, but checking with an unbounded number of servers that a
> commit doesn't conflict isn't feasible.

Not unbounded. Look at Scalaris. And in any case, what exactly is this  
multi-node mode? Why compromise the API for something that is so  
ephemeral that conflict management isn't feasible? What IS feasible?  
View consistency? MVCC semantics. If I write a document and then read  
it, do I maybe see an earlier document. What about in the view?  
Because if views are going to have a consistency guarantee wrt.  
writes, then that looks to me like distributed MVCC. Is this not 2PC?  
And if views aren't consistent, then why bother? Why not have a client  
layer that does content-directed load balancing.

Regardless, this discussion is also about whether supporting a single- 
node style of operation is useful, because CouchDB had an ACID  
_bulk_docs. IMO it's also about, the danger/cost of abstracting over  
operational models with considerably different operational  
characteristics - c.f. transparent distribution in object models.

> Everyone else: That's pretty reasonable.

Everyone == ? Damien told me explicitly that this change was decided,  
and that decision was made on IRC.

What's with this revisionist history Paul?

> 2. A patch was applied to trunk that made commits to CouchDB
> optionally ACID compliant (which gives users the traditional
> speed/safety choice) as well as removing the atomic 'all or none'
> semantics.

If it's not all or none then it's not ACID with respect to the user  
data model. Conflicts are a metadata feature.

> Near as I can tell Damien has been nose to the grindstone for quite
> some time on this very specific part of the api. Would I like more
> status updates and ideas on where he's heading? Of course. Do I trust
> him? Yes. Is the community as a whole going to blindly accept some
> asinine patch that has no value that removes a crap load of
> functionality? No.

Is the PMC going to accept some massive patch that has significant  
benefit, but as a side effect removes a key feature, for no good  
technical reason? That's what is happening. Damien's patches are  
neither asinine, nor of no value. On IRC Chris Anderson noted in  
response to a question that Damien has a heap of changes coming, but  
that we (the community) have to wait and see what they are.

> I tend to think that the 'discussion' that everyone keeps referring to
> hasn't even occurred yet. I look at the patch that was applied that
> caused this as an unfortunate early release.

And if commits don't represent some sort of decision, what are they? I  
saw the patch, thought WTF?, asked about it, and was eventually told  
that yes, a decision had been made that the ACID API was being removed.

> Admissions first: I have no money riding on this issue. Whether or not
> CouchDB has transactional _bulk_docs worries me not at all. Though, I
> can't say that I have that much sympathy for a business model that
> relies on an open source project's trunk to remain compatible with
> required assumptions.

Having an ACID guarantee explicitly stated, and then removed with no  
replacement, is not a 'required assumption' on my part. ACID is a big  
deal.

And in any case, my 'business model' response is to fork CouchDB,  
which is the appropriate response. But still, do you want people to  
use this project or not? Promote it or not? What message does that send?

> Reductio ad absurdum:

That's about right.

Antony Blakey
--------------------------
CTO, Linkuistics Pty Ltd
Ph: 0438 840 787

Don't anthropomorphize computers. They hate that.