incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexander Shorin <kxe...@gmail.com>
Subject Re: Are CouchDB filters limited to the _changes feed?
Date Sun, 29 Jan 2012 22:07:01 GMT
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