[
https://issues.apache.org/jira/browse/COUCHDB-707?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12851197#action_12851197
]
Luke Burton commented on COUCHDB-707:
-------------------------------------
_changes won't work for us in this case, I don't think. We need this feature to
decide if the requester should have access to a document or not (and more fun
stuff too, but this is a big one). Say for instance you break this out into a
per-user database scenario:
"PersonA" database gets a feed from "Master". Master has a new document added.
The replication filter detects that PersonA does indeed have access to this
document, so we replicate it across to PersonA. Now someone removes PersonA's
access to that document. The replication filter looks at that change and at
that point has to turn that request into a *delete* operation, not an *update*.
Can it do that? From what I have seen, I don't think it can.
Sure this operation is expensive on the Couch side, but in our stack we have to
do it *somewhere*. Right now it's two expensive HTTP calls from the client. We
could completely gut our middle tier layer if Couch allowed us to do this. Its
only job at that point would be to attach information from our authorization
system on any "view filter" requests coming through.
Another problem is the massive duplication this approach would entail. We have
tens of thousands of documents and hundreds of people. Basically we would be
multiplying our database size by close to the number of users, all to filter
out a few secure documents. I'd rather pay a small CPU cost to keep things
simple. And AFAIK Couch doesn't yet bring up replication on restart, so I'd
also have to write some script to trigger a few hundred replications ...
maintenance hassle ...
> 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.
