On Sun, Jul 22, 2012 at 12:43 PM, Samuel Williams
<[email protected]> wrote:
> Is it possible to signal an error from updates, e.g. that the update wasn't
> possible?
You may exit gracefully from update handler:
>>> return [null, {"code": 400, "json": {"error": "bad_request", "reason":
>>> "sorry, failed"}}]
or explicitly raise an error:
>>> throw {"failed": "why"}
Last thing would be catched by query server internals and prevents
process crush by forwarding error details back to CouchDB.
> It feels like updates could almost be a mapping function in the sense that
> given some input data, output one or more documents, following the emit
> style model.. it wouldn't fit with the existing approach but it just seems
> like it might be a nicer model?
Update handlers operates with only single document: which exists or
not yet. The only special thing of update handlers is that you're able
to implement business logic on server side, not on client. For others,
they provides no more additional features against regular document
saving via POST/PUT request.
--
,,,^..^,,,
On Sun, Jul 22, 2012 at 12:43 PM, Samuel Williams
<[email protected]> wrote:
> Hi again,
>
> Is it possible to signal an error from updates, e.g. that the update wasn't
> possible?
>
> It feels like updates could almost be a mapping function in the sense that
> given some input data, output one or more documents, following the emit
> style model.. it wouldn't fit with the existing approach but it just seems
> like it might be a nicer model?
>
> Kind regards,
> Samuel
