incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Klo <jim....@sri.com>
Subject Re: tracking changes - how to check what was deleted?
Date Fri, 17 May 2013 15:31:52 GMT
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!
Mime
View raw message