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 19:55:02 GMT
On Thu, Dec 10, 2009 at 11:43 AM, Luke Sneeringer
<lukesneeringer@gmail.com> wrote:
> On Thu, Dec 10, 2009 at 9:51 AM, Paul Davis <paul.joseph.davis@gmail.com> wrote:
>> 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.
> In this case I'm trying to write an abstraction layer around the accessing of the view
and the return of the results, so I'm not writing those pieces over and over.
>
> I guess there's a difference in my thinking versus that of the CouchDB implementors (which
is fine). I'm trying to write one method that always gives me back the keys and values of
the view, and another method that always gives me back the reduced value (and yet a third
that does ?group=true but that's outside the scope of this discussion).
>
> Within CouchDB, the idea is that if a reduce function exists, the user will always want
the reduced value unless they specifically state otherwise. At least for my implementation,
I'm working on a different line of thinking, which is that my goal is to quickly and specify
the type of result I want back (list or reduced value). I want the little black box that I'm
writing to ask CouchDB for that thing and give it back to me.
>
> That explanation may be clear as mud. If so, I apologize and will be happy to clarify
as needed.
>> 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
> I suppose if I was going to suggest a backwards-incompatible API change, I would suggest
that you don't get a reduced value unless you specifically ask for it. Going that route wouldn't
have the issue this mechanism does. If you specifically ask for a reduced value and there
is no reduce function, that makes no sense. In my problem case, I'm making a request that
makes logical sense, but CouchDB still doesn't like it.
>
> However, this observer would venture a guess that CouchDB is nearing sufficient stability
that a change of that magnitude and consequence would be quite disruptive. Also, I expect
most others don't agree with my assumption, or this would have been brought up before now.
:)
>

I do think making the default be reduce=false (so you have to say
reduce=true to get the reduce value) is more sensible than a bigger
change. But I don't think it's a good idea at this time.

Your library could solve this case by inspecting the design document.

Chris

> Best Regards,
> Luke



-- 
Chris Anderson
http://jchrisa.net
http://couch.io

Mime
View raw message