Hello list, 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. I'd attempt a patch, but I probably lack the necessary Erlang-fu. Jan encouraged me to propose the feature here anyway :) Have a nice week, David
smime.p7s
Description: S/MIME cryptographic signature
