Dear all,
I have known update handlers for quite long but I never used them "for real"
myself... My current idea, which must be very common, is to proxy updates of
whole documents in order to add some accountability of who contributed to the
document and when.
# rewrites.json
[{
"from": "",
"to": "elsewhere",
"method": "GET"
}, {
"from": "",
"to": "_update/accounting"
}, {
"from": ":object",
"to": "../../:object",
"method": "GET"
}, {
"from": ":object",
"to": "_update/accounting/:object"
}]
# accounting.js
function(doc, req) {
var o = JSON.parse(req.body);
o._id = o._id || req.id || req.uuid;
var h = doc && doc.history || [];
h.push({
user: req.userCtx.name,
timestamp: new Date()
});
o.history = h;
return [o, {json: {ok: true, id: o._id }}];
}
Tested on CouchDB 2.3.1, it *nearly* emulates the direct update of a document
and adds contributions accounting, however I face two problems ;
1. In the update handler, I see no way to get the new `_rev` value (which
should be returned either in the JSON body or as an ETag for compatibility with
normal update of an object). Is there a secret builtin function that could be
used to get (or set) this? Or is it set afterwards and then cannot be get or
set at this stage of the process?
2. In the update handler, when used with POST (with the `_id` in the body but
not in the URI), it seems that `doc` is always null (even when the ID refers
to an existing document)... Is this behaviour intended? I feel that the
documentation could be interpreted both ways...
Of course, we can still use PUT. But I wanted a complete emulation of normal
updates (with both methods)...
Any help or insight would be appreciated.
Regards,
Aurélien
