The main trouble is loops. If couchdb edits the doc after the user edits it, this edit is also replicated out to wherever you replicate to, which will make this edit again, and then back again, and then back again.
In couchdb, by design, one request causes one action, not multiple, not loops. We should think very carefully about changing that. This proposal (and its been proposed before in other guises) seems to suffer a fatal flaw. B. On 31 May 2014, at 20:12, Alexander Shorin <[email protected]> wrote: > The problem with update functions that they cannot be applied for bulk > updates. API reroute via reverse proxy cannot solve that too. I > believe, proposed feature assumed to handle this case. > -- > ,,,^..^,,, > > > On Sat, May 31, 2014 at 11:06 PM, Joan Touzet <[email protected]> wrote: >> The typical solution to this is to use a reverse proxy or API layer to >> ensure that all client updates go through the required document update >> handler. It's unclear to me that this functionality native in CouchDB is >> necessary. >> >> If you decide to move ahead with implementation , keep in mind that the >> 1843-feature-bigcouch branch as that will be landing very soon. Any proposed >> patch should be compatible the fabric/chttpd-based approach and support >> single- and multi-node (BigCouch cluster) approaches. >> >> -Joan >> >> ----- Original Message ----- >> From: "Franck Eyraud" <[email protected]> >> To: [email protected] >> Cc: [email protected] >> Sent: Saturday, May 31, 2014 8:34:57 AM >> Subject: Re: Proposal for new feature: Auto Update Functions >> >> Le 30/05/2014 13:04, Dirkjan Ochtman a écrit : >>> On Fri, May 30, 2014 at 12:57 PM, Suraj Kumar <[email protected]> >>> wrote: >>>> What are your thoughts, both from the use-case as well as >>>> internals/performance of CouchDB about this? >>> How is this different from document update handlers? >> Update handlers must be called by the client to be used. Auto update >> functions would be called even if the client directly POST/PUT a doc to >> the DB (so they would be mandatory). >> >> At first sight a good idea, it seems to me that auto update functions >> would cause problem during replication : the replicated doc might be >> different from the original one. >> >> Franck
