You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@couchdb.apache.org by Jens Alfke <je...@couchbase.com> on 2011/07/21 00:17:19 UTC
Weird: the order of 'group' and 'group_level' params is significant
I’ve spent the last half hour trying to figure out a view query that sometimes behaves and sometimes doesn’t, depending on how I specify the parameters. I finally figured out that if you put the ‘group_level’ parameter before ‘group’, the view misbehaves — the group_level is interpreted as some large number instead of what I specified. This must be a bug, right? I’ve never run into an HTTP API that cares what order URL query-string parameters occur in.
Here’s an example from a database I imported my iTunes library into (thus the kind of weird-looking data set…)
# This query works correctly:
$ curl 'http://127.0.0.1:5984/itunes/_design/tunes/_view/tracks?group=true&group_level=1&limit=10'
{"rows":[
{"key":["_radio magenta"],"value":2},
{"key":["!!!"],"value":8},
{"key":["\"Weird Al\" Yankovic"],"value":3},
{"key":["(mrk)"],"value":5},
{"key":["[Dunkelbunt]"],"value":1},
{"key":["1 Mile North"],"value":12},
{"key":["12th Floor"],"value":1},
{"key":["19.454.18.5.25.5.18"],"value":1},
{"key":["2001: A Space Odyssey"],"value":2},
{"key":["2562"],"value":1}
]}
# This one doesn’t — it’s like the group_level got changed to a large number
$ curl 'http://127.0.0.1:5984/itunes/_design/tunes/_view/tracks?group_level=1&group=true&limit=10'
{"rows":[
{"key":["_radio magenta","so far, so good ... so what ?!",4,"appearance ... not disappearance"],"value":1},
{"key":["_radio magenta","so far, so good ... so what ?!",8,"like a radio magenta"],"value":1},
{"key":["!!!","!!!",1,"The Step"],"value":1},
{"key":["!!!","!!!",2,"Hammerhead"],"value":1},
{"key":["!!!","!!!",3,"KooKooka Fuk-U"],"value":1},
{"key":["!!!","!!!",4,"Storm The Legion"],"value":1},
{"key":["!!!","!!!",5,"There's No Fucking Rules, Dude"],"value":1},
{"key":["!!!","!!!",6,"Intensify"],"value":1},
{"key":["!!!","!!!",7,"Feel Good Hit Of The Fall"],"value":1},
{"key":["!!!","Louden Up Now",8,"Me And Giuliani Down By The School Yard (A True Story)"],"value":1}
]}
# Here’s the query without any reduce:
$ curl 'http://127.0.0.1:5984/itunes/_design/tunes/_view/tracks?reduce=false&limit=10'
{"total_rows":10842,"offset":0,"rows":[
{"id":"59AD53FBBFBF17C0","key":["_radio magenta","so far, so good ... so what ?!",4,"appearance ... not disappearance"],"value":1},
{"id":"59AD53FBBFBF17C2","key":["_radio magenta","so far, so good ... so what ?!",8,"like a radio magenta"],"value":1},
{"id":"59AD53FBBFBF123A","key":["!!!","!!!",1,"The Step"],"value":1},
{"id":"59AD53FBBFBF1236","key":["!!!","!!!",2,"Hammerhead"],"value":1},
{"id":"59AD53FBBFBF1238","key":["!!!","!!!",3,"KooKooka Fuk-U"],"value":1},
{"id":"59AD53FBBFBF1239","key":["!!!","!!!",4,"Storm The Legion"],"value":1},
{"id":"59AD53FBBFBF123B","key":["!!!","!!!",5,"There's No Fucking Rules, Dude"],"value":1},
{"id":"59AD53FBBFBF1237","key":["!!!","!!!",6,"Intensify"],"value":1},
{"id":"59AD53FBBFBF1234","key":["!!!","!!!",7,"Feel Good Hit Of The Fall"],"value":1},
{"id":"59AD53FBBFBF123C","key":["!!!","Louden Up Now",8,"Me And Giuliani Down By The School Yard (A True Story)"],"value":1}
]}
Here’s the definition of the view I’m using:
"map": "function(doc){ if (doc['Artist']) emit([doc['Artist'], doc['Album'], doc['Track Number'], doc['Name']], 1); }",
"reduce": "_sum"
The version of CouchDB is 1.2.0a-eb77a97-git.
—Jens
Re: Weird: the order of 'group' and 'group_level' params is significant
Posted by Paul Davis <pa...@gmail.com>.
On Wed, Jul 20, 2011 at 5:17 PM, Jens Alfke <je...@couchbase.com> wrote:
> I’ve spent the last half hour trying to figure out a view query that sometimes behaves and sometimes doesn’t, depending on how I specify the parameters. I finally figured out that if you put the ‘group_level’ parameter before ‘group’, the view misbehaves — the group_level is interpreted as some large number instead of what I specified. This must be a bug, right? I’ve never run into an HTTP API that cares what order URL query-string parameters occur in.
>
> Here’s an example from a database I imported my iTunes library into (thus the kind of weird-looking data set…)
>
> # This query works correctly:
> $ curl 'http://127.0.0.1:5984/itunes/_design/tunes/_view/tracks?group=true&group_level=1&limit=10'
> {"rows":[
> {"key":["_radio magenta"],"value":2},
> {"key":["!!!"],"value":8},
> {"key":["\"Weird Al\" Yankovic"],"value":3},
> {"key":["(mrk)"],"value":5},
> {"key":["[Dunkelbunt]"],"value":1},
> {"key":["1 Mile North"],"value":12},
> {"key":["12th Floor"],"value":1},
> {"key":["19.454.18.5.25.5.18"],"value":1},
> {"key":["2001: A Space Odyssey"],"value":2},
> {"key":["2562"],"value":1}
> ]}
>
> # This one doesn’t — it’s like the group_level got changed to a large number
> $ curl 'http://127.0.0.1:5984/itunes/_design/tunes/_view/tracks?group_level=1&group=true&limit=10'
> {"rows":[
> {"key":["_radio magenta","so far, so good ... so what ?!",4,"appearance ... not disappearance"],"value":1},
> {"key":["_radio magenta","so far, so good ... so what ?!",8,"like a radio magenta"],"value":1},
> {"key":["!!!","!!!",1,"The Step"],"value":1},
> {"key":["!!!","!!!",2,"Hammerhead"],"value":1},
> {"key":["!!!","!!!",3,"KooKooka Fuk-U"],"value":1},
> {"key":["!!!","!!!",4,"Storm The Legion"],"value":1},
> {"key":["!!!","!!!",5,"There's No Fucking Rules, Dude"],"value":1},
> {"key":["!!!","!!!",6,"Intensify"],"value":1},
> {"key":["!!!","!!!",7,"Feel Good Hit Of The Fall"],"value":1},
> {"key":["!!!","Louden Up Now",8,"Me And Giuliani Down By The School Yard (A True Story)"],"value":1}
> ]}
>
> # Here’s the query without any reduce:
> $ curl 'http://127.0.0.1:5984/itunes/_design/tunes/_view/tracks?reduce=false&limit=10'
> {"total_rows":10842,"offset":0,"rows":[
> {"id":"59AD53FBBFBF17C0","key":["_radio magenta","so far, so good ... so what ?!",4,"appearance ... not disappearance"],"value":1},
> {"id":"59AD53FBBFBF17C2","key":["_radio magenta","so far, so good ... so what ?!",8,"like a radio magenta"],"value":1},
> {"id":"59AD53FBBFBF123A","key":["!!!","!!!",1,"The Step"],"value":1},
> {"id":"59AD53FBBFBF1236","key":["!!!","!!!",2,"Hammerhead"],"value":1},
> {"id":"59AD53FBBFBF1238","key":["!!!","!!!",3,"KooKooka Fuk-U"],"value":1},
> {"id":"59AD53FBBFBF1239","key":["!!!","!!!",4,"Storm The Legion"],"value":1},
> {"id":"59AD53FBBFBF123B","key":["!!!","!!!",5,"There's No Fucking Rules, Dude"],"value":1},
> {"id":"59AD53FBBFBF1237","key":["!!!","!!!",6,"Intensify"],"value":1},
> {"id":"59AD53FBBFBF1234","key":["!!!","!!!",7,"Feel Good Hit Of The Fall"],"value":1},
> {"id":"59AD53FBBFBF123C","key":["!!!","Louden Up Now",8,"Me And Giuliani Down By The School Yard (A True Story)"],"value":1}
> ]}
>
> Here’s the definition of the view I’m using:
> "map": "function(doc){ if (doc['Artist']) emit([doc['Artist'], doc['Album'], doc['Track Number'], doc['Name']], 1); }",
> "reduce": "_sum"
> The version of CouchDB is 1.2.0a-eb77a97-git.
>
> —Jens
The group and group_level options are the same option underneath.
Setting group=true is semantically equivalent to setting
group_level=infinity. In your case you're giving two values for the
same setting.
I'm not entirely certain what the best solution is here. The fact that
its order dependent is only a consequence of the decision to be
"relaxed" and not throw an error. I am historically the most vocal
proponent of throwing errors precisely because of emails like this.
There's behavior that can lead to non-intuitive results that's hard to
debug unless you're quite familiar with the internals.
Although, in general my preference for being strict in what's accepted
is overridden by the larger community's desire to be relaxed in what's
accepted and try and just try and make it work as best as possible.
So, in summary, yeah it's a bit funky. Values that can be specified in
multiple ways generally prefer the second specification cause we
process URL parameters left to right for the most part.
Re: Weird: the order of 'group' and 'group_level' params is significant
Posted by Dave Cottlehuber <da...@muse.net.nz>.
On 21 July 2011 10:33, Robert Newson <rn...@apache.org> wrote:
> 'group=true' is an alias for 'group_level=exact', so given that, it's
> no surprise that the order matters. You're basically setting the same
> thing to two different values, the last value wins.
>
> not a bug, just a quirk.
>
> B.
In that case would it make sense for 2.0 to deprecate group=true ?
A+
D
Re: Weird: the order of 'group' and 'group_level' params is
significant
Posted by Jens Alfke <je...@couchbase.com>.
On Jul 21, 2011, at 7:01 AM, Kevin R. Coombes wrote:
And I would therefore argue in favor of deprecation. In the long run,
it is better to teach people to use "group_level=exact" than to
repeatedly have to explain this issue to them. I think it's a bad idea
to promote behavior (using "group=true") that does not fit with user
expectations (that "group=true" is simply a binary switch that still
allows you to set group_level to whatever you want).
+1. Having two different parameters that affect the same behavior, but in different and incompatible ways, is just confusing.
I suggest:
1. Make the URL parser ignore ‘group=‘, if ‘group_level=‘ is specified too.
2. Remove ‘group=‘ from the documentation, except perhaps as an obsolete way to specify ‘group_level=exact’.
—Jens
Re: Weird: the order of 'group' and 'group_level' params is significant
Posted by "Kevin R. Coombes" <ke...@gmail.com>.
To this user, it still smells like a bug....
And I would therefore argue in favor of deprecation. In the long run,
it is better to teach people to use "group_level=exact" than to
repeatedly have to explain this issue to them. I think it's a bad idea
to promote behavior (using "group=true") that does not fit with user
expectations (that "group=true" is simply a binary switch that still
allows you to set group_level to whatever you want).
I also think making it a "400 Bad Request" is just going to confuse
users who still won't know why it's bad.
Kevin
On 7/21/2011 4:10 AM, Robert Newson wrote:
> Rather than deprecate, I'd convert it to a 400 bad request (or leave
> as is). Specifying two different values for the same parameter sounds
> unambiguously 'bad' to me. The fact that it's non obvious to the user
> that they are doing so is further motivation to improve the
> information in the response.
>
> B.
>
> On 21 July 2011 03:16, Jens Alfke<je...@couchbase.com> wrote:
>> Thanks. After Damien explained this to me, I updated the wiki page on view queries to point it out explicitly.
>>
>> --Jens
>>
>> On Jul 20, 2011, at 3:33 PM, "Robert Newson"<rn...@apache.org> wrote:
>>
>>> 'group=true' is an alias for 'group_level=exact', so given that, it's
>>> no surprise that the order matters. You're basically setting the same
>>> thing to two different values, the last value wins.
>>>
>>> not a bug, just a quirk.
Re: Weird: the order of 'group' and 'group_level' params is significant
Posted by Robert Newson <rn...@apache.org>.
Rather than deprecate, I'd convert it to a 400 bad request (or leave
as is). Specifying two different values for the same parameter sounds
unambiguously 'bad' to me. The fact that it's non obvious to the user
that they are doing so is further motivation to improve the
information in the response.
B.
On 21 July 2011 03:16, Jens Alfke <je...@couchbase.com> wrote:
> Thanks. After Damien explained this to me, I updated the wiki page on view queries to point it out explicitly.
>
> --Jens
>
> On Jul 20, 2011, at 3:33 PM, "Robert Newson" <rn...@apache.org> wrote:
>
>> 'group=true' is an alias for 'group_level=exact', so given that, it's
>> no surprise that the order matters. You're basically setting the same
>> thing to two different values, the last value wins.
>>
>> not a bug, just a quirk.
>
Re: Weird: the order of 'group' and 'group_level' params is
significant
Posted by Jens Alfke <je...@couchbase.com>.
Thanks. After Damien explained this to me, I updated the wiki page on view queries to point it out explicitly.
--Jens
On Jul 20, 2011, at 3:33 PM, "Robert Newson" <rn...@apache.org> wrote:
> 'group=true' is an alias for 'group_level=exact', so given that, it's
> no surprise that the order matters. You're basically setting the same
> thing to two different values, the last value wins.
>
> not a bug, just a quirk.
Re: Weird: the order of 'group' and 'group_level' params is significant
Posted by Robert Newson <rn...@apache.org>.
'group=true' is an alias for 'group_level=exact', so given that, it's
no surprise that the order matters. You're basically setting the same
thing to two different values, the last value wins.
not a bug, just a quirk.
B.
On 20 July 2011 23:17, Jens Alfke <je...@couchbase.com> wrote:
> I’ve spent the last half hour trying to figure out a view query that sometimes behaves and sometimes doesn’t, depending on how I specify the parameters. I finally figured out that if you put the ‘group_level’ parameter before ‘group’, the view misbehaves — the group_level is interpreted as some large number instead of what I specified. This must be a bug, right? I’ve never run into an HTTP API that cares what order URL query-string parameters occur in.
>
> Here’s an example from a database I imported my iTunes library into (thus the kind of weird-looking data set…)
>
> # This query works correctly:
> $ curl 'http://127.0.0.1:5984/itunes/_design/tunes/_view/tracks?group=true&group_level=1&limit=10'
> {"rows":[
> {"key":["_radio magenta"],"value":2},
> {"key":["!!!"],"value":8},
> {"key":["\"Weird Al\" Yankovic"],"value":3},
> {"key":["(mrk)"],"value":5},
> {"key":["[Dunkelbunt]"],"value":1},
> {"key":["1 Mile North"],"value":12},
> {"key":["12th Floor"],"value":1},
> {"key":["19.454.18.5.25.5.18"],"value":1},
> {"key":["2001: A Space Odyssey"],"value":2},
> {"key":["2562"],"value":1}
> ]}
>
> # This one doesn’t — it’s like the group_level got changed to a large number
> $ curl 'http://127.0.0.1:5984/itunes/_design/tunes/_view/tracks?group_level=1&group=true&limit=10'
> {"rows":[
> {"key":["_radio magenta","so far, so good ... so what ?!",4,"appearance ... not disappearance"],"value":1},
> {"key":["_radio magenta","so far, so good ... so what ?!",8,"like a radio magenta"],"value":1},
> {"key":["!!!","!!!",1,"The Step"],"value":1},
> {"key":["!!!","!!!",2,"Hammerhead"],"value":1},
> {"key":["!!!","!!!",3,"KooKooka Fuk-U"],"value":1},
> {"key":["!!!","!!!",4,"Storm The Legion"],"value":1},
> {"key":["!!!","!!!",5,"There's No Fucking Rules, Dude"],"value":1},
> {"key":["!!!","!!!",6,"Intensify"],"value":1},
> {"key":["!!!","!!!",7,"Feel Good Hit Of The Fall"],"value":1},
> {"key":["!!!","Louden Up Now",8,"Me And Giuliani Down By The School Yard (A True Story)"],"value":1}
> ]}
>
> # Here’s the query without any reduce:
> $ curl 'http://127.0.0.1:5984/itunes/_design/tunes/_view/tracks?reduce=false&limit=10'
> {"total_rows":10842,"offset":0,"rows":[
> {"id":"59AD53FBBFBF17C0","key":["_radio magenta","so far, so good ... so what ?!",4,"appearance ... not disappearance"],"value":1},
> {"id":"59AD53FBBFBF17C2","key":["_radio magenta","so far, so good ... so what ?!",8,"like a radio magenta"],"value":1},
> {"id":"59AD53FBBFBF123A","key":["!!!","!!!",1,"The Step"],"value":1},
> {"id":"59AD53FBBFBF1236","key":["!!!","!!!",2,"Hammerhead"],"value":1},
> {"id":"59AD53FBBFBF1238","key":["!!!","!!!",3,"KooKooka Fuk-U"],"value":1},
> {"id":"59AD53FBBFBF1239","key":["!!!","!!!",4,"Storm The Legion"],"value":1},
> {"id":"59AD53FBBFBF123B","key":["!!!","!!!",5,"There's No Fucking Rules, Dude"],"value":1},
> {"id":"59AD53FBBFBF1237","key":["!!!","!!!",6,"Intensify"],"value":1},
> {"id":"59AD53FBBFBF1234","key":["!!!","!!!",7,"Feel Good Hit Of The Fall"],"value":1},
> {"id":"59AD53FBBFBF123C","key":["!!!","Louden Up Now",8,"Me And Giuliani Down By The School Yard (A True Story)"],"value":1}
> ]}
>
> Here’s the definition of the view I’m using:
> "map": "function(doc){ if (doc['Artist']) emit([doc['Artist'], doc['Album'], doc['Track Number'], doc['Name']], 1); }",
> "reduce": "_sum"
> The version of CouchDB is 1.2.0a-eb77a97-git.
>
> —Jens