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.230 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=jhRkSpdaGgBSbBGBrgmz4j7xB5dYFNMlQ0uvkoIDWbc3p2bNyGLI+W8gCja8urzBJv
         p9UuZ0e5p7RaVoLZt3ZukYApAzhFWXZiqPg2cm50Y+8ycWp/DWOJQdQaH4xEIpTAF/4D
         TV2sapc3z0iDexn7S9+U2aJiFo8STvTzrrAu0=
Message-Id: <987B2FFD-964D-4DD8-AC8C-C9B6060D64E5@gmail.com>
From: Antony Blakey <antony.blakey@gmail.com>
To: dev@couchdb.apache.org
In-Reply-To: <451872B8-152C-42A6-9324-DD52534D9A32@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: Sun, 8 Feb 2009 16:07:15 +1030
References: <84F66023-030A-4669-B75C-3DCC92D71A78@yahoo.com>
 <3B1EB33E-D224-43E2-9FDC-D7493CD5BFDD@pobox.com>
 <59473D22-6EA5-4CE2-A193-8F4938C2D6BB@apache.org>
 <82C6FE57-1BBA-4E71-BDA4-0A1522608FEC@pobox.com>
 <BCBBBDEC-BB49-4B9B-9630-4851DD0F84E3@apache.org>
 <B63ABF9B-9980-4559-BFEA-888644591CC6@gmail.com>
 <4E84FF76-444A-48F9-A6F1-837800BCB7C9@apache.org>
 <867439E1-D87A-4BCC-9732-94C1C6018B72@gmail.com>
 <F3E85261-0557-4EAA-982A-305A243061D5@apache.org>
 <AA192582-7452-4B82-9C80-BAF74E5A77E4@gmail.com>
 <C93B1C85-B1F2-4A2B-B97A-C1800D0A8086@apache.org>
 <13619B4B-F8F3-42F6-A18F-0ED07AFDE2D3@gmail.com>
 <451872B8-152C-42A6-9324-DD52534D9A32@apache.org>


On 08/02/2009, at 3:52 PM, Damien Katz wrote:

> No, CouchDB replication doesn't support replicating the  
> transactions. Never has, never will. That's more like transaction  
> log replication that's in traditonal dbs, a different beast.

So just to be clear, replication ignores MVCC? And there is therefore  
no way to achieve any form of consistency, even the weaker ACID you've  
proposed - which sounds like it's really only Durability. I presume it  
at least replicates according to update_seq? If so, would it be  
difficult to ensure that the update_seq that the replicator sees is  
always on an MVCC boundary? That would allow for transactional  
replication of the form I'm talking about.

> For the new bulk transaction model, I'm only proposing supporting  
> eventual consistency. All changes are safe to disk, but the db may  
> not be in a consistent state right away.

Or indeed, ever.

>> Not necessarily, and even if they did, it's likely that they'll  
>> have multiple browser windows open.
>
> What's the front end written in?

On OSX, an Objective-C app that	provides an embedded Safari connecting  
to an embedded Ruby/Merb admin server, although I'm thinking of  
changing to Yaws et al. That provides a traditional OS app, with a GUI  
that looks like iTunes, provided via HTML. The admin app can then  
replicate/download web applications written in e.g. Ruby (for now)  
which do the real work.

On Windows, something similar, I presume .NET/C++/Gecko. Discussed in  
the contract RFI I posted.

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

Human beings, who are almost unique in having the ability to learn  
from the experience of others, are also remarkable for their apparent  
disinclination to do so.
   -- Douglas Adams