Why not just use "_rewrite" ? Cheers, Fedor.
On Thu, Jun 2, 2011 at 2:25 AM, Adam Kocoloski <[email protected]> wrote: > On May 30, 2011, at 7:51 AM, David Zülke wrote: > > > 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 > > Hi David, this sounds like a good idea to me, and I like the name > "query_defaults". I think there's even some code in a multi-query JIRA > ticket I started that takes care of parsing JSON objects which specify query > parameters. Do you mind creating a ticket so we don't forget about it? > Best, > > Adam
