couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Smith <>
Subject Re: Proposal for changes in view server/protocol
Date Mon, 02 Aug 2010 10:11:17 GMT
I coded up an instructive example. This is not at this time a candidate for
merging, just something to consider.

Update functions receive a third parameter called "failures". The update
function is re-executed if a save was not possible, with the `failures`
object accumulating a map of failed document _ids to the reason for the
failure. For example {"some_id": {"validation": {"forbidden", "I am
_design/mean and I hate all documents!"}}}

This is an instructive update funciton:

I would like to hear critiques of this approach, if possible addressing its

  * It exists
  * Backward-compatible with existing update function code
  * No change to the view server protocol
  * Update functions know why the failure occurs, including the validation
error thrown by `validate_doc_update`
  * For successful saves, the function runs once
  * In the typical case, for unsuccessful saves, the function runs twice:
once to fail, and the second time to react to the failure. (In practice
updaters are not likely to continue guessing at alternative _ids because if
any old _id would work, then they would choose `req.uuid`.)

Of course I would like to alternatives to improve on this proposal's cons:

  * A little bit complex
  * A function called `update` is now doing document save error handling
  * Bears similarity to the old _list functions that nobody liked
  * Conceptually, it is over-engineering for a function to execute
recursively simply because it wants to know if a document can be saved.
(Although I took the idea from the Erlang pattern of looping over and over,
while accumulating state.)

In closing, I will reiterate the first point: it exists :)

Jason Smith
Couchio Hosting

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