couchdb - 每个用户数据库(pouchdb/couchdb)和共享数据 - 可行吗？

Question

我有以下用例/应用程序:

一个 TODO 应用程序，用户可以: CRUD 他们的 TODO(我正在使用 pouchdb/couchdb 同步)。几乎基于 Josh Morony 的 tutorial

现在我想增加用户与其他用户“共享”(仅发布，没有“编辑”/放置)他们的 TODO 项目的能力，这些用户只能查看(读取)那些(没有写访问权限等)。

我正在考虑添加一个单独的数据库(我们称之为“共享 TODOs 数据库”)，我的服务器可以在其中写入，而所有用户只能读取。
因此，任何用户都可能在该只读数据库上执行 .find() 操作，而在该数据库中发布仍将由服务器根据来自用户的共享 TODO 请求进行管理。

是否有已知的模式(方法)？是否有任何真正的应用程序/示例已经这样做了？

Answer 1

CouchDB 没有提供一个很好的方法来做到这一点，但如果你的后端有一个维护大量共享数据库的工具(除了单用户数据库)，我认为你可以完成它。

最初的冲动是使用与中央“主”集线器之间的连续过滤复制，但这会给您带来两个问题:

复制不能删除文档，除非它们被删除! IE。过滤复制不会确定目标中存在哪些文档，而是确定文档的更改是否会传播到目标。这样做的效果是可以分享，但不能取消分享。

这种复制无法扩展。对于需要保持同步的 N 个用户数据库，对中央数据库的每次更改都会强制所有 N 个复制独立处理该更改。现在考虑中央数据库上发生的更改量 M 几乎与 N 成正比(即，您拥有的用户越多，所有这些用户将不得不处理对中央数据库的更改的频率越高!)您可以在一定程度上缓解这种情况通过添加更多层(从一个中央集线器到半共享集线器再到单个数据库)，但这也增加了实际的复杂性。

您的分享是如何组织的？您可以做的是为每个“共享”组合设置一个共享数据库。

当用户 A 想与用户 B 共享文档 D 时，将文档“移动”到新的数据库 AB 中。实际上这意味着:将 D 的内容复制到数据库 AB 中的新文档 D' 中，然后从数据库 A 中删除原始 D。

这是如何同步的？

请记住，PouchDB 客户端可以复制到多个源数据库/从多个源数据库复制，因此用户 A 将从 A 和 AB 复制，而用户 B 从 B 和 AB 复制。诀窍是在相反的方向使用过滤复制，回到服务器数据库:

现在共享的文档 D' 不应该进入数据库 A 或数据库 B，同样，未共享的文档 X 也不应该进入数据库 AB。像这样的东西:

┌───────────────────────┐                                  
│  server:5984/user_a   │                                  
└───┬───────────────▲───┘                                  
    └─┐           ┌─┘    ┌──────────────────────────────┐  
      │           ●──────│ if (doc.shared_with == null) │  
    ┌─▼───────────┴─┐    └──────────────────────────────┘  
    │     local     │                                      
    └──▲──────────┬─┘                                      
     ┌─┘          └─┐      ┌──────────────────────────────┐
     │              ●──────│ if (doc.shared_with == 'ab') │
 ┌───┴──────────────▼────┐ └──────────────────────────────┘
 │ server:5984/shares_ab │                                 
 └───────────────────────┘              

因此，假设共享数据库已经建立，当本地客户端想要共享一些数据时，它实际上添加了 _deleted:true。到原始(未共享)文档并创建一个新(共享)文档。删除的原始文件传播到服务器上的 user_a 数据库，创建的副本传播到 share_ab。

然后取消共享的工作原理几乎相同:客户端添加 _deleted:true到共享文档并在新的非共享副本中重新创建数据。从 B 的角度来看，该文档曾经出现在 share_ab 中，但现在消失了，因为它已从 share_ab 中删除。

(而不是用户“对”，您可以将其扩展到特定的用户集，或将其简化为用户已经在的特定组，或诸如此类。关键思想是为所需的每个唯一共享上下文创建一个实际共享的数据库.)