From dev-return-3650-apmail-couchdb-dev-archive=couchdb.apache.org@couchdb.apache.org Thu Mar 26 17:00:55 2009 Return-Path: Delivered-To: apmail-couchdb-dev-archive@www.apache.org Received: (qmail 82164 invoked from network); 26 Mar 2009 17:00:55 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 26 Mar 2009 17:00:55 -0000 Received: (qmail 56318 invoked by uid 500); 26 Mar 2009 17:00:54 -0000 Delivered-To: apmail-couchdb-dev-archive@couchdb.apache.org Received: (qmail 56262 invoked by uid 500); 26 Mar 2009 17:00:54 -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 56252 invoked by uid 99); 26 Mar 2009 17:00:54 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 26 Mar 2009 17:00:54 +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; Thu, 26 Mar 2009 17:00:45 +0000 Received: by server1.example.com (Postfix, from userid 65534) id 3F4441C8419; Thu, 26 Mar 2009 17:00:24 +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 728D41C8416 for ; Thu, 26 Mar 2009 17:00:22 +0000 (GMT) Message-ID: <49CBB4A6.1050001@timparkin.co.uk> Date: Thu, 26 Mar 2009 17:00:22 +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> <49CA2879.3070502@timparkin.co.uk> <49CA8AA6.90708@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 Antony Blakey wrote: > > On 26/03/2009, at 6:18 AM, Tim Parkin wrote: > >> I don't want to have to repeat myself but *it's not about the >> consistency or atomicity*. It's about being able to make two or more >> changes in a single request (via a UI or API) and if the last one fails, >> being able to roll the first ones back and tell the user "Sorry, >> something went wrong, would you like to try again" instead of "you have >> a partial success, how would you like to deal with it?" > > In what way is that not atomicity? Well the difference is I'm more interested the ability to rollback than the atomicity. The philosophical objection (AFAICT) is to the atomicity of bulk_docs. So if we can simplify the rollback that would be goal number 1 acheived.. The simplest way to do this would probably be to reinstate bulk_docs I imagine (as your comment below points out). The alternative is to create a virtual revision layer system over couch, which we're testing and writing up, but this would have interesting repurcussions (the system would probably not use couchdb's replication model as each replication is just a union and you would have to layer a new conflict system on top of couch's - I'll try to write this up soon) > > I have a patch that adds/restores fail-on-conflict bulk update behaviour > (ie. your rollback requirement, but with no intermediate state). It's > 10-15 lines depending on formatting, i.e. fairly trivial, so it should > be easy to keep it on HEAD. I trigger it explicitly by adding > fail-on-conflict: true to the top level json in the bulk request, which > means that existing tests pass because the default semantics are unpatched. > I'd be very interested - could I have a play with it? Cheers Tim