couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Newson <rnew...@apache.org>
Subject Re: list functions, error checking, and content-type
Date Mon, 25 Feb 2013 16:41:03 GMT
It's not a fix, it's a feature. 1.4 :)

On 25 February 2013 16:20, Kevin R. Coombes <kevin.r.coombes@gmail.com> 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<
>> 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
View raw message