From user-return-14775-apmail-couchdb-user-archive=couchdb.apache.org@couchdb.apache.org Sun Feb 06 10:37:47 2011 Return-Path: Delivered-To: apmail-couchdb-user-archive@www.apache.org Received: (qmail 80013 invoked from network); 6 Feb 2011 10:37:47 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 6 Feb 2011 10:37:47 -0000 Received: (qmail 44958 invoked by uid 500); 6 Feb 2011 10:37:45 -0000 Delivered-To: apmail-couchdb-user-archive@couchdb.apache.org Received: (qmail 44730 invoked by uid 500); 6 Feb 2011 10:37:42 -0000 Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@couchdb.apache.org Delivered-To: mailing list user@couchdb.apache.org Received: (qmail 44722 invoked by uid 99); 6 Feb 2011 10:37:41 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 06 Feb 2011 10:37:41 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=5.0 tests=FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of matt.goodall@gmail.com designates 209.85.216.52 as permitted sender) Received: from [209.85.216.52] (HELO mail-qw0-f52.google.com) (209.85.216.52) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 06 Feb 2011 10:37:36 +0000 Received: by qwi4 with SMTP id 4so2855572qwi.11 for ; Sun, 06 Feb 2011 02:37:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type:content-transfer-encoding; bh=4JKe5uwAkzYNdCt1Ju/8mYFgUXlNmLQca0c2M06JwEE=; b=UmTOcWzV+K7to56RcBcBC3R3miQRVFI7EnzlAYG3yzJo6qKMav8dOsrjDpVHVf3iCI fobT6qXk8GZ2nmjLJnkOnjHpGT0WqXISt+HwFoX0l2ZmlcQdy7yJF2WKUtHUwUBGWLWj /imMV3gDmTWBvDSEwP3R5ipXe1/AlgmpO5Nhk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=qHO6Bthy+sdILB4AndhfebfjZ0G3qiijM5eKJGjCKBCjjc/R8G6BbCVkDYjBZTkfev kxlnyhXNKrJXBYRTxKYhcweFVd8qzX6IIY7SsHTVaf6yGokjt0nPZhjY5aFDhX9OM42p TMSJFstZz1o3R2F5NA7sRm4yOqx5D3pGKWAGc= MIME-Version: 1.0 Received: by 10.229.97.134 with SMTP id l6mr4585825qcn.253.1296988635260; Sun, 06 Feb 2011 02:37:15 -0800 (PST) Received: by 10.229.249.76 with HTTP; Sun, 6 Feb 2011 02:37:15 -0800 (PST) In-Reply-To: References: Date: Sun, 6 Feb 2011 10:37:15 +0000 Message-ID: Subject: Re: _changes and filters not working in harmony? From: Matt Goodall To: user@couchdb.apache.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 5 February 2011 23:59, Timothy Wood wrote: > > I=E2=80=99ve been playing with the _changes support in concert with the f= ilter parameter. I=E2=80=99m seeing some odd results, though. > > In all these cases, my filter function looks like: > > function(doc, req) { > =C2=A0if (doc.type =3D=3D "item" && doc["_attachments"]) { > =C2=A0 =C2=A0return true; > =C2=A0} > =C2=A0return false; > } > > > 1) If I query for changes with a filter like: > > =C2=A0 =C2=A0 =C2=A0 =C2=A0http://status-board:5984/status-board/_changes= ?feed=3Dcontinuous&filter=3Dapp/items > > I=E2=80=99ll see my test documents (that match the filter) come back. Gre= at. But then if I go and delete a document using Futon, no =E2=80=9C_delete= d=E2=80=9D:true change comes back. If I leave off the filter, I do get a _d= eleted entry in the changes feed. Unfortunately, a deleted document does not retain existing attributes. A deleted doc is basically just a stub containing _id, _rev and _deleted attributes. Personally, I think it would be very useful to retain a document's existing attributes when deleted, i.e. add a _deleted attribute and leave everything else alone. > > 2) If I edit the document in Futon (by deleting its last attachment) so t= hat it no longer matches the filter, I don=E2=80=99t 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. Fo= r an observer following a filtered feed, this delete seems pretty crucial (= if you wanted to do a filtered replication, for example). I don't really understand why you would expect a _deleted row in the changes feed here. The document has not been deleted, just changed, and your filter function explicitly says it's not interested in documents with no attachments. You should remove the test for doc["_attachments"] and handle attachments vs no attachments in your change feed handled. > > If I start a an unfiltered _changes feed and then do an insert of a docum= ent 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=E2=80=99t note the document until the document matches th= e filter. Probably a happy accident, but the mirror case (edit to not match= the filter) should be symmetric and issue a delete change. It's really not a happy accident - it's exactly what your filter function tells CouchDB to do. > > In my particular use case, I can probably just drop the filter on the ser= ver side and do it in the client. Is there something wrong in my use of _ch= anges with a filter? I don=E2=80=99t see any discussion of this in the book= or on the mailing list, but maybe I missed it. You don't need to drop the filter func but you might have to compromise a little. Change it to the following: function(doc, req) { return doc._deleted || doc.type =3D=3D "item"; } You can then: * Handle attachments vs no attachments correctly * Clean up after a document gets deleted. Note that you will see *all* deleted documents and not just documents that used to have an item: "type" attribute. Admittedly, that's not ideal but, in my experience, not a massive problem either. Hope that helps. - Matt