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 16:29:05 GMT
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!


Mime
View raw message