具有动态用户组的CouchDB复制策略

有这种情况的解决方法吗？我是否缺少明显的解决方案？

案例1的部分解决方案：

每个remove（）给我409（冲突），是这样。有没有办法告诉Pouch不再将其视为可复制的，而只是将其从数据库中删除？

（3 ）对我来说似乎是最简单的解决方案，即每个角色的数据库解决方案。

我认为您的困难源于试图管理文档内部的权限（然后是使用过滤复制）。当您这样做时，您基本上是在尝试在文档中镜像CouchDB的权限系统，这会引起麻烦。

为什么不为每个角色创建数据库并分配使用常规 _users 数据库的用户角色？如果角色更改，则用户将失去或获得对一组文档的访问权限。您需要具有服务器端点来处理角色转换，或者需要设置具有特殊特权的单独的管理数据库，用户可以在其中更改角色。

然后，如果用户失去对a的访问权限文档中，它们只会在复制期间出现401错误（在实时复制期间会显示在'denied'事件中）。不需要ddocs或经过筛选的复制-简单得多！

This is the situation: We have a series of users who share some documents. The documents they can share might change throughout the day, so can the documents themselves (changes and deletions). The users can change some information on the documents. E.g. Users | Documents A | X A | Y A | Z B | X B | Z C | Y

Possible groups: A+C, A+B

The server on CouchDB is a replica of a SQL Server DB with this data, an ETL takes care of managing changes on CouchDB. However, the CouchDB database is replicated on each user phone via PouchDB.

The goal: To replicate changes and deletions accordingly.

What we've tried: 1) we figured we'd structure our documents with a list of users that can access to it. Each document would have a "Users" array and then a filter in the design document would take care of the replication to the clients. Unfortunately document deletions and document changes that won't pass the filter (e.g. a user is removed from the array) are not present in the _changes feed so cannot be replicated accordingly on the clients 2) database per user. This is not possible, because users need to see each others work on the documents (they share them) 3) database per group of users. Pretty much the same problem as the first solution, but worse. In fact: - groups of user can change and no longer be present: how do reflect that client-side? - a document can shift to a new group: it will have to be redownloaded from scratch. This greatly increases the download size - the same document can be in more than one group! (see example above) - each client would have to know in which group she is everytime she logs in and replicate multiple databases. Then on the return trip you'd have to know on which databases the document was present

Is there a recipe for this situation? Am I missing an obvious solution?

Partial solution for case 1:

Each remove() is giving me a 409 (conflict), and rightfully so. Is there a way to tell Pouch "no longer consider this as replicable and just remove it from my DB?"

(3) Seems like the simplest solution to me, i.e. the "database per role" solution.

I think your difficulty stems from trying to manage permissions inside the documents themselves (and then using filtering replication). When you do that, you are basically trying to mirror CouchDB's permission system inside your documents, which is going to cause headaches.

Why not create a database per role, and assign roles to users using the normal _users database? If roles change, then users will lose or gain access to a set of documents. You would need to have server endpoints to handle the role-shuffling, or you would need to set up separate "admin" databases with special privileges, where users can change the roles.

Then on the client side, you can either replicate from multiple CouchDB databases into a single PouchDB (and then collate the results together yourself), or into a single PouchDB (probably a bad idea if you need to sync bidirectionally). Obviously you would need an initial step where you determine which databases the user has access to, but that's a small downside in my opinion.

Then if the user loses access to a document, they will simply get normal 401 errors during replication (which will show up in the 'denied' event during live replication). No need for ddocs or filtered replication - much simpler!