couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Klo <jim....@sri.com>
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
filtering.

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
docs.

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 <jim.klo@sri.com> 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 <dave@muse.net.nz> wrote:
>> 
>>> On 29 January 2012 18:13, Benoit Chesneau <bchesneau@gmail.com> wrote:
>>>> On Sun, Jan 29, 2012 at 8:54 AM, Daniel Gonzalez <gonvaled@gonvaled.com>
wrote:
>>>> 
>>>>> 
>>>>> - 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


Mime
View raw message