Aha, ok, that makes more sense. oldDoc will be null in that case to match the behavior when there was never a document there, but it's definitely a debatable nuance. I'm in favor of the existing behavior but I do see your point.
B. On 17 May 2013 16:31, Jim Klo <[email protected]> wrote: > No, I think I incorrectly described the condition where this happens. > > If I first delete a doc with extra info like you illustrated, and then > re-insert the doc as new, the VDU does not get the existing delete "stub" in > my experience. If this has changed in 1.3, I'd welcome it. > > It would be useful if the VDU got the existing "deleted" document in certain > use cases, like a document got removed for DCMA violation - I don't want it > to reappear by mistake. I'd like to have the right logic in my VDU to check > the notes in the existing deleted stub before permitting the insert. There's > ways around this which I use instead, but think that if there's a stub that > could be handed to VDU, it should. > > > - JK > > Sent from my iPhone > > On May 17, 2013, at 7:41 AM, "Robert Newson" <[email protected]> wrote: > >> VDU does receive the 'stub', which is always a document. The term >> 'stub' can mislead people into thinking a deleted document is not an >> actual document (it is). >> >> Here I insist that deleted documents have a reason; >> >> ➜ ~ curl localhost:5984/db1/_design/foo -XPUT -d >> '{"validate_doc_update":"function(newDoc) { if(newDoc._deleted && >> !newDoc.reason) { throw({forbidden:\"must have a reason\"}); } }"}' >> {"ok":true,"id":"_design/foo","rev":"1-ab8a8ecd8cf3de35ed7541facfb75029"} >> >> An empty doc; >> >> ➜ ~ curl localhost:5984/db1/bar -XPUT -d {} >> {"ok":true,"id":"bar","rev":"1-967a00dff5e02add41819138abb3284d"} >> >> I try delete with DELETE method, which just does _id, _rev, _deleted. >> >> ➜ ~ curl 'localhost:5984/db1/bar?rev=1-967a00dff5e02add41819138abb3284d' >> -XDELETE >> {"error":"forbidden","reason":"must have a reason"} >> >> Now I delete with a PUT and a reason; >> >> ➜ curl 'localhost:5984/db1/bar?rev=1-967a00dff5e02add41819138abb3284d' >> -XPUT -d '{"reason":"because I said so","_deleted":true}' >> {"ok":true,"id":"bar","rev":"2-6e10b3cc9ea15f6a9d81aa72aaa6e098"} >> >> And it's really deleted; >> >> ➜ ~ curl localhost:5984/db1/bar >> {"error":"not_found","reason":"deleted"} >> >> And my reason is recorded; >> >> ➜ ~ curl 'localhost:5984/db1/bar?rev=2-6e10b3cc9ea15f6a9d81aa72aaa6e098' >> {"_id":"bar","_rev":"2-6e10b3cc9ea15f6a9d81aa72aaa6e098","reason":"because >> I said so","_deleted":true} >> >> B. >> >> On 17 May 2013 14:52, Jim Klo <[email protected]> wrote: >>> It's a great tip, my only complaint about it is that the deleted stub >>> doesn't get handed to the VDU function, unless that's changed in 1.3 >>> >>> - Jim >>> >>> >>> On May 17, 2013, at 12:04 AM, "Dave Cottlehuber" <[email protected]> wrote: >>> >>>> On 17 May 2013 01:32, Randall Leeds <[email protected]> wrote: >>>>> Actually, it's even easier than this. It is acceptable to put a body in >>>>> the >>>>> DELETE. You can store whatever fields you want accessible in your deletion >>>>> stubs. >>>> >>>> **WIN** best tip of the month!
