couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Randall Leeds <randall.le...@gmail.com>
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 <jhs@iriscouch.com> 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 <randall.leeds@gmail.com>
> 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,
>
>
> https://github.com/apache/couchdb/blob/trunk/src/couchdb/couch_httpd_show.erl#L125
>
> 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
explicitly
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
>

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