Hm, I dislike that, but you could raise it as a topic in the dev@ mailing list. I think couchdb's core behavior should be predictable, it shouldn't change based on where you are. Consider that this would break eventual consistency (a validate_doc_update would have a different result based on that flags value).
B. On 17 May 2013 17:29, Jim Klo <[email protected]> wrote: > 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! > >
