具有连续复制功能的 CouchDB 恢复文档修订而不是删除
CouchDB with continuous replication reverts document revision instead of deleting
我们有一个使用 CouchDB 作为数据库的系统。
我们正在使用连续复制来创建我们数据库的始终更新的副本。
最近我们发现了一个奇怪的行为（也许是错误？），我希望这里有人能帮助我：
我们将系统设置为正常复制（未 过滤）。
我们连续多次更新同一文档（每次都等待 CouchDB 到 return 200ok）- 这部分工作正常，文档似乎在复制的数据库中更新得很好。
但是，当我们尝试删除此文档时，即使在连续更新几分钟后，它也不会在复制数据库中删除，而只是恢复到连续更新之前的修订版。
需要注意的是，我们通过添加一个 _deleted 字段设置为 true
来删除
我知道使用 HTTP DELETE 结合过滤复制进行删除存在一些问题，但我们两者都没有使用。
此外，进行相同的更新并在一个更新和另一个更新之间等待一秒钟就可以很好地解决问题（或者只是将它们组合到一个更新中）。
然而，这两种解决方案都是不可能的，无论如何只能解决问题。
tl;博士：
1) 具有正常连续复制的 CouchDB
2) 连续更新文档
3) _deleted = 真实文档
4) 复制的 DB 不删除，而是恢复到 #2
之前的 _rev
环境：
CouchDB 版本为 1.6.1
Windows 计算机
使用 CouchDB-Lucene
很可能您在文档中引入了一些冲突。当一个文档在多个副本中被编辑时，CouchDB 在复制时选择一个成功的修订，但也会保留失败的修订。如果您删除获胜的修订版，失败的修订版将再次显示。您可以阅读 CouchDB 指南（现在有些过时）中的介绍：http://guide.couchdb.org/draft/conflicts.html and in the CouchDB Docs: http://docs.couchdb.org/en/1.6.1/replication/conflicts.html
但简而言之，复制数据库可能已被某人编辑。可能是您将多个数据库复制为一个，或者有人在目标数据库中手动编辑了文档。
您可以删除目标数据库并重新创建一个空数据库。如果您不手动编辑目标数据库并且不将多个数据库复制到一个数据库中，那么 _deletes 将从那时起被正确复制。
问题已解决。
这是修订限制。
似乎快速进行超过修订限制的更改会导致复制机制出现问题。
CouchDB 中有一个关于此问题的未解决错误：
https://issues.apache.org/jira/browse/COUCHDB-1649
由于我们的修订限制是 2，对同一文档进行 3 次连续更新，然后将其删除导致了这个问题。
将修订限制设置为 5 可以避免它。
我们有一个使用 CouchDB 作为数据库的系统。 我们正在使用连续复制来创建我们数据库的始终更新的副本。
最近我们发现了一个奇怪的行为（也许是错误？），我希望这里有人能帮助我：
我们将系统设置为正常复制（未 过滤）。
我们连续多次更新同一文档（每次都等待 CouchDB 到 return 200ok）- 这部分工作正常，文档似乎在复制的数据库中更新得很好。
但是，当我们尝试删除此文档时，即使在连续更新几分钟后，它也不会在复制数据库中删除，而只是恢复到连续更新之前的修订版。
需要注意的是，我们通过添加一个 _deleted 字段设置为 true
来删除我知道使用 HTTP DELETE 结合过滤复制进行删除存在一些问题，但我们两者都没有使用。 此外，进行相同的更新并在一个更新和另一个更新之间等待一秒钟就可以很好地解决问题（或者只是将它们组合到一个更新中）。 然而，这两种解决方案都是不可能的，无论如何只能解决问题。
tl;博士：
1) 具有正常连续复制的 CouchDB
2) 连续更新文档
3) _deleted = 真实文档
4) 复制的 DB 不删除，而是恢复到 #2
之前的 _rev环境：
CouchDB 版本为 1.6.1
Windows 计算机
使用 CouchDB-Lucene
很可能您在文档中引入了一些冲突。当一个文档在多个副本中被编辑时，CouchDB 在复制时选择一个成功的修订，但也会保留失败的修订。如果您删除获胜的修订版，失败的修订版将再次显示。您可以阅读 CouchDB 指南（现在有些过时）中的介绍：http://guide.couchdb.org/draft/conflicts.html and in the CouchDB Docs: http://docs.couchdb.org/en/1.6.1/replication/conflicts.html
但简而言之，复制数据库可能已被某人编辑。可能是您将多个数据库复制为一个，或者有人在目标数据库中手动编辑了文档。
您可以删除目标数据库并重新创建一个空数据库。如果您不手动编辑目标数据库并且不将多个数据库复制到一个数据库中，那么 _deletes 将从那时起被正确复制。
问题已解决。 这是修订限制。 似乎快速进行超过修订限制的更改会导致复制机制出现问题。
CouchDB 中有一个关于此问题的未解决错误： https://issues.apache.org/jira/browse/COUCHDB-1649
由于我们的修订限制是 2，对同一文档进行 3 次连续更新，然后将其删除导致了这个问题。 将修订限制设置为 5 可以避免它。