couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Lehnardt <>
Subject Re: filter changes for some docids
Date Mon, 18 Oct 2010 19:37:32 GMT

On 18 Oct 2010, at 20:36, Benoit Chesneau wrote:

> On Mon, Oct 18, 2010 at 2:02 PM, Jan Lehnardt <> wrote:
>> I'm thinking: GET /db/_changes?filter=_doc_ids
>> Where _doc_ids references a built in Erlang function that does filtering
>> by doc id. Much like _sum or _count for reduce.
>> How does your scenario differ from this? Maybe I'm just unclear on it.
> That's working in my case. Though if for doc_ids we posts i'm not sure
> passing a param is needed in this case since we already define the
> request with a POST and a json body containing a doc_ids member. ALso
> if we want to mix doc_ids + a filter it would be better to handle the
> POST + different params to the filter query argument, I think. In
> other cases that is perfect . I could allows to create for exaample a
> builtin function to get all changed design docs in a db for ex...

I agree for your scenario using the explicit filter *and* a defined JSON
key in the POST body is effectively duplication, but I think my approach
is a bit more general and allows for future scenarios.

I think specifying a built in filter function should work like specifying
a regular filter function, except there's an underscore, as per CouchDB

I also like the idea of POSTing options to a filter function, but that
should be possible for both custom and built in filter functions.

That's why I think we should use a combination of both mechanisms to 
create a solution for your problem while being open for future uses of 
the same API.

(Awful lot of starting sentences with "I", so yeah, this is highly
subjective. :)

Either way though, I think we should get this sorted before shipping
1.1.0 or migrating it to a feature branch so we can work on it and
get it right for 1.2.0.

(I talked to Benoit on IRC a bit and he agreed to tackle the changes
 I proposed. I'm happy to chip in, if needed.)


View raw message