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: No safe way to query and not ever reduce a view.
Date Thu, 10 Dec 2009 15:51:58 GMT
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?"

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

Mime
View raw message