From dev-return-3709-apmail-couchdb-dev-archive=couchdb.apache.org@couchdb.apache.org Wed Apr 01 12:23:46 2009 Return-Path: Delivered-To: apmail-couchdb-dev-archive@www.apache.org Received: (qmail 82593 invoked from network); 1 Apr 2009 12:23:46 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 1 Apr 2009 12:23:46 -0000 Received: (qmail 96451 invoked by uid 500); 1 Apr 2009 12:23:45 -0000 Delivered-To: apmail-couchdb-dev-archive@couchdb.apache.org Received: (qmail 96368 invoked by uid 500); 1 Apr 2009 12:23:45 -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 96357 invoked by uid 99); 1 Apr 2009 12:23:45 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 01 Apr 2009 12:23:45 +0000 X-ASF-Spam-Status: No, hits=2.2 required=10.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of sixtus@gmail.com designates 209.85.132.246 as permitted sender) Received: from [209.85.132.246] (HELO an-out-0708.google.com) (209.85.132.246) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 01 Apr 2009 12:23:35 +0000 Received: by an-out-0708.google.com with SMTP id b2so6796ana.5 for ; Wed, 01 Apr 2009 05:23:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=rN5cZef+wS3eEMkki5b4mwgRDZanPqhKX2JsDEN6EfI=; b=Awd5CPFhy9U+zGNEIEKbiKx1uDN4UpijKIju/g00B+3gHKzPzCdMromt7bxCakN6KN Kf+XAwiO2NWTAA98plicJJXe3Weoi4IIFXKkto/cp8BSQCr0SuuWO+GwAvotunVQUgXl ifr9JA3nanJ7a28pIjYFgeySiKqTgcre4E0R0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=XURroL5LNpacLOdVNMq8dXNoKpdd3bZazGX1LRrw1ArEJX5JD6o/U7X1fwOPuxpsqc WW6O3NwB4F1AyAVa4KGxZJKPS61pXIGT2tIZWqFERkFTK6LvgNc3pporNYTNNGChYMHI DjtIff5wxkT1rflVxOwncfteh837t+Fh/ygWg= MIME-Version: 1.0 Received: by 10.100.226.16 with SMTP id y16mr1565922ang.129.1238588590675; Wed, 01 Apr 2009 05:23:10 -0700 (PDT) In-Reply-To: <5DA1BF0C-C1D9-47E5-8B3D-7FDC360C5C77@gmail.com> References: <56a83cd00903182250l5aaec9c2g8815899f32e6924a@mail.gmail.com> <5DA1BF0C-C1D9-47E5-8B3D-7FDC360C5C77@gmail.com> Date: Wed, 1 Apr 2009 14:23:10 +0200 Message-ID: <42fe43e10904010523p1d90542dlbefd3e9da6f9153@mail.gmail.com> Subject: Re: Bulk updates and eventual consistency From: Hagen Overdick To: dev@couchdb.apache.org Content-Type: multipart/alternative; boundary=0016369202c9f8c38504667d608c X-Virus-Checked: Checked by ClamAV on apache.org --0016369202c9f8c38504667d608c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit > > IMO this is a questionable decision, but I'm in the minority. Guess, after much thought about this, I am joining the minority. I base my argumentation on this excellent paper: http://www-db.cs.wisc.edu/cidr/cidr2007/papers/cidr07p15.pdf In essence, Pat Helland recommends to identify _entities_ which represent the maximum scope of _local_ serializability. Thanks to the bulk update mechanism, this used to be a whole couchdb, with the changes given, an entity maps to a single document now. The reason given here is sharding a single database, a concept which I would refuse, because it breaks the idea of a database as an entity in the first place. Btw, the reasoning that let to the removal of bulk_transactions can be applied to the single update as well, there is just no guarantee there won't be a conflicting update somewhere in the distributed environment. Also, I don't really see, how you want to provide all_or_nothing semantics assuming a sharded database. So, what's an entity for CouchDB? I very much prefer a whole db, because I can have partial updates (which is exactly what the old bulk_transaction provided). I don't want to use this for referencial integrity, but local serializability of updates. If you remove that, you will either force people to bad design (keeping everything in a single document and eventually ask for partial updates) or force them to replicate this functionality outside of CouchDB, leading to ugly clutches. Just my 2 Eurocents Hagen -- Dissertations are a successful walk through a minefield -- summarizing them is not. - Roy Fielding --0016369202c9f8c38504667d608c--