On Thu, Dec 10, 2009 at 7:51 AM, Paul Davis <[email protected]> wrote: > On Thu, Dec 10, 2009 at 10:27 AM, Luke Sneeringer > <[email protected]> wrote: >> Greetings, >> So I'm in a situation here, and perhaps I'm missing something obvious. >> >> I have four views. They work fine. Two of them have reduce functions, and >> two of them don't. On views with a reduce function, CouchDB sends reduced >> replies unless you specifically tell it not to. Anyway, in this particular >> instance, I want to query a view that may or may not have a reduce function, >> but I want the non-reduced results. >> >> This seems simple enough...just add ?reduce=false. However, if you send >> ?reduce=false to a map-only view, you get an error from CouchDB. I also can >> find no way to ask if a view is a map-view or a map-reduce-view. In other >> words, if I have a view that may or may not have a reduce function, the only >> way I can see to get non-reduced results is to send a request with >> ?reduce=false, catch the exception that's raised if it was a map-only view, >> and send the query again without ?reduce=false. >> > > I've never considered the scenario where the view was being accessed > without knowledge of what view it was. Which seems odd, but if its > popping up on the ML, then there's probably quite a few other people > trying it as well. > >> This feels quite clunky to me and not at all relaxing. I understand the >> strict error checking, but I suppose it seems there should either be a >> salient way to see which request form I should use, or there should be a >> request form that works in both cases? If I don't want reduced results, >> after all, it shouldn't matter if I have a reduce function. > > Chris Anderson yelled at me about that as well. When I was writing > that parsing I was attempting to fix a very common problem where > people were trying to use a query parameter and then failing to figure > out why CouchDB wasn't working as expected. I don't remember the exact > parameter, but it was the equivalent of "reduce=false" with no reduce > function, and then the ML and IRC got filled with questions of > "There's no difference between reduce=false and not specifying it! > What's up with that?"
I think we should just stop validating the query parameters so strictly. This would be a simple first patch for someone interested. > > So after awhile I fixed it and now the URL processing tries to detect > as many errors as possible and complain loudly. > >> Which brings me to the mailing list. Am I missing something? I looked in the >> manual, and found nothing. Is this in CouchDB? If so, how do I do it? >> > > Nothing yet. Though as part of the ensuing discussion on whether this > exact scenario should be an error or not I made the suggestion that > maybe our views should use two URL handlers. Something like: > > http://127.0.0.1:5984/db_name/_design/foo/_map/bar > http://127.0.0.1:5984/db_name/_design/foo/_reduce/bar > > But I got yelled at for suggesting API changes. > > HTH, > Paul Davis > -- Chris Anderson http://jchrisa.net http://couch.io
