Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Date: Mon, 6 Jun 2011 14:46:59 +0000 (UTC)
From: =?utf-8?Q?David_Z=C3=BClke_=28JIRA=29?= <jira@apache.org>
To: dev@couchdb.apache.org
Message-ID: <929529399.587.1307371619787.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Created] (COUCHDB-1188) View query option defaults
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

View query option defaults
--------------------------

                 Key: COUCHDB-1188
                 URL: https://issues.apache.org/jira/browse/COUCHDB-1188
             Project: CouchDB
          Issue Type: New Feature
          Components: JavaScript View Server
    Affects Versions: 1.0.2
            Reporter: David Z=C3=BClke
            Priority: Minor
             Fix For: 1.1.1


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

http://localhost:5984/mydb/_design/burp/_view/count-laser-beams?group_level=
=3D2

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". Fo=
r instance, views that pull in foreign documents by emitting {_id: ...} as =
a value will only produce useful results when called with "include_docs" se=
t to true.

I'd suggest a feature where inside a view definition, a new key "query_defa=
ults" 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-de=
fined options is passed as a query argument, in which case the explicitly g=
iven query argument would take precedence.

Example:

"views": {
   "talks-by-room": {
       "map": "function(doc) {\n\tif(doc.type =3D=3D 'talk' && doc.date_sta=
rt) {\n\t\temit([doc.room, doc.date_start, 0], doc.name);\n\t\tif(doc.speak=
er) {\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 r=
un with include_docs=3Dtrue, but the doc inclusion could be suppressed by r=
equesting http://localhost:5984/couchcamp/_design/burp/_view/talks-by-room?=
include_docs=3Dfalse

Alternative names for the new key are "query_options" or "query_option_defa=
ults". Whilst I prefer "query_options", I think "query_defaults" will be th=
e better choice as it underlines the nature of the functionality - namely, =
that the options defined therein may be overridden by the caller.

Someone on the dev list suggested to use _rewrite, but the idea is that the=
 defaults also apply when invoking a list function. So you'd need two rewri=
tes, one for the view if you want to call it standalone, and one for the li=
st function. And then you'd still have the issue that the behavior of the v=
iew is changed by the rewrite, which is confusing to anyone looking at the =
view code - you have to look at the rewrite as well to get the whole pictur=
e. Not good.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira