Return-Path: X-Original-To: apmail-couchdb-user-archive@www.apache.org Delivered-To: apmail-couchdb-user-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 085E010587 for ; Wed, 16 Apr 2014 20:46:46 +0000 (UTC) Received: (qmail 40158 invoked by uid 500); 16 Apr 2014 20:46:44 -0000 Delivered-To: apmail-couchdb-user-archive@couchdb.apache.org Received: (qmail 40074 invoked by uid 500); 16 Apr 2014 20:46:44 -0000 Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@couchdb.apache.org Delivered-To: mailing list user@couchdb.apache.org Received: (qmail 40066 invoked by uid 99); 16 Apr 2014 20:46:44 -0000 Received: from minotaur.apache.org (HELO minotaur.apache.org) (140.211.11.9) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 16 Apr 2014 20:46:44 +0000 Received: from localhost (HELO [192.168.1.6]) (127.0.0.1) (smtp-auth username rnewson, mechanism plain) by minotaur.apache.org (qpsmtpd/0.29) with ESMTP; Wed, 16 Apr 2014 20:46:43 +0000 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: Modeling Relationships and providing Transactional Integrity From: Robert Samuel Newson In-Reply-To: <0D27F132-296F-4034-BB02-82E8453B5E87@couchbase.com> Date: Wed, 16 Apr 2014 21:46:39 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <4A11D521-2143-4BF0-BFDE-C298070C6B12@apache.org> References: <0D27F132-296F-4034-BB02-82E8453B5E87@couchbase.com> To: user@couchdb.apache.org X-Mailer: Apple Mail (2.1874) _bulk_docs is not transactional at all. all_or_nothing:true used to be = but the semantic changed for the reason Jens notes, it doesn=92t work in = a sharded context. Now it simply forcibly introduces conflicts if it has = to. B. On 16 Apr 2014, at 15:32, Jens Alfke wrote: >=20 > On Apr 15, 2014, at 8:59 PM, Suraj Kumar = wrote: >=20 >>> - To modify an attribute that is involved in a relationship, a >>> "transactional update" API must be used. All the related documents = for >>> those change(s), must also be submitted through this API = "bulk_doc"-like >>> API (perhaps bulk_docs itself?). >=20 > I don=92t think _bulk_docs will provide a transactional update even on = a single shard/node =97 the semantics will be the same as issuing a = bunch of individual PUT requests one after the other, i.e. someone else = can sneak in and update a doc in between two of your updates. There are = warnings about this in the API docs (at least there were in the old = docs; haven=92t checked the new ones.)=20 >=20 > There used to be an =93all or nothing=94 mode to _bulk_docs a long = time ago that did provide a transactional update, but apparently it was = removed because it couldn=92t be supported in a clustered environment = (BigCouch). >=20 > [The usual disclaimer: I=92m not familiar with the code inside = CouchDB, only its behavior.] >=20 > =97Jens >=20 > PS: Removing the dev@ group from the reply because (a) I=92m not = subscribed to that, and (b) it=92s off-topic.