couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Suraj Kumar <>
Subject Re: Proposal for new feature: Auto Update Functions
Date Mon, 02 Jun 2014 05:13:37 GMT
On Sun, Jun 1, 2014 at 3:00 AM, Robert Samuel Newson <>

> 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.

What if this is written to not interfere with replicator? ie., this is a
sequential update done just before doc is written to disk and this does not
happen in the replicator pathway at all (ie., when another
auto-update-handler of a remote machine does it, the nodes pulling this
change will store it as-is). Also, this means this edit is in the
synchronous path, just like how VDU calls are in the synchronous path.

does that make sense?



An Onion is the Onion skin and the Onion under the skin until the Onion
Skin without any Onion underneath.

The information contained in this communication is intended solely for the 
use of the individual or entity to whom it is addressed and others 
authorized to receive it. It may contain confidential or legally privileged 
information. If you are not the intended recipient you are hereby notified 
that any disclosure, copying, distribution or taking any action in reliance 
on the contents of this information is strictly prohibited and may be 
unlawful. If you have received this communication in error, please notify 
us immediately by responding to this email and then delete it from your 
system. The firm is neither liable for the proper and complete transmission 
of the information contained in this communication nor for any delay in its 

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