Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
Message-Id: <8438304D-644D-48F8-A7D1-5D1853BC2578@apache.org>
From: Damien Katz <damien@apache.org>
To: dev@couchdb.apache.org
In-Reply-To: <D4BFC5FA-0B05-4641-B4DB-55890C5B92A8@apache.org>
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: couchdb transactions changes
Date: Sat, 7 Feb 2009 11:09:17 -0500
References: <84F66023-030A-4669-B75C-3DCC92D71A78@yahoo.com>
 <D4BFC5FA-0B05-4641-B4DB-55890C5B92A8@apache.org>


On Feb 7, 2009, at 11:04 AM, Jan Lehnardt wrote:

> Hi Damien,
>
> On 7 Feb 2009, at 16:47, Damien Katz wrote:
>
>> So I propose supporting 2 different transaction models:
>>
>> [...]
>>
>> With these 2 transactions models, it's possible to deploy the same  
>> apps on a single machine or a huge partitioned cluster. To support   
>> the current model, it's only possible to deploy apps on a single  
>> machine. I propose we drop the current model as bulk transactions  
>> are not supportable in clustered or replicated set ups.
>
> To be absolutely clear:
>
> You propose to drop the old behaviour in favour of the two
> new ones that get their own distinct API endpoints (which
> are to be  determined). The user could then choose which
> type of trade-offs to take by choosing one of the endpoints.
>
> You are _not_ proposing to drop the old behaviour and we
> now have to decide on one of the two new behaviours to
> replace it.

I am proposing removing the old behavior completely, in favor of the  
two new ones, which will be selectable by the client.

>
>
> Is that correct?
>
> Cheers
> Jan
> --
>