couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adam Kocoloski <>
Subject Re: View query option defaults
Date Wed, 01 Jun 2011 19:25:19 GMT
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.date_start, 0],;\n\t\tif(doc.speaker) {\n\t\t\temit([, 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,

View raw message