Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Received-SPF: pass (athena.apache.org: domain of antony.blakey@gmail.com
 designates 209.85.219.12 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=trkUvzTr3XTOrEMdYJwPkm1e1o4FAOvOAuOogdf1y3n+48m6da1hNcJQ0CeIZek3I5
         dCEFHlzRCRz+4yX6EPW5BTIcZJLp+WImvX4BkgYh02rp6IKwnJ684LkMHnvBrHK6D1uF
         y29J8b3wFnLxdZatOntXEC8C3yZyDBdi7ItMk=
Message-Id: <B108A357-F1A2-4CF3-867B-69C38EEB3247@gmail.com>
From: Antony Blakey <antony.blakey@gmail.com>
To: dev@couchdb.apache.org
In-Reply-To: <e2111bbb0902091600v688130d5te47c8e5fd87bce3a@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: couchdb transactions changes
Date: Tue, 10 Feb 2009 10:59:18 +1030
References: <84F66023-030A-4669-B75C-3DCC92D71A78@yahoo.com>
 <3233C6E1-B613-4A39-AA4C-D46743C60981@gmail.com>
 <D94440D6-40DD-447F-8AC7-3A1442F6EE55@gmail.com>
 <e2111bbb0902090823h43bcf918ge329916cd5e310e9@mail.gmail.com>
 <A1BCBE02-893D-40EA-B242-A10292B4287F@gmail.com>
 <e2111bbb0902090935m799be568j16f7e9324bb01ef2@mail.gmail.com>
 <54602F24-6517-459F-98DB-1A934A98A3B8@gmail.com>
 <D3A11D36-6555-4D32-8610-9425B222478C@gmail.com>
 <8CC336DF-241D-4E79-960D-763E43D4B484@apache.org>
 <EF4161F9-E211-439C-BCE5-219CE506EF43@gmail.com>
 <e2111bbb0902091600v688130d5te47c8e5fd87bce3a@mail.gmail.com>


On 10/02/2009, at 10:30 AM, Paul Davis wrote:

>> Compaction and revision stemming (which is required to avoid  
>> unbounded
>> growth) make intermediate states inconsistent because they can  
>> delete either
>> the data of a document rev or the document rev itself. In the face of
>> compaction, it's possible for consistency to only be achieved when  
>> the
>> replication reaches the same MVCC commit point that the compaction  
>> was
>> operating against. Revision stemming has a similar effect, although  
>> it has
>> the further issue of being automatic i.e. not scheduled.
>>
>> That's ignoring replication failure, either temporary or permanent,  
>> which
>> further complicates the picture. Given that intermediate states are  
>> not
>> necessarily consistent, anything that leaves you in an intermediate  
>> state
>> without a way forward, repudiates the guarantee of Eventual  
>> Consistency.
>>
>
> I'm pretty sure the rest of this is wrong though.

I mean no offense, but I'm looking for something more than 'pretty  
sure'. I'm trying to work through these issues so that I understand  
the formal model and design intention completely and properly.

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

Borrow money from pessimists - they don't expect it back.
   -- Steven Wright