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 <[email protected]> wrote: > On 21 November 2012 16:12, Jim Klo <[email protected]> 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. > > A+ > Dave
smime.p7s
Description: S/MIME cryptographic signature
