This was discussed before here: http://mail-archives.apache.org/mod_mbox/couchdb-user/200912.mbox/%[email protected]%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. -- Jason Smith Couchio Hosting
