incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan Ramage <ryan.ram...@gmail.com>
Subject Re: list functions, error checking, and content-type
Date Fri, 22 Feb 2013 18:50:11 GMT
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 <
kevin.r.coombes@gmail.com> 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<kevin.r.coombes@gmail.com>>
>>  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
>>>
>>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message