从CouchDB副本中删除文档

Question

我们的产品使用每个客户端的中央CouchDB数据库复制到在用户的iPad上运行的应用程序。大多数数据库都可以正常复制，但我们要过滤两类文档：

1. 拥有所有者的文档 - 我们希望仅将复制过滤到当前用户文档（以及没有指定所有者的文档）。
2. 某些类型的最后X个文档。对于某些类型的文档，我们只想在iPad上留下最后10个（比方说）副本。

我们可以使用过滤复制轻松设置两个规则 - 这样服务器只会将我们想要的文档子集呈现给iPad进行复制。除了......它不起作用。

1. 如果文档没有所有者（已复制），稍后指定了所有者，则它将从复制流中消失 - 但不会从iPad中消失。实际上，保留在iPad上的文档版本仍然没有所有者，因此我们甚至无法将其隐藏在代码中。
2. 当文档成为第11个最早的文档并从复制流中消失时，它不会从iPad中消失。事实上，除非iPad数据库被重建，否则这些文档的所有版本都会在那里完成，并且不再复制，这比首先复制它们更糟糕。

我们确实找到了一个hacky解决方法 - 在文档获得新所有者或者比X更旧的情况下，我们复制它并删除原始文件。删除传播到iPad，新文档被过滤掉复制。这很好用（尽管效率有点低）。然而，我们意识到新复制的文档已丢失所有修订信息，我们依靠修订来跟踪更改！

那么 - 有没有人有任何其他建议？我们正在寻找的是一种根据需要从iPad副本中提取文档的机制。我知道我们可以指示iPad在本地删除文件 - 但迟早这些删除会泄漏回服务器并破坏原件？

Answer 1

  

......我们依靠修订来跟踪变化

恕我直言，这是谈论替代解决方案最有趣的一点。

对不起，我不得不说你以不推荐的方式使用CouchDB版本控制。文件修订是暂时的。跟踪文档更改的最佳方法是在文档内部或外部编写更改日志。

您如何在文档本身之外保留更改 - 是的，您将创建新文档。 惊喜：你＆＃34; Hack＆＃34;是正确的解决方案\ o /

也许你摇头，你不开心，因为你试图从iPad上删除文档，使它们成为隐形的客户端。那是你＆＃34; Hack＆＃34;的起点，对吧？

我的建议是不要结合＆＃34;可见性＆＃34;和＃34;存在＆＃34;。更好的方法是使用你的专有技术来构建服务器端的视图索引，就像客户端与PouchDB一样。 让复制只是处理复制 - 这很难。使用客户端和服务器端的视图/过滤器来解决可见性要求。