couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benoit Chesneau <>
Subject Re: filter changes for some docids
Date Mon, 18 Oct 2010 10:38:52 GMT
On Mon, Oct 18, 2010 at 12:21 PM, Filipe David Manana
<> wrote:
> 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 about them
separately, I think we can come up with a cleaner, more future-proof design. I'd like to avoid
special casing for situations we think are common but turn out not to be.
>> 1. Built-in filters. Much like built in reduce functions, the _doc_Ids filter could
be built-in. This would allow us to add more built-in filter functions 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 practical limits
on the URL length so we can't send a large number of URL parameters. 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 same 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)

having a parameter for that isn't really RESTful. We already have the
POST meaning. Why do we need another param in url ? I've tjinking to
the filter args before code that and rejected for abive reason.

- benoit

View raw message