Ipad 从CouchDB副本中删除文档

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

有所有者的文档—我们希望只将复制筛选到当前用户文档（以及没有指定所有者的文档）

最后是一些类型的X文档。对于某些类型的文档，我们只想将最后10份（比如）留在iPad上

使用过滤复制，我们可以很容易地设置这两个规则，这样服务器只向iPad提供我们想要复制的文档子集。除了它不起作用

如果一个文档没有所有者（已复制），并且后来指定了所有者，它将从复制流中消失，但不会从iPad中消失。事实上，保存在iPad上的文档版本仍然没有所有者，因此我们甚至无法将其隐藏在代码中

当文档成为第11个最早的文档并从复制流中消失时，它不会从iPad中消失。事实上，除非重建iPad数据库，否则这些文档的所有版本都会在那里结束，不再复制，这比一开始就复制它们更糟糕

我们确实找到了一个黑客的解决方法——在文档获得新所有者或比X旧的情况下，我们复制它并删除原始文档。删除操作将发布到iPad上，新文档将从复制中筛选出来。这已经足够好了（尽管效率有点低）。然而，我们意识到新复制的文档丢失了所有的修订信息，我们依靠修订来跟踪更改

那么，有人有其他建议吗？我们正在寻找的是一种按需从iPad副本中提取文档的机制。我知道我们可以指示iPad在本地删除这些文档，但这些删除操作迟早会泄漏回服务器并销毁原始文档

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

这是谈论替代解决方案最有趣的一点

我很抱歉，但是我不得不说，您使用CouchDB修订控件的方式并不推荐。文件修订是临时性的。跟踪文档更改的最佳方法是在文档内部或外部编写更改日志

您将如何在文档本身之外保留更改-是的，您将创建新文档惊喜：您的“黑客”是正确的解决方案\o/

也许你摇了摇头，你的电脑不高兴，因为你试图从iPad上删除文档，让它们在客户端看不见。那是你“黑客”的起点，对吗

我的建议是不要把“可见性”和“存在性”结合起来。更好的做法是在服务器端使用构建视图索引的专有技术，就像在客户端使用数据库一样让复制只处理复制-这已经够难了。使用视图/过滤器客户端和服务器端解决可见性要求。