1

I've got ctime and mtime (created/modified time) fields in my docs.

How can I let couchDB handle those for me? For example:

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

-> ctime and mtime should be auto-generated

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

-> mtime should be updated automatically


I was hopping using validate_doc_update to deal with this, something like:

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;
}

but with no luck: it appears altering newDoc has no effect (pass by copy?)

Thank you

abernier
  • 27,030
  • 20
  • 83
  • 114

1 Answers1

1

No, you cannot modify document content within validate_doc_update function. You need to set this value on client if you're using Document API or via update handlers which acts as server side handlers. At validate_doc_update function you only could validate this value and accept/reject new version of the document.

Since timestamping is not easy to control and clients may easy by pass your update handlers with "incorrect" (non actual) value, I see only solution to validate mtime within specific range from current timestamp (+/- 2-3 seconds is ok range) and require ctime field for initial document version.

But this validation is buggy, since you'll have broken replication: replicated documents will have ctime and mtime fields from the past and validate function will reject it in this case.

Kxepal
  • 4,659
  • 1
  • 19
  • 16
  • 1
    1. Ok, I understand I cannot "edit" the document inside `validate_doc_update`. 2. Interesting stuff about replication and validating time: haven't thought to that issue. Conclusion: what conclusion? :) The simple way would be to trust the client and do not validate `[cm]time`. Update handlers on the other hand would require an additional HTTP request, just to create those fields: this is not ideal... – abernier Nov 12 '12 at 12:56
  • 1
    Conclusion is simple: `ctime` required on document creation, but his future modification is not allowed. `mtime` modification is allowed, but new value should be great than current one and still lesser than *now* (make sure that you have deal with UTC). About replication just make a decision: could documents with *old* `mtime` override *new* ones. If could - make a rules for those one how may override such value (by document author, special role etc.). – Kxepal Nov 12 '12 at 13:32
  • And never trust users data(: unless it is validated by you. So with clients everything is simple: they will keep their logic up to dated with yours or they will use your update handlers. At some point maintainers will be bored fixing document storing again and again and they will switch to your update handlers with happy. Surely, there is still some window to break this logic, but everything depend from how much this fields are valuable for you and could you allow some incorrection for them? As for me, I'm following same strategy now without any serious problems. – Kxepal Nov 12 '12 at 13:38