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 Thu, 15 Sep 2011 00:10:29 GMT
On Sun, Sep 11, 2011 at 12:11, Jason Smith <> wrote:

> 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?

Sounds reasonable. You're right about my assessment and how much it would
change things. I think proposal 1 makes more sense. Open for suggestions
about how the limits look.

First thoughts on

Limit set at query time:
1) It may be desirable not to clients dictate the use of server resources so
2) Super flexible, but is that useful?

Limit set in the configuration system:
1) Lets the owner of the system deployment set limits on this. If this is
desirable I expect you'll be the first to tell me.

Limit on the design document itself:
1) Not sure this has a good use case, but it's a natural middle ground
between the other two so I bring it up.

Anything else?

> Thanks!
> --
> Iris Couch

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