Hi Ryan,
I think that is the same reference that Robert Newson supplied, and the
JIRA page notes the "fix version" as 1.4 -- which is why I asked if
there was some timeline for the release of 1.4. It would certainly be
nice if the fix could be included in 1.3....
Thanks,
Kevin
On 2/22/2013 12:50 PM, Ryan Ramage wrote:
Kevin, I believe this was fixed as a part of :
https://issues.apache.org/jira/browse/COUCHDB-430
and I think may come out in a soon 1.3 release.
On Fri, Feb 22, 2013 at 11:45 AM, Kevin R. Coombes<
[email protected]> wrote:
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<https://issues.apache.org/jira/browse/COUCHDB-430>
.
On 22 February 2013 17:12, Kevin R.
Coombes<kevin.r.coombes@gmail.**com<[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<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
