将简单的CouchDB用于CouchDB压缩对删除的文档完全无动于衷的理论.
在尝试检索时,通过DELETE方法从沙发中删除文档会产生以下结果:
localhost:5984/enq/deleted-doc-id {"error":"not_found","reason":"deleted"}
预期.
现在我压缩数据库:localhost:5984/enq/_compact {'ok':true}
并检查压缩是否已完成"compact_running":false
现在,我希望向CouchDB的返回NOT_FOUND,原因就一个简单的GET本地主机 "失踪":5984/ENQ /删除-DOC-ID { "错误": "NOT_FOUND", "原因": "已删除"}
尝试使用？rev = deleted_rev给了我一个完整的文档,是的,对于毫无价值的数据.
因此,我认为couchdb压缩对已删除的文档没有特殊处理,并在决定压缩的一部分时简单查看rev count again rev limit.我们可以为已删除的文档设置特殊的rev_limit吗？
当然唯一的解决方案不能是_purge？目前我们必须拥有数千个孤立的已删除文档,虽然我们希望维护正常文档的某些版本历史记录,但我们不希望将rev_limit减少为1以协助此方案
清除时我们应该注意哪些复制问题？
删除的文档将永久保留(因为它必须在副本之间提供最终的一致性).所以,你描述的行为是故意的.
要尽可能高效地删除文档,请使用DELETE谓词,因为它只存储_id,_rev和已删除的标志.当然,您可以通过POST或PUT手动实现相同的操作.
最后,_purge仅存在于极端情况下,例如,您已将重要密码放入couchdb文档并需要将其从磁盘中删除.它不是修剪数据库的推荐方法,它通常会使您拥有的任何视图无效(强制完全重建),也会使复制混乱.
添加文档、删除文档然后压缩不会将 CouchDB 数据库恢复到原始状态。已删除的文档通过压缩保留，尽管在通常情况下生成的文档很小（只有 _id、_rev 和 _deleted=true）。其原因是复制。想象一下以下情况：
如果在删除+压缩后文档被完全删除，那么第二次复制将不知道告诉远程数据库文档已被删除。这将导致两个数据库不一致。
报告了一个问题，可能导致数据库中的文档不小；然而它与 HTTP DELETE 方法 AFAIK 无关（尽管我可能是错的）。门票在这里：
https://issues.apache.org/jira/browse/COUCHDB-1141
基本思想是审计信息可以包含在 DELETE 中，并通过压缩保留。确保您没有使用 DELETE 方法发布完整的文档正文（这样做可能会解释为什么文档实际上没有被删除）。