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
