Hi Aurélien, we generally recommend doing this kind of stuff outside of CouchDB, these days.
A Node.js proxy that does this completely and reliably is maybe 50 lines of code and not a huge operational overhead, while granted not as neat as doing all this inside of CouchDB. As for getting the new _rev in the function: the rev will be generated from the result that the function returns, so there is no way to get that other than calculating it yourself (it is deterministic), but that requires knowledge of erlang term encoding and such things. I’ve done it in JS (for other things), but it is not pretty. Best Jan — Professional Support for Apache CouchDB: https://neighbourhood.ie/couchdb-support/ 24/7 Observation for your CouchDB Instances: https://opservatory.app > On 27. May 2021, at 22:08, Aurélien Bénel <[email protected]> wrote: > > 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 > >
