If there were a way to enable this sort of feature via a flag, like local_seq that would be a good compromise IMO. :)  I don't know what the ramifications of this would be on performance, but would be a 'nice to have'.

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

On May 17, 2013, at 8:39 AM, Robert Newson <rnewson@apache.org>
 wrote:

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 <jim.klo@sri.com> 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" <rnewson@apache.org> 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 <jim.klo@sri.com> 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" <dch@jsonified.com> wrote:

On 17 May 2013 01:32, Randall Leeds <randall.leeds@gmail.com> 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!