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 <[email protected]> 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 <[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!
smime.p7s
Description: S/MIME cryptographic signature
