couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Randall Leeds <>
Subject Re: [proposal] Update Handler Conflict Resolution
Date Sun, 11 Sep 2011 02:54:19 GMT
On Fri, Sep 9, 2011 at 06:37, Pepijn de Vos <> 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.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message