CouchDB“_changes”侦听器更新了doc,这会触发另一个更改

时间:2011-08-20 18:10:15

标签: recursion couchdb infinite

我想编写一个后台程序,它将监视CouchDB的_changes feed,并可能更新文档。问题是更新导致另一个_change,我得到一个无限循环!避免这种情况的最佳方法是什么?

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

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


我得出的结论是“_changes”监听器永远不应该修改它监听的文档。在我的情况下,我决定将我的PDF文件附加到一个单独的文档,在couchdb中的一个单独的“数据库”中,但使用相同的“_id”使其易于关联。这样我就不会在我正在听的同一文件上触发“_change”。我无法满足要求每个更改文档的客户端以某种方式“标记”它需要处理(通过删除现有附件,或以其他方式设置一些“脏”标志)。经过多次思考后,我认为这对我来说是一个经验法则:在收到该文档的“_change”通知后,您不得修改文档。还有其他人得出同样的结论吗?

1 个答案:

答案 0 :(得分:4)

使用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)

检查附件