我希望在单个couchdb实例上具有绝对原子性（插入，如果已经存在则失败）

我真的很喜欢couchdb风格的组织和更新数据，但在一些情况下，我确实需要能够创建一个条目，并在返回给用户之前确定是否已经存在一个等效条目。对于我的应用程序来说，这是绝对必要的唯一情况是用户注册。我可以让所有的用户注册写入转到一个特定的、指定的couchdb实例，称为“注册实例”

我想把用户id散列成一些要使用的id。然后使用此_id执行put，但如果已插入_id，则执行失败。我需要返回给用户，用户名已经被保留，我无法在稍后检测到冲突并解决它，因为用户会觉得他们已经保留了用户名

---

我不明白为什么couchdb不能提供一些方法来实现这一点，因为假设您指定特定“类型”文档的插入总是路由到特定实例。

如果您向单个couchdb服务器发送一个新用户文档的PUT请求，您应该已经获得了所需的行为

如果文档不存在，它将创建新文档

如果文档确实存在，则保证返回409冲突错误。这是因为您没有提供_rev属性，因为您没有尝试更新预先存在的文档

只有当_id和_rev属性匹配时，CouchDB才会更新现有文档

您可能还想了解文档更新处理程序：

您可以使用更新处理程序散列用户id并动态分配相应的id。您还可以自定义Coach使用更新处理程序发送的错误响应类型

---

祝你好运

您正在操作couchdb服务器群集吗？或者当你说实例时，你真的是指数据库吗？（您可能只需要为注册指定一个单独的数据库，并在多个couchdb服务器之间连续复制该数据库。然后写操作可以在任何地方进行，这不会出现问题。）是的，但在多主机环境中，行为必须不同于只有一个couchdb实例，对吗？无法知道您的_id是否与另一个发生冲突，因为数据可能没有传播到您正在写入的实例（在多主机情况下）。你是说当couchdb在单个实例上检测到冲突时，行为是不同的，因为客户端会立即得到通知，而不是在“事后”冲突处理程序中处理冲突？是的，有多个服务器会使事情复杂化。尽管你可能会发现沙发的复制速度足够快，在实践中不会成为问题。我的观点是，如果新文档无法创建，客户会立即知道，因为具有相同id的文档已经存在。您的最后一句话只是描述了具有该id的文档存在于特定数据库中的情况，对吗？您可能希望更新您的答案，以描述这两种情况及其差异。出于我的目的，用户名的所有写入都会进入一个实例，因此需要这种行为。有一件事你忘了提，那就是我们是否“保证”能及时发现冲突。也就是说，couchdb的单个实例是否一致？我更新了我的答案，以澄清我只讨论单个couchdb服务器实例，因为您的问题指定了对单个实例的写入。是的，如果你试图插入一个数据库中已经存在的带有_id的文档，CouchDB肯定会立即对你大喊大叫。关于你的集群，我想补充一点，写入单个CouchDB服务器进行用户注册当然是可以的。但是请记住，您仍然必须将新的用户文档复制到其他couchdb服务器。如果要对这些数据库进行连续复制，为什么不让用户注册写入任何数据库？我的意思是，如果您认为复制速度不够快，那么您还应该担心读取新创建的用户注册文档。