Javascript 在CouchDB中使用JSON模式

我想问一下CouchDB中JSON示意图的良好实践。现在我使用纯CouchDB 1.6.1。我在没有任何couchapp框架的情况下处理它（我知道这是有用的，但我担心它将来会起作用）

• CouchDB中的模式放在哪里？作为常规文件？设计文件？或者将它们存储为文件？但如果我要验证它们，特别是服务器端的validate_doc_update函数，它们应该存储在设计文档中

• 有没有库（最好是JavaScript）在CouchDB和客户端（Web浏览器）中运行？库可以自动生成JSON并验证它们吗

• 我考虑如何将数据发送到客户端，将其存储在输入标记中，然后以某种方式收集并发送到serwer。可以将输入id设置为字段的路径，例如：
  { “地址”：{ “街道”：“xxx”， “Nr”：“33” } }

---

在这种情况下，输入可以有id=“address.”Street”，但我不知道这是一个好的解决方案。我应该从服务器发送模式，并使用此模式构建JSON对象，但不知道如何使用（如果JSON中的所有字段都有唯一的名称，包括层次结构）.

也许最好的选择是使用。您在中实现了。我在javascript中成功地使用了

---

为了与CouchDB集成，我认为最好的选择是定义一个json模式并使用json模式javascript验证器。

在探索CouchDB在表单中相对于数据用例的潜在优势时，你问了我多年来遇到的同一个问题

最初，我希望找到一种基于相同的JSON模式定义和验证代码（服务器端和客户端）的数据验证方法。结果表明，这不仅是可能的，而且还有一些额外的优势

在CouchDB中把模式放在哪里？作为常规文档？设计文档？或者作为文件存储？但是如果我想验证它们，特别是服务器端的validate_doc_update函数，它们应该存储在设计文档中

你说得对。设计文档（ddoc）也包括在文档更新之前执行验证的validate_doc_update函数，它是放置模式的最常见位置。

validate_doc_update函数中的这个

就是ddoc本身-ddoc中包含的所有内容都可以通过验证代码访问

我已经开始将模式作为JSON对象存储在公共JS模块的常规库属性/文件夹中，例如

lib/schemata.JSON

。我文档的

type

属性指定了文档更新验证应该获取的模式的键，例如

type:'adr'

->

lib/schemata/adr

。模式也可以引用每个属性的er到其他模式-递归验证函数已经遍历到任何属性的末尾，不管嵌套属性是什么类型的。它在第一个项目中运行良好

{
  "person": {
    "name": "/type/name",
    "adr": "/type/adr",
    ...
  },
  "name": {
    "forname": {
      "minlenght": 2,
      "maxlength": 42,
      ...
    },
    "surname": {
      ...
    }
  },
  "adr": {
    ...
  }
}

但后来我想在另一个项目中使用该模式的子集。简单地复制它并添加/删除一些模式太短视了。如果像地址这样的通用模式有一个bug，并且需要在使用它的每个项目中更新，该怎么办

此时，我的模式存储在存储库中的一个文件中（我用作DDoS的上载工具）。然后我意识到，当我将每个模式存储在一个单独的文件中时，例如

adr.json

、

geo.json

、

tel.json

等。它会在服务器ddoc中产生与以前使用单文件方法相同的json结构。但它更适合于源代码管理。不仅文件越小，合并就越少冲突和更清晰的提交历史-还启用了通过子存储库（子模块）的模式依赖关系管理

另一个想法是使用CouchDB本身作为模式存储和管理场所。但正如您自己所提到的，模式必须在validate_doc_update函数中可访问。首先，我尝试了一种使用更新处理程序的方法-每个文档更新都必须通过一个从数据库获取正确模式的验证更新处理程序CouchDB本身：

POST /_design/validator/_update/doctype/person

function (schema, req) {
   ... //validate req.body against schema "person"
  return [req.body, {code: 202, headers: ...}]
}

但是这种方法不能很好地处理嵌套模式。更糟糕的是，为了防止未经处理程序验证的文档更新，我不得不在CouchDB前面使用代理来隐藏直接的内置文档更新路径（例如，POST to/the/doc/_id）。我没有找到在validate_doc_update函数中检测更新处理程序之前是否参与的方法（可能其他人参与了？我很乐意阅读这样的解决方案）

在调查过程中，同一架构的不同版本的问题出现在我的雷达上。我应该如何管理？来自同一类型的所有文档必须对同一架构版本有效吗（在几乎每次架构版本更改之前需要db范围的数据迁移意味着什么）？类型属性是否还应包括版本号？等

---

但是，等等！如果文档的架构附加到文档本身怎么办？它：

• 将为每个文档的文档内容提供兼容版本
• 可在验证文档更新功能中访问（在

  oldDoc

  中）
• 可以在没有管理员访问权限的情况下复制（如您需要ddoc更新）
• 将包含在客户端文档请求的每个响应中

这听起来很有趣，我觉得这是迄今为止最具CouchDB风格的方法。说得清楚一点——文档的模式附加到文档本身——意味着将其存储在文档的属性中。作为附件的存储和将模式本身作为文档结构的使用都没有成功。

这种方法最敏感的时刻是文档CRUD生命周期中的C（创建）。有许多不同的解决方案

{
  "_id": "_design/schema",
  "libs": {
    "tv4": // Code from https://raw.githubusercontent.com/geraintluff/tv4/master/tv4.min.js
  },
  "validate_doc_update": "..."
  "schema": {
    "title": "Blog",
    "description": "A document containing a single blog post.",
    "type": "object",
    "required": ["title", "body"],
    "properties": {
      "_id": {
        "type": "string"
      },
      "_rev": {
        "type": "string"
      },
      "title": {
        "type": "string"
      },
      "body": {
        "type": "string"
      }
    }
  }
}

function(newDoc) {
  if (newDoc['_deleted']) return;

  var tv4 = require('libs/tv4');

  if (!tv4.validate(newDoc, this.schema)) {
    throw({forbidden: tv4.error.message + ' -> ' + tv4.error.dataPath});
  }
}