Mailing-List: contact couchdb-user-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: couchdb-user@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of jchris@gmail.com designates
 72.14.220.155 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth;
        b=V4UfriuocqdpeqCNv9nyUJr0Z+GlLGTvKeoxOJfKCJlBa+KRjOuN2idfPPbkmRF5SuJTFsGRc7mTJ1ezVmFerbiRFiHeamS0FH1KYjx3QHXOvObFvIzONIOudYfwRlk1SCVfMAOPNb/fSvtFLptTgX4Wq3AhCtgk0P/27j1kCUw=
Message-ID: <e282921e0804091201o7b35cfa0k6ebb4e7c5794b946@mail.gmail.com>
Date: Wed, 9 Apr 2008 12:01:45 -0700
From: "Chris Anderson" <jchris@mfdz.com>
Sender: jchris@gmail.com
To: couchdb-user@incubator.apache.org
Subject: Re: multi-document acid transactions
In-Reply-To: <0433F5A7-24B9-4194-91CF-631282DCD975@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <0433F5A7-24B9-4194-91CF-631282DCD975@gmail.com>

Damien,

I can see the value of this feature, but there's also a lot of value
in being able to do fire-and-forget multi document inserts. In my
application I'm relying on uniq document id semantics, and was very
happy to see that bulk inserts would create some but not all documents
when the _rev property was absent and some ids were taken. It would
extremely useful if there was a parameter that could choose not to run
the inserts in a transaction.

I'll understand if that is infeasible. If you don't have
time/inclination to make the change, I'd happily pour over the diffs
to try to add the option. Perhaps you can give a pointer to the
check-in?

Thanks for everything!
Chris

On 4/9/08, Damien Katz <damienkatz@gmail.com> wrote:
> FYI, CouchDB now has multi-document ACID transactions. This were
> checked in last week as part of a larger refactoring.
>
> To do a multi-document update, simply use the bulk update POST option.
> If any document fails to commit due to conflict (or whatever reason),
> then all the documents fail.  You can also delete documents in the
> same bulk transaction, by setting the _deleted member in the document
> to true.
>
> So now if all transactions happen on the single instance, you can use
> bulk transactions and keep relationships and heirarchies amongst
> documents intact at all times. But once the application is
> distributed, then you potentially lose the ACID properties of the
> updates, as the replication system won't preserve the atomicity of the
> multi-document update.
>
> This mean I don't recommend relying on bulk updates to preserve inter-
> document ACID properties in distributed applications, but it's
> workable for applications that use only a single database instance.
>


-- 
Chris Anderson
http://jchris.mfdz.com