Consider using JS _rewrite for this, it can do whatever you want with your request. https://docs.couchdb.org/en/2.3.1/api/ddoc/rewrites.html?highlight=_rewrite#using-a-stringified-function-for-rewrites
Please note, that JS _rewrite in v 2.3.1 has a bug which may cause inbound attachments to drop (https://github.com/apache/couchdb/issues/1878), it was fixed in 3.0 afaik. ermouth чт, 27 мая 2021 г. в 23:09, Aurélien Bénel <aurelien.be...@utt.fr>: > 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 > > >