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 mrtrick@gmail.com designates
 209.85.160.180 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:user-agent:mime-version:to:subject:references
         :in-reply-to:content-type:content-transfer-encoding;
        b=Q2dz0zTslREut/sO8BtJQJZ6Zx1J92SqJ30gUxV8KdVetsnvqcG4+YGdKbGmDVBcXi
         yPAhsIkJApO8MsF3GmFdZ3N7i1jWpIWTfD4WtQNWQQauK2gj/bjMIz3RzNcC44AizolN
         9jiUkG0OgcZG/QKaMwmCyZzpVZjLckfbPM04Y=
Message-ID: <4BB00D76.301@gmail.com>
Date: Mon, 29 Mar 2010 13:16:22 +1100
From: Patrick Barnes <mrtrick@gmail.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
 rv:1.9.1.8) Gecko/20100227 Lightning/1.0b1 Thunderbird/3.0.3
MIME-Version: 1.0
To: user@couchdb.apache.org
Subject: Re: Deciding on the structure of documents
References: <a04554c01003280558k3784281bq35bbeca153af447b@mail.gmail.com>
	 <4BAFF265.8070202@gmail.com>
 <j2xcfeeccf81003281858o7b3852d8p8d64767245601ca4@mail.gmail.com>
In-Reply-To: <j2xcfeeccf81003281858o7b3852d8p8d64767245601ca4@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

I would suggest that on replication if the documents conflict and have 
different owners, do a kind of 'asynchronous revision error' - have the 
system choose the earlier 'owner claim' by date, and send an email 
stating 'sorry X, Y has already taken ownership'.

I'm not sure if that would cause further issues regarding whether to 
invalidate content changes made by X, or how best to resolve that sort 
of thing.


On 29/03/2010 12:58 PM, Robert Sanford wrote:
> On Sun, Mar 28, 2010 at 7:20 PM, Patrick Barnes<mrtrick@gmail.com>  wrote:
>
>> For the single-document situation: What if multiple people reply to the
>> same post at the same time? The first comment to reach couchdb would succeed
>> in updating the document, and the second comment would result in an error,
>> because the doc revision is now out of date. A single-document situation
>> would require the application logic to handle a revision error, and maybe
>> automatically resubmit. This solution does not scale well - the more traffic
>> and the more comments a site receives, the more likely these revision errors
>> will occur.
>>
>
> This brings up a question on an app I'm in the process of designing and I'm
> wondering how it works in a multi-node situation.
>
> In my app a document (almost literally a document actually) can have a
> single caretaker. In some situations the owner can decide they no longer
> wish to act as caretaker and offer up the document to others. That situation
> is easy in that the role of caretaker is explicitly transferred. Or, they
> can simply release "ownership" of the document.In that instance others that
> are assigned the role of Caretaker in the system can then claim the document
> on a first-come-first-served basis.
>
> In a multi-node system w/ replication what happens if Caretaker D in the
> Dallas office claims the document and prior to any replication occurring
> Caretaker P in the Phoenix office also claims the document?
>
> How can that sort of situation be handled? In a single-node system it's (not
> quite) trivial to handle but in a multi-node system w/ a time delay between
> replications that are not taking business logic into account that is
> trickier and I don't have my head around it yet.
>
> rjsjr
>