On Sun, Sep 11, 2011 at 12:11, Jason Smith <[email protected]> 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 <[email protected]> > 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 >
