couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Z├╝lke <>
Subject View query option defaults
Date Mon, 30 May 2011 11:51:27 GMT
Hello list,

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


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.


"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,


View raw message