couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Newson <rnew...@apache.org>
Subject Re: tracking changes - how to check what was deleted?
Date Fri, 17 May 2013 15:39:24 GMT
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!

Mime
View raw message