On Thu, Dec 10, 2009 at 11:43 AM, Luke Sneeringer <[email protected]> wrote: > On Thu, Dec 10, 2009 at 9:51 AM, Paul Davis <[email protected]> > 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
