couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Smith <...@couch.io>
Subject Rekindle discussion: `reduce=false` fails unpredictably
Date Mon, 30 Aug 2010 08:01:25 GMT
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.

-- 
Jason Smith
Couchio Hosting

Mime
View raw message