From dev-return-12583-apmail-couchdb-dev-archive=couchdb.apache.org@couchdb.apache.org Mon Oct 18 10:22:17 2010 Return-Path: Delivered-To: apmail-couchdb-dev-archive@www.apache.org Received: (qmail 73982 invoked from network); 18 Oct 2010 10:22:16 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 18 Oct 2010 10:22:16 -0000 Received: (qmail 82810 invoked by uid 500); 18 Oct 2010 10:22:16 -0000 Delivered-To: apmail-couchdb-dev-archive@couchdb.apache.org Received: (qmail 82360 invoked by uid 500); 18 Oct 2010 10:22:13 -0000 Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@couchdb.apache.org Delivered-To: mailing list dev@couchdb.apache.org Received: (qmail 82352 invoked by uid 99); 18 Oct 2010 10:22:12 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 18 Oct 2010 10:22:12 +0000 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests=FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of fdmanana@gmail.com designates 209.85.213.180 as permitted sender) Received: from [209.85.213.180] (HELO mail-yx0-f180.google.com) (209.85.213.180) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 18 Oct 2010 10:22:07 +0000 Received: by yxh35 with SMTP id 35so337576yxh.11 for ; Mon, 18 Oct 2010 03:21:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:content-type:content-transfer-encoding; bh=yIV+A1VHFkdJpBnneiQOvM0hcFrbVmK44G1ppqaxp5Q=; b=oXc1Yv6cbX7g8cak5kCUUtIDkX0qF8m11wpR44Qd84k40unq4UugApj8n0M8JDn7UA tTovLH+yvzFsx38MSP+iI6E+8GPWrhVpf2yMIY4vGwY0DihFREAXDlVhp2szvzLqFLfu XG/RjsAH79SVJlh6LZVzxa7KX2lYfqlfb6Ksc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; b=BYpH0Y0L8JpgE2Dn2N8dEjBGIIbqIjnptpnFIxdSGOp/q20QqiRkPFZJTh2HK4v8OY VOKWLk3X0S83IewF8sRpPovZhH5VtMcdyeJUCMmuB1+M1p62JawzEZK1lSFqtJd6YZi5 N8aTzF1p9YK9DGWHsw8t+74A/qhkiuq/IzBOY= MIME-Version: 1.0 Received: by 10.101.206.19 with SMTP id i19mr2641001anq.99.1287397306360; Mon, 18 Oct 2010 03:21:46 -0700 (PDT) Sender: fdmanana@gmail.com Received: by 10.101.66.19 with HTTP; Mon, 18 Oct 2010 03:21:46 -0700 (PDT) In-Reply-To: <42DDD352-BD80-4900-9EFA-24956668B63B@apache.org> References: <42DDD352-BD80-4900-9EFA-24956668B63B@apache.org> Date: Mon, 18 Oct 2010 11:21:46 +0100 X-Google-Sender-Auth: iz8xVmQoqjR7TsbGQFHbuHQh74g Message-ID: Subject: Re: filter changes for some docids From: Filipe David Manana To: dev@couchdb.apache.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sun, Oct 17, 2010 at 6:20 PM, Jan Lehnardt wrote: > Hi Benoit, all, > > I'm not too happy with how this turned out. > > There's multiple things this patch is trying to solve and by thinking abo= ut them separately, I think we can come up with a cleaner, more future-proo= f design. I'd like to avoid special casing for situations we think are comm= on but turn out not to be. > > 1. Built-in filters. Much like built in reduce functions, the _doc_Ids fi= lter could be built-in. This would allow us to add more built-in filter fun= ctions in the future when we discover patterns there. Exactly. Like we have the "special " reduce functions "_sum" and "_count" for views for e.g. > > 2. POST-ing arguments to _changes. This is needed because there are pract= ical limits on the URL length so we can't send a large number of URL parame= ters. This is the same reason we have POST to views. > > Together, 1. & 2. can solve what you need and they also help us keep the = improvements Filipe said could be roll into the replicator while at the sam= e time we don't code ourselves into a corner for future additions. Instead of a doc_ids parameter to changes, I was thinking that to achieve the same goal, we could still use the "filter" parameter that would have a different value for very common cases, starting with an "_" just like for the special reduce cases. (the list of doc IDs would then be a regular parameter to the builtin Erlang filter function) > > What do you think? Totally +1 > > Cheers > Jan > -- > > > On 13 Oct 2010, at 17:24, Benoit Chesneau wrote: > >> Hi all, >> >> For a project I have to know each time a design doc change and for now >> I have to create a filter function for each databases created to do >> that. I think getting changes on specific docids is a common behavior >> (see replication for example) so I thought to add the possibility to >> filters changes on docids if a list of documents is passed in the >> request. >> >> ex: >> >> POST /db/_changes >> {"docids": ["id1", ..]} >> >> >> Here is the patch that allows that feature : >> http://github.com/benoitc/couchdb/commit/fd7829b6b3093ab324a2b5c496600cc= 6335480b8 >> >> What do you think about it ? >> >> - benoit > --=20 Filipe David Manana, fdmanana@gmail.com, fdmanana@apache.org "Reasonable men adapt themselves to the world. =C2=A0Unreasonable men adapt the world to themselves. =C2=A0That's why all progress depends on unreasonable men."