From dev-return-2353-apmail-couchdb-dev-archive=couchdb.apache.org@couchdb.apache.org Sun Feb 08 06:28:17 2009 Return-Path: Delivered-To: apmail-couchdb-dev-archive@www.apache.org Received: (qmail 99200 invoked from network); 8 Feb 2009 06:28:17 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 8 Feb 2009 06:28:17 -0000 Received: (qmail 41870 invoked by uid 500); 8 Feb 2009 06:28:16 -0000 Delivered-To: apmail-couchdb-dev-archive@couchdb.apache.org Received: (qmail 41838 invoked by uid 500); 8 Feb 2009 06:28:16 -0000 Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@couchdb.apache.org Delivered-To: mailing list dev@couchdb.apache.org Received: (qmail 41825 invoked by uid 99); 8 Feb 2009 06:28:16 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 07 Feb 2009 22:28:16 -0800 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of antony.blakey@gmail.com designates 209.85.200.174 as permitted sender) Received: from [209.85.200.174] (HELO wf-out-1314.google.com) (209.85.200.174) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 08 Feb 2009 06:28:06 +0000 Received: by wf-out-1314.google.com with SMTP id 28so1538620wff.29 for ; Sat, 07 Feb 2009 22:27:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer; bh=eHn8J0vsquuEEncHqtEDpEhKHvkcWGM+f1PO21c+hPw=; b=tvZSVogAScBTYg/UL038NX2S179nf89tHZ/ENZO0DsVTU2yrJUr3ftfrSiFaOR3RoR J4/cjkB0fwfnE2w8+WRJtaP9x3YiR9jB/LdA2D9YThr8yHXfsRHPsTqT8GT+J3vZkto6 4Ct1yP4x8yFbecQQ1Aa3NIeCm938ICsmr87TQ= 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=U03/UbgHKbApo6XBdSlhQSRAWU5HaYjNq2SN5RkfXOVkvWNBWMsp7SymeTUVRxZpNB iZ3KDRMqKHC6p4zn4TYNIuABIjsP1+zqWEMAfQfyCqdTH04NBQQpUyat2H9upkMysTbH 90jqDuwHbvkoUP0fJ0I9UiINk4zkG2jRDMYj0= Received: by 10.143.9.11 with SMTP id m11mr2096414wfi.44.1234074465379; Sat, 07 Feb 2009 22:27:45 -0800 (PST) Received: from ?192.168.0.16? (ppp121-45-202-232.lns10.adl2.internode.on.net [121.45.202.232]) by mx.google.com with ESMTPS id 31sm7682670wff.36.2009.02.07.22.27.43 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 07 Feb 2009 22:27:44 -0800 (PST) Message-Id: <7FAF8167-00FA-4945-86A6-08DEEF32F378@gmail.com> From: Antony Blakey To: dev@couchdb.apache.org In-Reply-To: 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:57:40 +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> <4E84FF76-444A-48F9-A6F1-837800BCB7C9@apache.org> <867439E1-D87A-4BCC-9732-94C1C6018B72@gmail.com> X-Mailer: Apple Mail (2.930.3) X-Virus-Checked: Checked by ClamAV on apache.org I think discussion of this issue is complicated by the lack of a clear exposition of the different ways in which CouchDB may be used/ deployed. I have the following in mind: --------------------------------------- A. A single-node database engine embedded in a desktop application. B. A single-node database server. C. A multi-node clustered database server. Furthermore it might have: D. No replication or replication from the app purely for backup. No conflict is possible. E. Replication from a distinguished peer that accepts write operations e.g. a content/query distribution mechanism. No conflict is possible. F. Replication in a p2p mesh e.g. collaborative content management. Conflict is possible. Then, in a non-orthogonal way, conflicts are dealt with: G. Not at all because they can't arise. H. Replication is under user control, and exclusive with 'normal' operation. Conflict resolution is only caused by replication, said conflicts being resolved by the user using a specialized UI/Workflow. Normal operation sees no conflicts. I. Replication is concurrent with normal operation, and may or may not be under user control. Normal operation sees conflicts. --------------------------------------- I have a pending deployment project of type A/E/G, and pending projects of types A/F/H and B+A/E/G. In all my cases, update and indexing throughput is not an issue, although replication efficiency, especially of incremental updates to attachments, is a concern. I understand that there is a sense in which CouchDB was on a trajectory pre-Apache to be C/F/I, but I wonder if the desire to achieve that isn't *unnecessarily* at the expense of other deployment models. In particular, some of these sound like a Notes client, and I have heard CouchDB promoted as 'Notes done right', hence my focus on those kinds of use cases (as opposed to high-throughput db servers). IMO it would be a good thing to not burden these other use cases with the operational cost of supporting just one of them. Obviously supporting transactions in a partition-based cluster can impose a cost (although only if the transaction spans the cluster in some way, the probability of which is potentially lessened by the partitioning), but what if one could turn them off via configuration? From what Damien has said about replication, I'm getting the idea that it is possible to do replication on an MVCC boundary, in the same way that a view represents an MVCC boundary, although I hear loud and clear that CouchDB has never, ever, claimed that replication works in that manner. The benefit of a transactional API vs. a conflict based API, for local operations, is not only that certain models can only be implemented using a transactional API, but the transaction failure mode has a clear and simple reflection into the GUI. Users have an expectation of transactionality, and IMO domain-dependent conflict resolution (as opposed to domain-independent transactionality) is a leap into the unknown. I think it's both less natural and more work for the user. IMO The tradeoff of user-interface model/complexity vs. single/multi- node deployment vs. transaction cost should be in the hands of the application developer. Antony Blakey ------------- CTO, Linkuistics Pty Ltd Ph: 0438 840 787 When I hear somebody sigh, 'Life is hard,' I am always tempted to ask, 'Compared to what?' -- Sydney Harris