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