[
https://issues.apache.org/jira/browse/COUCHDB-707?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12849885#action_12849885
]
Luke Burton commented on COUCHDB-707:
-------------------------------------
Hah, I picked a bad example. Forget attachments and images. In my case, I
actually have rather large hashes stored in documents. I chose images thinking
it would better illustrate the point of working with unwieldy documents. Sorry
for the confusion!
So in my case I don't have any affordances for using attachments, and I can't
create a view that emits the values that I want along with the lookup keys
because what I need is the *entire* document at the end (it populates records
in a SproutCore frontend).
As to what is "natural" with Couch: this is a database that can host its own
apps! I don't think I'm crossing any natural couch boundaries here :) Really
this is just a small extension to the idea of list views. In fact you could use
the list view entirely for this if we just added one JS call that effectively
did: "emit these complete document IDs." But I think it's different enough that
it might merit its own place.
> 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.
