You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@couchdb.apache.org by "Kevin R. Coombes" <ke...@gmail.com> on 2013/02/22 18:12:48 UTC
list functions, error checking, and content-type
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
Re: list functions, error checking, and content-type
Posted by Robert Newson <rn...@apache.org>.
It's not a fix, it's a feature. 1.4 :)
On 25 February 2013 16:20, Kevin R. Coombes <ke...@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<ke...@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
>>>>>
>
Re: list functions, error checking, and content-type
Posted by "Kevin R. Coombes" <ke...@gmail.com>.
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<ke...@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
>>>>
Re: list functions, error checking, and content-type
Posted by Ryan Ramage <ry...@gmail.com>.
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<ke...@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
>>>
>>
Re: list functions, error checking, and content-type
Posted by Robert Newson <rn...@apache.org>.
The 1.3.0 release process has begun, so it'll be next after that.
On 22 February 2013 18:45, Kevin R. Coombes <ke...@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.
>>
>> On 22 February 2013 17:12, Kevin R. Coombes<ke...@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),
>>> 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
Re: list functions, error checking, and content-type
Posted by "Kevin R. Coombes" <ke...@gmail.com>.
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<ke...@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),
>> 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
Re: list functions, error checking, and content-type
Posted by Robert Newson <rn...@apache.org>.
Sounds like https://issues.apache.org/jira/browse/COUCHDB-430.
On 22 February 2013 17:12, Kevin R. Coombes <ke...@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),
> 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