Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Received-SPF: pass (athena.apache.org: domain of randall.leeds@gmail.com
 designates 209.85.213.52 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <04419515-81B2-480D-A897-2BDD4EC8EFD5@yahoo.com>
References: <04419515-81B2-480D-A897-2BDD4EC8EFD5@yahoo.com>
Date: Sat, 10 Sep 2011 19:54:19 -0700
Message-ID: 
 <CAAL6JQgrC1wH-a1SeC6r524u5=jsa4Kf8_-5PxV=tDbXQzEH3A@mail.gmail.com>
Subject: Re: [proposal] Update Handler Conflict Resolution
From: Randall Leeds <randall.leeds@gmail.com>
To: dev@couchdb.apache.org
Content-Type: multipart/alternative; boundary=90e6ba6e8f28e71b9d04aca186bd

--90e6ba6e8f28e71b9d04aca186bd
Content-Type: text/plain; charset=UTF-8

On Fri, Sep 9, 2011 at 06:37, Pepijn de Vos <pepijndevos@yahoo.com> wrote:

> Hi,
>
> Today I had a long and complicated discussion involving rnewson, jan____,
> me and muhqu.
>
> I was falsely assuming Document Update Handlers did atomic updates. Truth
> is that they don't, but for most of my use cases could.
>
> What currently happens is that the update handler gets executed with the
> latest rev of the requested doc. When the update is completed, it is
> committed, but when another update has meanwhile happened, a conflict arises
> and 409 is returned.
>
> When I use update handlers, I mostly use idempotent functions. This means
> that it is safe for the update handler to retry on its own account, and in
> doing so, avoid a ton of latency and headaches.
>
> Only, it turns out that programmatic updates are not the sole use for
> update handlers, so rnewson argued that it might destroy data.
>
> Proposal 1:
> Add an idempotent=true parameter to the handler, allowing it to retry on
> its own.
>
> Proposal 2:
> Add an update() function so the handler can handle conflicts in itself.
>

Just so I understand... is update() a function called from within the
handler that tries to commit the result?
If this fails, should there be a function to retrieve the latest version of
the document again?
I sort of like this approach. Proposal 1 makes some sense but I worry about
a request potentially being retried 'forever' and not sure how to impose
limits on that without expanding our configuration space or HTTP API surface
area when proposal 2 is perhaps cleaner.

-Randall

--90e6ba6e8f28e71b9d04aca186bd--