incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Davis <paul.joseph.da...@gmail.com>
Subject Re: Weird: the order of 'group' and 'group_level' params is significant
Date Wed, 20 Jul 2011 22:33:01 GMT
On Wed, Jul 20, 2011 at 5:17 PM, Jens Alfke <jens@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.

Mime
View raw message