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.198.228 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=nzIPS+YmnRxOhuXnah4h8g6SN45B4pPyzUJMVipYzb9Ba0Wp3DcY+0bZy7PRg1cv6A
         2bItms4lYxt2p3qRzYbMQuq2inWtjMNAG6YyTK3VfIvXgEuIrn+P9DT1UHYWznUXclZh
         +iANESvidPtcIUG8nQixVr4ArjBRouqjyaeDk=
Message-Id: <2D9F641A-5397-4B15-86CA-7A6A992000AF@gmail.com>
From: Antony Blakey <antony.blakey@gmail.com>
To: dev@couchdb.apache.org
In-Reply-To: <46aeb24f0902161551pca716f8r5826aef73ee7db6c@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: Replication and forms of weak consistency
Date: Tue, 17 Feb 2009 11:08:09 +1030
References: <0FDDC57C-DB78-4241-86DE-549FECC8B558@gmail.com>
 <5B34C99E-DE0A-42FE-AC68-4C79A6754862@gmail.com>
 <e282921e0902152025p48e4055dxfcdd9cc1e54d694a@mail.gmail.com>
 <61D81FC2-F3FB-4DC9-969B-633AE1FA6E6A@gmail.com>
 <e282921e0902152125r7870b4b7xd8f4eb77ad5e484b@mail.gmail.com>
 <86408A84-A967-41C6-872B-F69403184A24@gmail.com>
 <46aeb24f0902160315s82a6e6fyc700907d5d4a0b88@mail.gmail.com>
 <72F60CE6-34B0-4C1A-A7AC-EF46A8F1E129@gmail.com>
 <46aeb24f0902161456y57e8db1fq70ac4ab5a5a93381@mail.gmail.com>
 <D3CD6837-7A6E-4336-8E00-66198AFAF211@gmail.com>
 <46aeb24f0902161551pca716f8r5826aef73ee7db6c@mail.gmail.com>


On 17/02/2009, at 10:21 AM, Robert Newson wrote:

> Ok, now I do understand. This matches my surprise at the replication
> strategy. Two partitioned nodes make local changes, they both
> cross-replicate, but each node does not have the full revision history
> of the other, they don't converge to the same state. The only promise
> is that the revision of each document will be the same at both nodes
> after successful, bi-directional replication. It's that behavior that
> breaks MW. I'm so used to replication using write-ahead logs (where
> all replicas see all intermediate states) that I have to consciously
> recall that CouchDB doesn't do that.

Hence my proposal to change it. Bayou shows that it possible to get a  
result that is easier to program against, with stronger weak  
consistency, and easier reasoning. PRACTI shows how to do that with  
partial replication.

And this can all be done whilst increasing performance e.g. lower  
bandwidth requirements, incremental progress, isolated write groups etc.

But it needs community support to be part of CouchDB (as opposed to a  
new project, forked).

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

There is nothing more difficult to plan, more doubtful of success, nor  
more dangerous to manage than the creation of a new order of things...  
Whenever his enemies have the ability to attack the innovator, they do  
so with the passion of partisans, while the others defend him  
sluggishly, So that the innovator and his party alike are vulnerable.
   -- Niccolo Machiavelli, 1513, The Prince.