couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Smith <>
Subject Re: [proposal] Update Handler Conflict Resolution
Date Sun, 11 Sep 2011 19:11:26 GMT
Hi, Randall. May I refer to the update() function as store() to avoid
overloading the word "update"?

    var store = update; // Hopefully this clarifies the email.

Also, I use ?retry=true instead of ?indempotent=true because we are
talking about either 0 or 1 total document updates. _update runs until
it works; it doesn't ever update the same document twice in one query.

On Sun, Sep 11, 2011 at 9:54 AM, Randall Leeds <> wrote:
> 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.

I'm curious what makes proposal 2 cleaner. I'm unsure of two things:

Firstly, what if an _update function calls store() and also returns a
document? What if it calls store() twice? Am I misunderstanding?

Secondly, won't this require modifying the view server protocol?

Proposal 1, yes, adds one parameter to the API. But it does not change
Couch conceptually. Instead of high-latency retry loops, you get
low-latency retry loops. _update itself follows this philosophy, being
API sugar for a low-latency fetch-modify-store loop.

In the _update handler code,

It seems like send_doc_update_response could have an `Attempts`
parameter, initially 0. If couch_db:update_doc throws a conflict and
?retry=true, re-enter the function with Attempts+1. After 2 or 3
attempts, it would re-throw. Is this a possible approach?


Iris Couch

View raw message