Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
MIME-Version: 1.0
In-Reply-To: <F8F88329-DA27-48A2-8DBC-BAF818DE1FB8@sri.com>
References: <20130516144732.0dda4bbf@svilendobrev.com>
	<CAL+Y1nvsOsPpeH5XH-MnqCHqadYdKJ_UmiWptoOK6o-K=TgQFw@mail.gmail.com>
	<CAAL6JQh6wnLuvs8GFSO88z3CGBVw5DTVSST5wNcX33YjG-QZSQ@mail.gmail.com>
	<CAL+Y1nsiFUtvYFW5GAAOFTyLcctWO6rKcFvu-79hx6F-MdaCiw@mail.gmail.com>
	<70BAE84F-500B-4372-A81D-EABDD80B5A0B@sri.com>
	<CABvT1DGaJ-r=11=36N5MNYggZPa454DMti7fYRnTufjU44BfUA@mail.gmail.com>
	<F8F88329-DA27-48A2-8DBC-BAF818DE1FB8@sri.com>
Date: Fri, 17 May 2013 16:39:24 +0100
Message-ID: 
 <CABvT1DFKeEjNALUkw4wp-6hH-YMzFGRYzhPFuBu_a9zzuXsDEA@mail.gmail.com>
Subject: Re: tracking changes - how to check what was deleted?
From: Robert Newson <rnewson@apache.org>
To: "user@couchdb.apache.org" <user@couchdb.apache.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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 cert=
ain use cases, like a document got removed for DCMA violation - I don't wan=
t 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 s=
tub 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;
>>
>> =E2=9E=9C  ~  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;
>>
>> =E2=9E=9C  ~  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.
>>
>> =E2=9E=9C  ~  curl 'localhost:5984/db1/bar?rev=3D1-967a00dff5e02add41819=
138abb3284d'
>> -XDELETE
>> {"error":"forbidden","reason":"must have a reason"}
>>
>> Now I delete with a PUT and a reason;
>>
>> =E2=9E=9C curl 'localhost:5984/db1/bar?rev=3D1-967a00dff5e02add41819138a=
bb3284d'
>> -XPUT -d '{"reason":"because I said so","_deleted":true}'
>> {"ok":true,"id":"bar","rev":"2-6e10b3cc9ea15f6a9d81aa72aaa6e098"}
>>
>> And it's really deleted;
>>
>> =E2=9E=9C  ~  curl localhost:5984/db1/bar
>> {"error":"not_found","reason":"deleted"}
>>
>> And my reason is recorded;
>>
>> =E2=9E=9C  ~ curl 'localhost:5984/db1/bar?rev=3D2-6e10b3cc9ea15f6a9d81aa=
72aaa6e098'
>> {"_id":"bar","_rev":"2-6e10b3cc9ea15f6a9d81aa72aaa6e098","reason":"becau=
se
>> 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 d=
oesn'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> wr=
ote:
>>>
>>>> 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 del=
etion
>>>>> stubs.
>>>>
>>>> **WIN** best tip of the month!