具有连续复制功能的CouchDB恢复文档修订，而不是删除

我们有一个使用CouchDB作为数据库的系统。 我们正在使用连续复制来创建数据库的始终更新副本

最近我们发现了一个奇怪的行为（可能是bug？），我希望这里的人能帮助我：

我们将系统设置为正常复制（未过滤）

我们连续几次更新同一文档（每次都在等待CouchDB返回200ok）——这部分工作正常，文档在复制的数据库中似乎更新得很好

但是，当我们尝试删除此文档时，即使在连续更新几分钟后，它也不会在复制数据库中删除，而是恢复到连续更新之前的修订版本

需要注意的是，我们通过添加一个\u deleted字段来删除，该字段设置为true

我知道使用HTTP DELETE和过滤复制相结合的方法进行删除会出现一些问题，但我们不使用这两种方法。 另外，做同样的更新，在一个和另一个之间等待一秒钟，就可以很好地解决问题（或者将它们合并到一个更新中）。 然而，这两种解决方案都不可能，在任何情况下，只要绕过问题就行了

tl；博士： 1） 具有正常连续复制的CouchDB

2） 文档的连续更新

3） _deleted=trueto文档

4） 复制的数据库不会删除，而是恢复为#2之前的#u rev

环境： CouchDB版本是1.6.1

Windows计算机

---

使用CouchDB Lucene很可能在文档中引入了一些冲突。在多个副本中编辑文档时，CouchDB会在复制时选择一个成功的修订，但也会保留丢失的修订。如果删除成功的修订，将再次显示失败的修订。您可以在CouchDB指南（现在有些过时）和CouchDB文档中阅读介绍：

但简而言之，复制数据库可能是由某人编辑的。可能是您将多个数据库复制到一个数据库中，或者有人在目标数据库中手动编辑了文档

您可以删除目标数据库并重新创建空数据库。如果您不手动编辑目标数据库，也不将多个数据库复制到一个数据库中，则从那时起将正确复制删除内容。

问题已解决。 这是修订限制。 似乎快速执行超出修订限制的更改会导致复制机制出现问题

关于此问题，CouchDB中有一个未解决的错误：

由于我们的修订限制是2，所以对同一文档连续进行3次更新，然后将其删除会导致此问题。

---

将修订限制设置为5可以避免此问题。

只是为了确保，无论何时在文档上将“删除”设置为true，该属性都不会复制到复制数据库？这是正确的一半。这并不是说复制数据库中的文档根本不受影响。它将恢复到早期版本。当我用？all_rev=true检查它时，我可以看到较新的修订确实获得了_deleted=true属性，但连续更新之前的修订没有。这就是为什么，我猜，它会成为replicate CouchDB在请求文档时返回的修订版。但是，主CouchDB对其所有修订都添加了_deleted=true。只是一个更正。当我写“全部”时，我的意思是“全部打开”