couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Fedor Indutny <fe...@indutny.com>
Subject Re: View query option defaults
Date Wed, 01 Jun 2011 19:28:04 GMT
Why not just use "_rewrite" ?

Cheers,
Fedor.



On Thu, Jun 2, 2011 at 2:25 AM, Adam Kocoloski <kocolosk@apache.org> 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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message