Javascript couchdb/cloudant更新处理程序未按预期工作

我正在开发一个使用Cloudant作为数据库的应用程序。在这种情况下，我几乎同时对同一个文档进行两次数据库调用，但由于它，我得到了一个冲突错误。因此，我尝试在cloudant数据库中创建一个更新处理程序函数，如下所示：

{
  "_id": "_design/_updateHandler",
  "updates": {
    "in-place": "function(doc, req) {
        var field = req.body.field,
        var value= req.body.value,
        var doc[field] = value;
        return [doc, toJSON(doc)];
    }"
  }
}

它会在文档中添加一个字段，但不会更新该字段的现有字段。这是预期的行为吗？在这座城市里，情况并非如此

如果没有，如何解决此问题，使其更新现有字段？ 此外，正如中所回答的，更新处理程序函数仍然会得到更新冲突，但如何避免它呢

---

提前感谢：）

这里是一个与CouchDB和Cloudant兼容的更新函数的工作示例，它可以完成您想要完成的任务——更新单个字段

function(doc, req) {
  if (!doc) doc = {_id: req.uuid};
  var body = JSON.parse(req.body);
  var field = body.field;
  var value = body.value;
  doc[field] = value;
  return [doc, JSON.stringify(doc)];
}

POST

请求的主体被认为是有效的JSON，因此您可能需要对

application/JSON

执行一些头检查

此外，如果您只计划像这里这样做field=value，那么

application/x-www-form-url-encoded

会更好，因为它会降低负载大小和解析时间——CouchDB和Cloudant会将该媒体类型自动解析到

req.form

对象中

最后，最好不要在顶级字段和

\u id

值的开头将下划线作为保留字符作为您给CouchDB或Cloudant的任何内容的前缀。

\u design/\u updateHandler

名称（随后）非常混乱

下面是要复制/粘贴到数据库中的JSON，以获得一个工作的更新函数来完成您想要的任务：

{
    "_id": "_design/overwrite",
    "updates": {
        "in-place": "function(doc, req) {\n  if (!doc) doc = {_id: req.uuid};\n  var body = JSON.parse(req.body);\n  var field = body.field;\n  var value = body.value;\n  doc[field] = value;\n  doc.body = body;\n  return [doc, JSON.stringify(doc)];\n}"
    }
}

要更新现有文档，您需要发出如下HTTP请求（其中，

bigbluehat

是以前存储的文档的id:

POST /db/_design/overwrite/_update/in-place/bigbluehat
Content-Type: application/json

{"field": "name", "value": "BigBlueHat"}

或者，如果您没有在请求URL中包含文档

\u id

，您将获得一个新文档，它使用

req.uuid

值来存储一个新文档

---

希望能有所帮助！

我建议您使用建议锁定机制；或重试冲突。对于建议锁定，您可以简单地使用memcache/redis；或内存字典；或cloudant中的锁定文档。对于重试冲突方法，只需重新应用对冲突错误的更改（http 409）。您粘贴的示例代码有很多错误…var语句后面有逗号，

var doc

当doc已定义时，等等：（您是否有更新的代码？或者与您正在尝试的代码更接近的代码？您可以在浏览器控制台中自行测试该函数，以首先清理JS。此外，CouchDB文档中的示例比一个更容易迭代。）在维基中：谢谢你指出代码错误！我因为冲突而沮丧，最终得到了这段代码，什么都没有发生。我仍然对解决冲突的最佳方法有问题。现在我使用的是萨法克·乌鲁索伊的解决方案，但感觉不对。有更好的解决方法吗？忘了提及……非常有用还有提示！冲突并不一定是坏的。：）这取决于它们发生的原因，你是否可以设计它们（或为它们设计），以及它的根本原因是什么——对单个文档的过于频繁的更新实际上应该存储在多个文档中？（mis）将CouchDB用于Redis更擅长的东西（内存计数）？等。可能会发布另一个问题，然后打电话给我^_^