[
https://issues.apache.org/jira/browse/COUCHDB-707?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12851169#action_12851169
]
Luke Burton commented on COUCHDB-707:
-------------------------------------
Wait a second. What I'm asking for basically already exists, but I didn't know
about it. You can apply exactly the kind of filter documents I'm talking about
on the _changes feed, as discussed in the CouchDB book.
All I want to do is use exactly that against *any* view. Is that possible??
> 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.
-
You can reply to this email to add a comment to the issue online.
