I don't think there's anything wrong with what you're doing here, but I
don't know the code too well.
It sounds like what maybe we need is to pass the old document as a third
parameter or something.

On Sat, Feb 5, 2011 at 15:59, Timothy Wood <tjw@omnigroup.com> wrote:

>
> I’ve been playing with the _changes support in concert with the filter
> parameter. I’m seeing some odd results, though.
>
> In all these cases, my filter function looks like:
>
> function(doc, req) {
>  if (doc.type == "item" && doc["_attachments"]) {
>    return true;
>  }
>  return false;
> }
>
>
> 1) If I query for changes with a filter like:
>
>
> http://status-board:5984/status-board/_changes?feed=continuous&filter=app/items
>
> I’ll see my test documents (that match the filter) come back. Great. But
> then if I go and delete a document using Futon, no “_deleted”:true change
> comes back. If I leave off the filter, I do get a _deleted entry in the
> changes feed.
>
> 2) If I edit the document in Futon (by deleting its last attachment) so
> that it no longer matches the filter, I don’t get a _deleted entry. I would
> expect to get one since the change feed reported the document to me (it
> matched the filter) and then it was edited to not match the filter. For an
> observer following a filtered feed, this delete seems pretty crucial (if you
> wanted to do a filtered replication, for example).
>
> If I start a an unfiltered _changes feed and then do an insert of a
> document followed by adding an attachment, I get two lines in the _changes
> feed. But, if I use the filter, I only get one. That is, unlike the delete
> case, the filter doesn’t note the document until the document matches the
> filter. Probably a happy accident, but the mirror case (edit to not match
> the filter) should be symmetric and issue a delete change.
>
> In my particular use case, I can probably just drop the filter on the
> server side and do it in the client. Is there something wrong in my use of
> _changes with a filter? I don’t see any discussion of this in the book or on
> the mailing list, but maybe I missed it.
>
> Thanks!
>
> -tim
>
>