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!"}}}
http://github.com/jhs/couchdb/commit/9147281fb664b78b9fe639da91d96f819b92479d
This is an instructive update funciton:
http://friendpaste.com/4xckLZzYr4XSXhbAAGIBhj
I would like to hear critiques of this approach, if possible addressing its
pros:
* 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
