incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Klo <>
Subject Re: Are CouchDB filters limited to the _changes feed?
Date Sun, 29 Jan 2012 22:20:58 GMT
I can see filters applied to views and replication, since lists are essentially a filter with
formatting. I understood the proposal being the other way around using view (or map) for replication

Chained filtering would be nice - albeit, I'm not sure how efficient it would be since the
worst possible case you'd be O = n*m where n is the number of filters, m is the number of

Jim Klo
Senior Software Engineer
Center for Software Engineering
SRI International

On Jan 29, 2012, at 2:07 PM, Alexander Shorin wrote:

> IMHO, that's nice idea to apply filter or set of filters to view result.
> Some examples:
> Your database contains set of articles. Your view looks like:
> function(doc){
>  if (doc.type == 'article')
>    emit(doc.title, doc)
> }
> Fine. Now you'd like to get articles that have been created by user
> group managers? No problem, just create new view with user group
> check. Wanted to emit only those who had any comments? Get another
> one. And so on, and so on. Instead of this, you may just apply set of
> filters to view result and customize output it on fly! Like this:
> /_design/articles/_view/by_title?filters=[only_managers,has_comments,has_positive_rating]
> If you're ready to pay some performance hit for this, you've got 4
> views by cost(disk-space) of single one.
> Now let's take a look a little closer...
> Common filter function takes two arguments: doc to filter and request
> information:
> function(doc, req){
>  ...
> }
> and should return boolean to mark has doc passed or not.
> View internals could surely say what document could be processed in
> map mode. If you apply reduce function this information is lost for
> oblivious reasons. So this idea could live for only map views if we
> operating with documents.  This means, that this filters should be
> applied after map function execution and before reduce one. Since the
> fact that reduced view result calculated for each request and doesn't
> stored in view index file(am I wrong?) this feature is quite possible
> to be real, theoretically(:
> P.S. There is nothing about replications due to views are already
> could be used as filters. Creating mix of views/filters I've found a
> little crazy.
> --
> ,,,^..^,,,
> On Mon, Jan 30, 2012 at 1:39 AM, Jim Klo <> wrote:
>> I could see it as a bad idea in that views usually have a different collation from
the changes feed. Views also can emit more than 1 key/value per doc, which I'm not sure how
that works with filters.  I suppose it's possible, but you'd still have to follow the changes
sequence, but when applying the map function, you replicate only the id emitted once.
>> - Jim
>> Sent from my iPad
>> On Jan 29, 2012, at 11:35 AM, Dave Cottlehuber <> wrote:
>>> On 29 January 2012 18:13, Benoit Chesneau <> wrote:
>>>> On Sun, Jan 29, 2012 at 8:54 AM, Daniel Gonzalez <>
>>>>> - Am I doing something wrong in the curl calls?
>>>>> - Is it at all possible to use views together with filters, or are
>>>>> filters limited to the _changes feed? I have seen no examples of
>>>>> filters except related to _changes
>>>> filters are only expected for _changes.
>>>> - benoƮt
>>> Although it might be interesting to factor out filters (in changes and
>>> replication) and to manage them the same way as views, including being
>>> able to use views as replication targets, and avoid needing to
>>> reprocess the filter each time.
>>> I'm sure that when I think about this after my wine, I'll come up with
>>> some good reasons why thats not a great idea.
>>> A+
>>> Dave

View raw message