CouchDB自动生成字段

我的文档中有

ctime

和

mtime

（创建/修改的时间）字段

我怎么能让couchDB帮我处理这些？例如：

// Create a dog
curl -X POST http://localhost:5984/dogs -d '{"name": "Bill"}'
{"ok":true,"id":"75efaeb93aa2ed75ffa0abf9f5006d40","rev":"1-49ce25e3db701c8cb613c1fd18d99619"}

->

ctime

和

mtime

应自动生成

// Update a dog
curl -X PUT http://localhost:5984/dogs/75efaeb93aa2ed75ffa0abf9f5006d40?rev=1-49ce25e3db701c8cb613c1fd18d99619 -d '{"name": "BILL"}'

->

mtime

应自动更新

---

我使用

validate\u doc\u update

来处理这个问题，比如：

function (newDoc, oldDoc, userCtx) {
  //
  // sanity checks
  //

  if (oldDoc && newDoc.ctime) throw {"forbidden": "ctime cannot be changed!"}

  ...

  //
  // Auto-generate fields
  //

  var now = new Date().toISOString();

  // mtime
  newDoc.mtime = now;

  // ctime
  if (!oldDoc) newDoc.ctime = now;
}

但是运气不好：它似乎对

newDoc

没有任何影响（通过复制？）

---

谢谢

否，您不能在

验证文档更新

功能中修改文档内容。如果使用或通过充当服务器端处理程序，则需要在客户端上设置此值。在

validate\u doc\u update

功能中，您只能验证此值并接受/拒绝文档的新版本

由于时间戳不容易控制，客户端可能很容易用“不正确”（非实际）的值绕过您的更新处理程序，因此我认为唯一的解决方案是在当前时间戳的特定范围内验证

mtime

（+/-2-3秒是正常范围），并要求

ctime

字段用于初始文档版本

---

但是这种验证是有缺陷的，因为您将破坏复制：复制的文档将具有过去的

ctime

和

mtime

字段，在这种情况下，验证函数将拒绝它。

否，您不能在

验证文档更新
函数中修改文档内容。如果使用或通过充当服务器端处理程序，则需要在客户端上设置此值。在
validate\u doc\u update
功能中，您只能验证此值并接受/拒绝文档的新版本

由于时间戳不容易控制，客户端可能很容易用“不正确”（非实际）的值绕过您的更新处理程序，因此我认为唯一的解决方案是在当前时间戳的特定范围内验证
mtime
（+/-2-3秒是正常范围），并要求
ctime
字段用于初始文档版本

但是这个验证是有缺陷的，因为你会破坏复制：复制的文档将有过去的
ctime
和
mtime
字段，在这种情况下，验证函数将拒绝它。
可能是一个带有。。。任何例子（欢迎！）也许是一条有。。。任何例子（欢迎！）1.好的，我知道我无法在
验证\u doc\u update
中“编辑”文档。2.关于复制和验证时间的有趣内容：我没有想到这个问题。结论：什么结论？：）简单的方法是信任客户机，不验证
[cm]时间
。另一方面，更新处理程序将需要额外的HTTP请求，仅用于创建这些字段：这并不理想……结论很简单：
ctime
在文档创建时需要，但不允许他将来进行修改
mtime
允许修改，但新值应该比当前值大，并且仍然比现在小（确保您已处理UTC）。关于复制，请做一个决定：使用旧
mtime
的文档是否可以覆盖新文档。如果可以-为那些人制定规则，说明如何覆盖这些值（由文档作者、特殊角色等），并且永远不信任用户数据（：除非经过您的验证。因此，对于客户端，一切都很简单：他们会让自己的逻辑与您的逻辑保持一致，或者他们会使用您的更新处理程序。在某些时候，维护人员会厌倦一次又一次地修复文档存储，他们会高兴地切换到您的更新处理程序。当然，仍然有一些窗口可以打破这一局面gic，但一切都取决于这些字段对您的价值有多大，您能允许对它们进行一些不正确的修改吗？至于我，我现在遵循相同的策略，没有任何严重的问题。1.好的，我知道我不能“编辑”
validate\u doc\u update
中的文档。2.关于复制和验证时间的有趣内容：没有想到这个问题。结论：什么结论？：）简单的方法是信任客户，而不验证
[cm]时间
。另一方面，更新处理程序将需要额外的HTTP请求，仅用于创建这些字段：这并不理想……结论很简单：
ctime
在文档创建时需要，但不允许他将来修改。
mtime
允许修改，但新值应该比当前值大，并且仍然比现在小（确保您已经处理了UTC）。关于复制，只需做一个决定：使用旧
mtime
的文档是否可以覆盖新文档。如果可以-为这些文档制定规则，如何覆盖此类值（由文档作者、特殊角色等）。并且永远不要信任用户数据（：除非经过您的验证。因此，对于客户端，一切都很简单：他们会让自己的逻辑与您的逻辑保持一致，或者他们会使用您的更新处理程序。在某些时候，维护人员会厌倦一次又一次地修复文档存储，他们会高兴地切换到您的更新处理程序。当然，仍然有一些窗口可以打破这一局面gic，但一切都取决于这些字段对您的价值有多大，您能允许对它们进行一些不更正吗？至于我，我现在遵循相同的策略，没有任何严重问题。