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.132.240 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=QAWvUylfFXKGARqfRALWazQ7K1Rcs+H3plKwcv/GWC0NPUtB03ijjHixfMQFspf01R
         chF284kK/8sPdY88Q3rnpNsvuAX5Rr9qQml4sepEfV4CW6SjSu+5l8bxe7tjVmnlEjuR
         B6ld/dje2D/HhN14hxtqfllnSxuUtwCvwxROc=
Message-Id: <122ABEB4-4BC7-4EA6-A6A4-277107E15DA3@gmail.com>
From: Antony Blakey <antony.blakey@gmail.com>
To: dev@couchdb.apache.org
In-Reply-To: <49B8FD3F.4050706@timparkin.co.uk>
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: Bulk Docs
Date: Thu, 12 Mar 2009 23:44:20 +1030
References: <49B8FD3F.4050706@timparkin.co.uk>


On 12/03/2009, at 10:47 PM, Tim Parkin wrote:

> I noticed a commit that suggests "atomic" bulk docs will no longer be
> working on trunk. Is now the right time to discuss the possibility of
> keeping a version of "atomic" bulk docs somewhere in couchdb rather  
> than
> removing the functionality?
>
> I think I understand that there is a philosophical reason for not  
> having
> it in (I think the reasoning is "don't have features in couchdb that
> won't work distributed" but I may be wrong ) but I personally am of  
> the
> opinion that trying to hide the difference between a single couchdb  
> and
> network of couchdbs at the cost of removing functionality that has
> legitimate use is not a good idea.
>
> Anyway - I don't want to start a thread prematurely but also didn't  
> want
> to miss adding my opinion. I'm happy to hang fire on discussion until
> later though..

I agree that hiding the distinction between single-node and multi-node  
operation is not a good idea.

However I think this discussion has come and gone, the outcome being  
that a) couchdb requires, by design, that no functionality is provided  
that cannot be provided under a loosely couple cluster model without  
distributed transaction support; and b) therefore, atomic bulk docs  
e.g. all-or-nothing-fail-on-conflict will not be provided by couchdb.

I require this functionality, and don't care about *loosely coupled*  
clustering, and hence have to maintain a fork that retains this  
functionality. This fork cannot be called CouchDB unless it is purely  
a point-in-time snapshot from the subversion repository - anything  
else is regarded as a derived work by Apache, understandably.

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

Don't anthropomorphize computers. They hate that.