couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Anderson <jch...@apache.org>
Subject Re: No safe way to query and not ever reduce a view.
Date Thu, 10 Dec 2009 17:24:31 GMT
On Thu, Dec 10, 2009 at 7:51 AM, Paul Davis <paul.joseph.davis@gmail.com> wrote:
> On Thu, Dec 10, 2009 at 10:27 AM, Luke Sneeringer
> <lukesneeringer@gmail.com> 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

Mime
View raw message