Ok, that's what I'm discovering.

Well here's my thinking… I assuming I can use a VDU to forbid a newDoc._delete = true and validate against a oldDoc.tombstone to prevent reuse(I'm assuming that VDU get's executed regardless if the delete is initiated via DELETE/POST verbs).
Then use the update handler to manage construction of the tombstone doc.

I think for our purposes I won't have to deal with the reverse proxy (i've found that really tricky to work right anyways, i.e. inbound DELETE is trivial, but delete via POST is tricky, because you can query multi-keys using POST too… and some updates are okay in my case).   As long as the VDU will let me forbid newDoc._delete, I should be able to not care about blocking access.

Jim Klo
Senior Software Engineer
Center for Software Engineering
SRI International
t. @nsomnac

On Nov 21, 2012, at 10:46 AM, Dave Cottlehuber <dch@jsonified.com>

On 21 November 2012 16:12, Jim Klo <jim.klo@sri.com> wrote:
Okay, say I did this. In the validate_doc_update, if someone tries to delete a doc, would I be able to modify the new doc and remove the _deleted field and just empty the doc myself - basically creating my own tombstone?

- Jim

No, VDUs are a pass/throw result only, no modification allowed. You
might be able to fake this by sending your DELETEs to a custom update
handler, and some jigery pokery to prevent normal document DELETEs
being accepted within the VDU apart from via your update handler; not
sure if that's possible though so your fallback would be blocking
inbound DELETEs using a reverse proxy.