Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Received-SPF: pass (athena.apache.org: domain of adam.kocoloski@gmail.com
 designates 209.85.216.173 as permitted sender)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Apple Message framework v1084)
Subject: Re: View query option defaults
From: Adam Kocoloski <kocolosk@apache.org>
In-Reply-To: <A987B8D2-A4CC-478C-9CCF-7CBC0571A26A@bitextender.com>
Date: Wed, 1 Jun 2011 15:25:19 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <62A955F7-32DF-4DD8-899A-AD93DB2DBC67@apache.org>
References: <A987B8D2-A4CC-478C-9CCF-7CBC0571A26A@bitextender.com>
To: dev@couchdb.apache.org

On May 30, 2011, at 7:51 AM, David Z=FClke wrote:

> Hello list,
>=20
> Currently, it's necessary to have intimate-ish knowledge of the inner =
workings of a view when calling it, e.g.:
>=20
> =
http://localhost:5984/mydb/_design/burp/_view/count-laser-beams?group_leve=
l=3D2
>=20
> If the group level was different, the results returned by the view =
might be useless.
>=20
> 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.
>=20
> 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.
>=20
> Example:
>=20
> "views": {
>    "talks-by-room": {
>        "map": "function(doc) {\n\tif(doc.type =3D=3D '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
>        }
>    }
> }
>=20
> http://localhost:5984/couchcamp/_design/burp/_view/talks-by-room would =
be run with include_docs=3Dtrue, but the doc inclusion could be =
suppressed by requesting =
http://localhost:5984/couchcamp/_design/burp/_view/talks-by-room?include_d=
ocs=3Dfalse
>=20
> 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.
>=20
> I'd attempt a patch, but I probably lack the necessary Erlang-fu. Jan =
encouraged me to propose the feature here anyway :)
>=20
> Have a nice week,
>=20
> 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=