incubator-couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Zülke <david.zue...@bitextender.com>
Subject Re: View query option defaults
Date Mon, 06 Jun 2011 14:35:48 GMT
The idea is that the defaults also apply when invoking a list function. So you need two rewrites,
one for the view if you want to call it standalone, and one for the list function. And then
you still have the issue that the behavior of the view 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 picture. Not good.

David


On 01.06.2011, at 21:28, Fedor Indutny wrote:

> 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
View raw message