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. :)

Best Regards,
Luke

Reply via email to