Yes, I would imagine the update function tries to commit the result. Maybe update could itself return the new document?
I think rnewson or jan____ said there was already some sort of timeout in place. Pepijn On Sep 11, 2011, at 4:54 AM, Randall Leeds wrote: > On Fri, Sep 9, 2011 at 06:37, Pepijn de Vos <[email protected]> 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. > > -Randall
