Dependencies 如何避免CouchDB中文档之间的循环依赖关系

我对CouchDB中文档之间的关系建模很感兴趣。假设我有三个文档A、B和C。这些文档可能相互引用，但有一个应用程序约束，即不能发生循环依赖

举个例子->是依赖项的标记：

A->B

C

两个客户端C1、C2尝试并发修改：

C1=B->C

C2=C->A

如果C1和C2成功，将出现循环。问题是如何预防它

我在考虑它，似乎我需要一种粗粒度的锁，用于文档和原子批量更新。问题是原子批量更新。CouchDB支持批量更新，但在版本冲突时不回滚。这意味着什么：

假设我们有文档V。该文档表示全局版本，并保存给定文档版本的相关文档A、B、C的版本

V {
  _rev: 1,
  versions: [[A,1],[B,1],[C,1]] 
}

C1和C2同时工作：

C1=获得V

C2=获得V

C1=得到A.1，B.1，C1

C2=获得A.1、B.1、C1

C1=进行依赖性检查，一切正常

C2=进行依赖性检查，一切正常

C1=更新V关于预期的B->C依赖项{版本：[[A，1]，[B，2]，[C，2]}一切正常

C1=更新B

C2=尝试更新V关于预期的C->A依赖项{versions:[[A，2]，[B，1]，[C，2]}由于CouchDB乐观锁定，此步骤将失败

在C1在第7步之间崩溃之前，一切都很好。八,。现在，批量插入/更新将进入场景

七,。C1=更新V关于预期的B->C依赖项{版本：[[A，1]，[B，2]，[C，2]}一切正常，更新B

这是一个多么好的解决方案，不幸的是，由于CouchDB中的批量插入/更新语义，它根本不起作用。大容量插入/更新不是原子操作

有什么解决办法吗？我可以绕过它吗？我错过什么重要的事了吗

两个客户端C1、C2尝试并发 修改：

C1=B->C

C2=C->A

如果C1和C2成功，则 周期问题是如何预防 是吗

这是无法避免的。如果C1对服务器X起作用，C2对服务器Y起作用，并且X和Y未在网络上连接，该怎么办。当X和Y重新连接并复制时，文档B和C都将被编辑

---

当我们说CouchDB在单个文档上是事务性的时，这就是我们的意思。

如果我可以在这里加上$0.02，关系实际上并不适用于基于文档的数据库世界

考虑在引用方面重新思考模型，就像一个文档引用另一个文档，另一个文档引用第一个文档一样。这对于文档来说是完全正常的，但是来自关系世界的我们都有思维惯性的问题：