View query option defaults
--------------------------

                 Key: COUCHDB-1188
                 URL: https://issues.apache.org/jira/browse/COUCHDB-1188
             Project: CouchDB
          Issue Type: New Feature
          Components: JavaScript View Server
    Affects Versions: 1.0.2
            Reporter: David Zülke
            Priority: Minor
             Fix For: 1.1.1


Currently, it's necessary to have intimate-ish knowledge of the inner workings 
of a view when calling it, e.g.:

http://localhost:5984/mydb/_design/burp/_view/count-laser-beams?group_level=2

If the group level was different, the results returned by the view might be 
useless.

Other good examples are "include_docs", "inclusive_end" or "descending". For 
instance, views that pull in foreign documents by emitting {_id: ...} as a 
value will only produce useful results when called with "include_docs" set to 
true.

I'd suggest a feature where inside a view definition, a new key 
"query_defaults" alongside "map" or "reduce" contains a hash map of query 
option keys and values that will be used when calling the view unless one of 
the pre-defined options is passed as a query argument, in which case the 
explicitly given query argument would take precedence.

Example:

"views": {
   "talks-by-room": {
       "map": "function(doc) {\n\tif(doc.type == 'talk' && doc.date_start) 
{\n\t\temit([doc.room, doc.date_start, 0], doc.name);\n\t\tif(doc.speaker) 
{\n\t\t\temit([doc.room, doc.date_start, 1], {_id: 
doc.speaker});\n\t\t}\n\t}\n};",
       "query_defaults": {
           "include_docs": true
       }
   }
}

http://localhost:5984/couchcamp/_design/burp/_view/talks-by-room would be run 
with include_docs=true, but the doc inclusion could be suppressed by requesting 
http://localhost:5984/couchcamp/_design/burp/_view/talks-by-room?include_docs=false

Alternative names for the new key are "query_options" or 
"query_option_defaults". Whilst I prefer "query_options", I think 
"query_defaults" will be the better choice as it underlines the nature of the 
functionality - namely, that the options defined therein may be overridden by 
the caller.

Someone on the dev list suggested to use _rewrite, but the idea is that the 
defaults also apply when invoking a list function. So you'd need two rewrites, 
one for the view if you want to call it standalone, and one for the list 
function. And then you'd still have the issue that the behavior of the view is 
changed by the rewrite, which is confusing to anyone looking at the view code - 
you have to look at the rewrite as well to get the whole picture. Not good.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

Reply via email to