[
https://issues.apache.org/jira/browse/COUCHDB-707?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13766699#comment-13766699
]
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: https://issues.apache.org/jira/browse/COUCHDB-707
> 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: http://www.atlassian.com/software/jira
