You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@couchdb.apache.org by Jan Lehnardt <ja...@apache.org> on 2010/09/19 14:52:34 UTC

Re: Rekindle discussion: `reduce=false` fails unpredictably

On 30 Aug 2010, at 10:01, Jason Smith wrote:

> This was discussed before here:
> 
> http://mail-archives.apache.org/mod_mbox/couchdb-user/200912.mbox/%3c04C82F94-CF83-45D9-B599-47A8DD7C0501@gmail.com%3e
> 
> This is complicating my own client code. I went out of my way to make
> views that are valuable both in map and map/reduce form. But I
> discovered that client code must never send reduce=false to map views
> even though that is a no-op.
> 
> In the cited discussion, people debated how strictly CouchDB should
> validate query parameters.
> 
> You could download the ddoc and inspect it. (But CouchApps are
> approaching 1MB with all the vendor/ libraries). A _show function
> could inform the client which views are map vs. map/reduce. Finally,
> an unused reduce function (such as _count) could be used. None of
> these seem relaxing.
> 
> I propose a minor change to validation: a simple check is made to
> determine if the extra parameter would result in a no-op. If so, no
> exception is thrown. Therefore:
> 
> map view, reduce=false -> Allowed
> map view, reduce=true -> query_parse_error
> map view, group or group_level -> no change to today's behavior
> map/reduce view -> no change to today's behavior
> 
> (It can't be known at query time whether group and group_level no-op.
> In general they do not. Therefore the client must explicitly get it
> right.)
> 
> If this is acceptable, I will submit the patch to JIRA. Thank you.

yes please :)

Cheers
Jan
--