[
https://issues.apache.org/jira/browse/COUCHDB-1188?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jan Lehnardt updated COUCHDB-1188:
----------------------------------
Fix Version/s: (was: 1.3)
> 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
> Labels: query, view
>
> 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.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
