recursion - CouchDB "_changes"监听器更新文档，这会触发另一个更改

Question

我想编写一个后台程序来监视 CouchDB 的 _changes 提要，并可能更新文档。问题是更新导致了另一个_change，我陷入了无限循环!避免这种情况的最佳方法是什么？

例如，具体场景如下:我有一个 CouchApp，用户通过浏览器修改文档。我还有一个 python 程序，它创建文档的 PDF 版本，然后将其作为附件附加到文档本身。我的问题是执行 PUT 附件上传 PDF 也会触发文档更改。我必须能够判断更改是否是由 PDF 上传引起的。看起来应该很容易，但我想不出一个简单的方法来做到这一点。我宁愿让 PDF 生成器程序保持“无状态”，在数据库本身中保持任何所需的状态。

现在，如果我要求更改文档的用户在文档上设置某种标志以指示需要对其进行处理，则可以轻松完成此操作。诀窍是如何在不需要的情况下做到这一点。

---

我得出的结论是“_changes”监听器永远不应该修改它监听的文档。在我的例子中，我决定将我的 PDF 文件附加到一个单独的文档，在 couchdb 中的一个单独的“数据库”中，但使用相同的“_id”以便于关联。这样我就不会在我正在收听的相同文档上触发“_change”。我无法摆脱要求每个更改文档的客户以某种方式将其“标记”为需要处理的需求(通过删除现有附件，或设置一些“脏”标记)。经过深思熟虑，我认为这将是我的经验法则:您不得在收到文档的“_change”通知后修改该文档。有没有其他人得出同样的结论？

Answer 1

使用 filter function并过滤掉第二个更改——通过文档结构更改或通过为更改的文档设置附加标志:

function(doc, req)
{
  if(!doc.hasStructuralChange) { //fix this
    return true;
  }
  return false;
}

或

function(doc, req)
{
  if(!doc.changed) { //set doc.changed during first update
    return true;
  }
  return false;
}

编辑:您可以通过 if (doc._attachments)

检查附件