Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Received-SPF: pass (nike.apache.org: domain of jchris@gmail.com designates
 209.85.132.243 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:sender:in-reply-to:references:date
         :x-google-sender-auth:message-id:subject:from:to:content-type
         :content-transfer-encoding;
        b=AgdMCPTuw7vL0gYzdd6ywecQP/Dnj4jQHmpi/rfhKCol7sO5jg0xOQCtzW2YLvG6PD
         GvUG3o7L5ptdfPdWdHHMYSrODc4gALdcOGpVRZ1Y1UweSKJTCFKpKWd6cjpyjUQ+1ssY
         GGntqgfm9XaSnmbuMt69o8TxFY0T+h1xoqfKk=
MIME-Version: 1.0
Sender: jchris@gmail.com
In-Reply-To: <0E7BBB9C-CEEC-4DEC-9BF4-8B3D420A9974@gmail.com>
References: <49B8FD3F.4050706@timparkin.co.uk>
	 <49B9882F.6050307@timparkin.co.uk>
	 <e282921e0903121715w19058992j337cbc1acd781ab2@mail.gmail.com>
	 <49BA299D.6090606@timparkin.co.uk> <49BA2D42.7000004@timparkin.co.uk>
	 <D157717D-F6E9-42AA-8E58-CD7EEF30901C@gmail.com>
	 <49BA77DF.6000405@timparkin.co.uk>
	 <342590F1-BCEA-4FF0-A430-D8FF25E30C97@gmail.com>
	 <e282921e0903130947g3a3aa425i2b90d9a6d51c73d3@mail.gmail.com>
	 <0E7BBB9C-CEEC-4DEC-9BF4-8B3D420A9974@gmail.com>
Date: Fri, 13 Mar 2009 10:53:31 -0700
Message-ID: <e282921e0903131053x9622a48n40701cf02407592b@mail.gmail.com>
Subject: Re: Bulk Docs - 'remove changes so far' Functionality?
From: Chris Anderson <jchris@apache.org>
To: dev@couchdb.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

On Fri, Mar 13, 2009 at 10:42 AM, Wout Mertens <wout.mertens@gmail.com> wrote:
> On Mar 13, 2009, at 5:47 PM, Chris Anderson wrote:
>
>> On Fri, Mar 13, 2009 at 9:41 AM, Wout Mertens <wout.mertens@gmail.com>
>> wrote:
>>>
>>> On Mar 13, 2009, at 4:12 PM, Tim Parkin wrote:
>>>
>>>> I think all bulk doc changes were written somewhere and then only
>>>> switched in once the last was successful.. so no locking.
>>>
>>> But then if a normal write comes in while the bulk doc is being
>>> processed,
>>> how did it know to fail that write/fail the bulk?
>>>
>>
>> CouchDB updates are serialized, so if a normal write comes in during a
>> bulk update, the normal write waits. Of course, all this is different
>> if the bulk update is spread across multiple nodes. Crossing that
>> bridge is part of the motivation for limiting the feature to skip
>> conflict checking.
>
> Again out of curiosity, how would the spreading work? The bulk write would
> go to ibrowse, which would then contact multiple couches and give each of
> them some work?
>

Something like that. Maybe leave out ibrowse / http all together and
communicate using erlang messages.

Alternatively, save the update to a local temporary database, ack the
client, and then replicate the updates to the proper home.

Chris


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