couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Erik Pearson (JIRA)" <>
Subject [jira] [Commented] (COUCHDB-707) Proposal for "Filter Views"
Date Fri, 13 Sep 2013 17:39:52 GMT


Erik Pearson commented on COUCHDB-707:

I see nothing has happened here for a while!

Wondering if any movement has happened in this area?

My use case is a little different, but I could really use a dynamic filter. 

I've been happily using couchdb as the data source for a cms. The cms rendering layer does
not have direct access to querying couchdb, rather there are two types of adapter functions
-- for processing templates on the server (json, handlebars-like, lisp), and for processing
templates on on the browser (json, handlebars, javascript). The adapter functions basically
massage the couchdb output, and provide a security layer (no direct access to couchdb from
client code.)

This has worked great.

However, one function that I would love to move to couchdb is simple view filtering.
Basically, I need view results filtering that is orthogonal to the view index. For example,
I have a set of content that is ordered in alpha order by title, but I want to filter out
any expired content. Expiration is determined by comparing the current time to the expiration
time on the content. In order to use the view for filtering, I would need to sort by expiration
time, but I don't want to do that. What I do currently is get the content in the order I need
(there is already filtering going on to select type of content and category) and then apply
a filter in my adapter code. 

What I envision is simply a dynamic filter and/or map function on the "other" side of the
view, applied as the view is generated. A filter function would just return true or false,
depending on whether the row should be included in the view or not, and the map would allow
altering the view data. The function should be applicable to any view. The filter should be
able to receive query parameters as well. Filters should also be chainable.

The list function seems like the wrong approach to this. I don't want to iterate over content,
just supply one or more functions that is applied to each row, as I would expect a filter
or map to do.

So I guess I'm curious whether this proposal has ever taken off, any work done on it, how
it might fit into the current architecture of couchdb. I see that no-one is assigned to it.
I might be happy to try to work on this if no one else is ...
> Proposal for "Filter Views"
> ---------------------------
>                 Key: COUCHDB-707
>                 URL:
>             Project: CouchDB
>          Issue Type: New Feature
>          Components: JavaScript View Server
>    Affects Versions: 0.11
>            Reporter: Luke Burton
> A common operation I find myself performing repeatedly is:
> * request a view (maybe with some basic filter like "keys" or a range of keys)
> * in my client, filter this view based on some complex criteria, leaving me with a small
set of document IDs (complex as in array intersections, compound boolean operations, &
other stuff not possible in the HTTP view API)
> * go back to Couch and fetch the complete documents for these IDs.
> List Views almost get me to the point of doing this purely in Couch. I can enumerate
over a view and do some complex things with it. But I can't output entire documents, unless
I use the include_docs=true flag which murders the performance of the list view.Apparently
because the entire view is fetched with including docs, THEN passed on to the list view JS.
Typically my complex filter criteria is contained in the view itself, so there is no need
to fetch the entire document until I know I have a match.
> In summary, a Filter View would execute some arbitrary JavaScript on each view row, with
access to HTTP request parameters, and return "true" for rows that match. The output would
be a list of IDs for whom the function returned true. include_docs=true would include the
matching documents.
> Performance would certainly not be as good as fetching a raw view, but it would indisputably
be better than fetching the entire view over HTTP to a client, deserializing the JSON, doing
some stuff, then making another HTTP request, and deserializing more JSON.
> I looked at the various entry points for list views in the Couch source. Unfortunately
it will take me some time to come up to speed with the source (if I ever have the time ...),
and I hope that what I'm asking for could be a simple extension to the List Views for someone
very familiar with this area.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see:

View raw message