tracking changes - how to check what was deleted?

[svilen]

g'day
so i have multiple (3) kinds of documents (say with fields .type=..) in
same database. And i listen to changes feed, and according to type,
show the different kinds of docs in 3 different windows.

if some doc was deleted, how can i guess what .type it had ?
changes return only _id and _rev of the new deleted stub..
is looking up the doc.id in those 3 caches the only option?

ciao
svilen

[Dave Cottlehuber]

Hey Svilen,

Some things:

Changes only returns the "last known good" change (~handwavey~) if
that makes sense - e.g. if doc a -> a' -> a'' -> a''' are processed in
between you checking changes, you will not receive a', a'' at all.

Document deletion inside couch is simply taking doc._id,_rev only and
storing a new doc._id, doc._deleted, and _rev + 1. There is nothing
stopping you re-implementing DELETE yourself (e.g. update handler
server side, or client side as you like), and storing doc._id _rev AND
_type as well.

Alternatively, use a byte of the id to store the type if you can achieve that.

That should see you right.

A+
Dave

[svilen]

thanks Dave.
i'll stick with client-cache-checks, because apart of deleting,
type-change also can happen (in principle) - and that's deleting from
one cache insert in another.

svilen

[Randall Leeds]

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.

[Dave Cottlehuber]

On 17 May 2013 01:32, Randall Leeds <randal...@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!

[Jim Klo]

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

[Robert Newson]

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.

[Jim Klo]

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

[Robert Newson]

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.

[Jim Klo]

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 <rne...@apache.org>

[Robert Newson]

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.