Thanks; yes, it sounds exactly like that issue.
If I read the "JIRA issues" page correctly, this problem is fixed as
of version 1.4. Since the current stable release is 1.2.1, is there
some (broad and clearly not binding...) estimate of when 1.4 might be
available and usable by mere mortals?
On 2/22/2013 11:17 AM, Robert Newson wrote:
Sounds like https://issues.apache.org/jira/browse/COUCHDB-430.
On 22 February 2013 17:12, Kevin R. Coombes<[email protected]> wrote:
Hi,
I am currently using CouchDB 1.2.0 on a Windows 7 machine. I have a database
with several different view functions, and I am trying to define a list
function that only makes sense when combined with _some_ of the views. Under
the (not unrealistic) assumption that anything that a user *can* do, sooner
or later, someone *will* do, I'd like the list function to check that the
view it is being called with actually makes sense. If not, then I want to
use the HTTP response to send an error message, with a proper error code.
My first (failed) attempt looked something like this:
function(header, request) {
var row = getRow();
if (row.hasRequiredField) {
start({"headers": "Content-Type": "text/html"});
// do what you need to do to 'send' this and all other rows
} else {
start({"code" 400, "headers": {"Content-Type": "text/html"}});
send("Helpful error message explaining the problem.");
}
This fails because the first call to "getRow" starts writing the HTTP
response and sets the Content-Type to "application/json". Thus the later
"start" calls fail to set the Content-Type or the response code.
The only alternative I can think of at this point is to peek into the
"request" argument to see if I can tell if the request is valid. But I
think the only information I can get that might be relevant is the name of
the view (by parsing the path element), and that causes difficulties with
maintaining the application over time. I must either maintain a "white
list" of known acceptable views or a "black list" of known unacceptable
views. (And, applying the user principle above to the developer/maintainer,
I know that I will forget to update this list at some point in time.)
I found a StackOverflow question about this issue from September 2011
(http://stackoverflow.com/questions/7595662/couchdb-list-api-cant-seem-to-return-plain-text),
but since the issue still exists, I assume that change either never got
requested in JIRA or never got implemented.
Is there some other way to accomplish what I want? Or do I have to give up
on sending proper error codes and just set the Content-Type globally before
calling getRow? Or should I put the issue into JIRA and hope someone fixes
it?
Thanks,
Kevin
