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-47a8dd7c0...@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 --