Thanks Alex, that all makes sense. On 22 July 2012 20:49, Alexander Shorin <[email protected]> wrote:
> 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 >
