Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: pass (athena.apache.org: domain of jens@couchbase.com designates
 199.193.200.194 as permitted sender)
Content-Type: text/plain; charset="windows-1252"
MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1877.7\))
Subject: Re: Modeling Relationships and providing Transactional Integrity
From: Jens Alfke <jens@couchbase.com>
In-Reply-To: 
 <CABadZmLWd02SRbfvdRYkWFeqW2Am8Sk-Rj+FD+JbBSSoiBhXoQ@mail.gmail.com>
Date: Wed, 16 Apr 2014 07:32:58 -0700
Content-Transfer-Encoding: quoted-printable
Message-ID: <0D27F132-296F-4034-BB02-82E8453B5E87@couchbase.com>
References: 
 <CABadZm+67XC9BKspBSUrJqHuaTi3q3yLCht74qinO9Nsew9BYg@mail.gmail.com>
 <CABadZmLWd02SRbfvdRYkWFeqW2Am8Sk-Rj+FD+JbBSSoiBhXoQ@mail.gmail.com>
To: <user@couchdb.apache.org>


On Apr 15, 2014, at 8:59 PM, Suraj Kumar <suraj.kumar@inmobi.com> wrote:

>>   - 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?).

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

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).

[The usual disclaimer: I=92m not familiar with the code inside CouchDB, =
only its behavior.]

=97Jens

PS: Removing the dev@ group from the reply because (a) I=92m not =
subscribed to that, and (b) it=92s off-topic.=