From dev-return-3631-apmail-couchdb-dev-archive=couchdb.apache.org@couchdb.apache.org Wed Mar 25 12:50:36 2009 Return-Path: Delivered-To: apmail-couchdb-dev-archive@www.apache.org Received: (qmail 36664 invoked from network); 25 Mar 2009 12:50:35 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 25 Mar 2009 12:50:35 -0000 Received: (qmail 96560 invoked by uid 500); 25 Mar 2009 12:50:34 -0000 Delivered-To: apmail-couchdb-dev-archive@couchdb.apache.org Received: (qmail 96495 invoked by uid 500); 25 Mar 2009 12:50:34 -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 96485 invoked by uid 99); 25 Mar 2009 12:50:34 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 25 Mar 2009 12:50:34 +0000 X-ASF-Spam-Status: No, hits=1.2 required=10.0 tests=SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (nike.apache.org: local policy) Received: from [89.16.178.93] (HELO server1.example.com) (89.16.178.93) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 25 Mar 2009 12:50:25 +0000 Received: by server1.example.com (Postfix, from userid 65534) id 89BD71C8419; Wed, 25 Mar 2009 12:50:04 +0000 (GMT) X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on timparkin.vm.bytemark.co.uk X-Spam-Level: Received: from [192.168.1.6] (cpc1-leed1-0-0-cust606.leed.cable.ntl.com [81.102.230.95]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by server1.example.com (Postfix) with ESMTPSA id 6BE4B1C8416 for ; Wed, 25 Mar 2009 12:50:02 +0000 (GMT) Message-ID: <49CA2879.3070502@timparkin.co.uk> Date: Wed, 25 Mar 2009 12:50:01 +0000 From: Tim Parkin User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 To: dev@couchdb.apache.org Subject: Re: Restricting user interactions to a single document -- was [VOTE] Apache CouchDB 0.9.0 release References: <20090324140050.GA17574@tumbolia.org> <49C9776E.1060804@timparkin.co.uk> <49CA1307.7060300@timparkin.co.uk> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org X-Old-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.2.5 Chris Anderson wrote: -- aa -- > > I think I understand the issue. I think there are two ways to approach > a solution. One is to confine end-user updates to a single key. This > approach is the classic model for key/value stores. Pretty unfeasible I would think.. > If your domain requires that edits are saved in multiple documents, > the complexity grows. If you can control replication, and ensure that > each user has a node to themselves, then you can treat edits between > replications as a transaction, and the application can roll back any > thing that has happened since the last outbound replication. It would > require a library between the UI and storage if you want to make that > simple for the user. > Fairly unfeasible for a database with 1m+ users.. and I imagine it won't be particularly fast to re-replicate the whole db on failure. > If you are working in an environment where the application can't treat > replication as a (soft) transaction boundary (hot-swap, or multiple > concurrent users) then you'll need to break updates out into > individual documents. A user can start an interactive transaction, and > mark all updates with the transaction id. Then you can use a view to > show only updates that are associated with a closed transaction. > > In this explicit-transaction use case, non-committed updates may be > replicated, and it is the responsibility of the application to read > data through a view which only shows updates that belong to finished > transactions. > Which isn't particularly straightforward either and you lose lots of couchdb features (like conflict management) plus, as you say, you need to monitor replication etc.. > The upshot is that bulk_docs can't and shouldn't give you any powers > that you don't have available with the individual document APIs, but > that doesn't mean your application can't provide those sorts of > interfaces. The upshot appears to be that CouchDB is limited to only changing a single document at a time through a user interface (unless you want to add lots of work to handle conflicts).. Could I have a confirmation of this so I can blog about it. It's a pretty fundamental restriction and one I'm sure people who want to use CouchDB would want to know about. Tim