It's not a fix, it's a feature. 1.4 :)
On 25 February 2013 16:20, Kevin R. Coombes <[email protected]> wrote: > 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 >>>>> >
