Return-Path: Delivered-To: apmail-couchdb-dev-archive@www.apache.org Received: (qmail 6925 invoked from network); 23 Mar 2009 21:30:16 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 23 Mar 2009 21:30:16 -0000 Received: (qmail 97634 invoked by uid 500); 23 Mar 2009 21:30:16 -0000 Delivered-To: apmail-couchdb-dev-archive@couchdb.apache.org Received: (qmail 97567 invoked by uid 500); 23 Mar 2009 21:30: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 97557 invoked by uid 99); 23 Mar 2009 21:30:16 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 23 Mar 2009 21:30:16 +0000 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 b.candler@pobox.com designates 207.106.133.19 as permitted sender) Received: from [207.106.133.19] (HELO sasl.smtp.pobox.com) (207.106.133.19) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 23 Mar 2009 21:30:07 +0000 Received: from localhost.localdomain (unknown [127.0.0.1]) by a-sasl-fastnet.sasl.smtp.pobox.com (Postfix) with ESMTP id 08838A49BF; Mon, 23 Mar 2009 17:29:43 -0400 (EDT) Received: from mappit (unknown [80.45.95.114]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by a-sasl-fastnet.sasl.smtp.pobox.com (Postfix) with ESMTPSA id 614DDA49BE; Mon, 23 Mar 2009 17:29:41 -0400 (EDT) Received: from brian by mappit with local (Exim 4.69) (envelope-from ) id 1LlriF-0005Us-EB; Mon, 23 Mar 2009 21:29:39 +0000 Date: Mon, 23 Mar 2009 21:29:39 +0000 From: Brian Candler To: David Van Couvering Cc: dev@couchdb.apache.org Subject: Re: Where to add documentation for bulk updates Message-ID: <20090323212939.GA20935@uk.tiscali.com> References: <56a83cd00903220737j16081b66nee344fcfad9f6123@mail.gmail.com> <20090322220237.GC5800@uk.tiscali.com> <56a83cd00903230648n19169a3egf4601c716b9d87ae@mail.gmail.com> <20090323142311.GA11694@uk.tiscali.com> <56a83cd00903230959k7271080el2d4f6af9b2b25053@mail.gmail.com> <20090323174055.GA15016@uk.tiscali.com> <56a83cd00903231225k7ed80fa0g66d596d9274bb167@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <56a83cd00903231225k7ed80fa0g66d596d9274bb167@mail.gmail.com> User-Agent: Mutt/1.5.17+20080114 (2008-01-14) X-Pobox-Relay-ID: B93DFDFE-17F1-11DE-8884-32B0EBB1AA3C-28021239!a-sasl-fastnet.pobox.com X-Virus-Checked: Checked by ClamAV on apache.org On Mon, Mar 23, 2009 at 12:25:02PM -0700, David Van Couvering wrote: > Fixed. Thanks for catching this. Obviously I should have tested this, > but I am very busy right now, and I wanted to get this doc out in time > for the release. Hmm, I believe the wiki is still wrong, I'm afraid. As I understand it: * In the normal (non-atomic) mode, the _rev of each document is checked, and individual documents may either be updated, or rejected with "error:" "conflict", "reason": "Document update conflict." in the case that the supplied _rev doesn't match the current _rev. * If you post with {"all_or_nothing":true} then you will *never* see a conflict error in the response. All documents will show successful saves. But in those cases where the _rev posted does not match the current _rev, both versions of the document will reside in the database, and be marked as in conflict. So as far as I can tell, the "all or nothing" part of this only comes into play if the server is killed during the POST. When it is restarted, you'll either see all the updates, or none. (I'm not sure if this guarantee is covered through replication too, that is, if either server is killed while a replication is taking place) Regards, Brian.