On Sun, Jun 1, 2014 at 3:00 AM, Robert Samuel Newson <[email protected]> wrote:
> 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? Regards, -Suraj -- 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 receipt.
