incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Newson <robert.new...@gmail.com>
Subject Re: _changes and filters not working in harmony?
Date Sun, 06 Feb 2011 10:21:45 GMT
I guess I'm missing something here, but since your function will
return false for a deleted document, what's the surprise?

A deleted document is exactly this;

{"_id":"foo","_deleted":true}

It has no type and no attachments, it's therefore filtered out.

if you add 'if (doc._deleted) { return true; }' you'll see the delete
but, as Randall points out, you'll see all deletes. To solve that, we
might want to pass either the previous doc *or* simply add the
_deleted:true field when we delete, meaning that your filter would
work as-is.

B.

On Sun, Feb 6, 2011 at 12:36 AM, Randall Leeds <randall.leeds@gmail.com> wrote:
> 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
>>
>>
>

Mime
View raw message