If doing a query that returns no results ( Insert etc ) db_cassa_raw_query would cause these ERRORS to be logged
0(22283) ERROR: db_cassandra [dbcassa_base.cpp:739]: db_cassa_raw_query(): The resultype rows was not set, no point trying to parse result. 0(22283) ERROR: avpops [avpops_db.c:333]: db_query_avp(): cannot do the query
db_cassa_raw_query would also return -1 as a failure code which caused avpops_db to log the query failure.
my patch changes the db_cassa_raw_query log message to debug level, and returns success from the function.
I had a quick look to see if there was an elegant way to determine if we should expect results, so we can vary the response code based on query type, but I was unable to find anything other than doing string comparisons on the query, so I opted to not bother with this as it would be erroneous.
Please find attached patch.
What would be the situation when the query is like SELECT but there is no result. Is the behaviour as expected with the new patch?
Anyone here using cassandra having comments? From my point of view is no problem to push the patch, but I am not using cassandra, so cannot do a proper review.
Cheers, Daniel
On 12/03/14 08:53, jay binks wrote:
If doing a query that returns no results ( Insert etc ) db_cassa_raw_query would cause these ERRORS to be logged
0(22283) ERROR: db_cassandra [dbcassa_base.cpp:739]: db_cassa_raw_query(): The resultype rows was not set, no point trying to parse result. 0(22283) ERROR: avpops [avpops_db.c:333]: db_query_avp(): cannot do the query
db_cassa_raw_query would also return -1 as a failure code which caused avpops_db to log the query failure.
my patch changes the db_cassa_raw_query log message to debug level, and returns success from the function.
I had a quick look to see if there was an elegant way to determine if we should expect results, so we can vary the response code based on query type, but I was unable to find anything other than doing string comparisons on the query, so I opted to not bother with this as it would be erroneous.
Please find attached patch.
-- Sincerely
Jay
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
In my test case I was doing an INSERT query... yet db_cassandra would complain there was no result... ( both the log message and return code )
This is the reason I provided the patch.
after a little more testing I have found that I get this log message :
0(23827) ERROR: <core> [db_res.c:130]: db_free_result(): invalid parameter
So far in my testing everything has performed flawlessly, just with a few less log lines :)
in essence this patch simply makes db_cassandra act the same when there is no result set as it does when there are now rows. ( previously it would act like no result set was a big deal )
Jay
On 12 March 2014 18:49, Daniel-Constantin Mierla miconda@gmail.com wrote:
What would be the situation when the query is like SELECT but there is no result. Is the behaviour as expected with the new patch?
Anyone here using cassandra having comments? From my point of view is no problem to push the patch, but I am not using cassandra, so cannot do a proper review.
Cheers, Daniel
On 12/03/14 08:53, jay binks wrote:
If doing a query that returns no results ( Insert etc ) db_cassa_raw_query would cause these ERRORS to be logged
0(22283) ERROR: db_cassandra [dbcassa_base.cpp:739]: db_cassa_raw_query(): The resultype rows was not set, no point trying to parse result. 0(22283) ERROR: avpops [avpops_db.c:333]: db_query_avp(): cannot do the query
db_cassa_raw_query would also return -1 as a failure code which caused avpops_db to log the query failure.
my patch changes the db_cassa_raw_query log message to debug level, and returns success from the function.
I had a quick look to see if there was an elegant way to determine if we should expect results, so we can vary the response code based on query type, but I was unable to find anything other than doing string comparisons on the query, so I opted to not bother with this as it would be erroneous.
Please find attached patch.
-- Sincerely
Jay
sr-dev mailing listsr-dev@lists.sip-router.orghttp://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
-- Daniel-Constantin Mierla - http://www.asipto.comhttp://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Kamailio World Conference - April 2-4, 2014, Berlin, Germanyhttp://www.kamailioworld.com
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
On 12/03/14 10:16, jay binks wrote:
In my test case I was doing an INSERT query... yet db_cassandra would complain there was no result... ( both the log message and return code )
In understand that and you are right here -- even select can have no result (but maybe is setting some other fields there). What I want to clarify is that in case of a query error (e.g., wrong statement or something happened with the connection), is it detected? Not to behave like it was all ok.
Cheers, Daniel
This is the reason I provided the patch.
after a little more testing I have found that I get this log message :
0(23827) ERROR: <core> [db_res.c:130]: db_free_result(): invalid parameter
So far in my testing everything has performed flawlessly, just with a few less log lines :)
in essence this patch simply makes db_cassandra act the same when there is no result set as it does when there are now rows. ( previously it would act like no result set was a big deal )
Jay
On 12 March 2014 18:49, Daniel-Constantin Mierla <miconda@gmail.com mailto:miconda@gmail.com> wrote:
What would be the situation when the query is like SELECT but there is no result. Is the behaviour as expected with the new patch? Anyone here using cassandra having comments? From my point of view is no problem to push the patch, but I am not using cassandra, so cannot do a proper review. Cheers, Daniel On 12/03/14 08:53, jay binks wrote:If doing a query that returns no results ( Insert etc ) db_cassa_raw_query would cause these ERRORS to be logged 0(22283) ERROR: db_cassandra [dbcassa_base.cpp:739]: db_cassa_raw_query(): The resultype rows was not set, no point trying to parse result. 0(22283) ERROR: avpops [avpops_db.c:333]: db_query_avp(): cannot do the query db_cassa_raw_query would also return -1 as a failure code which caused avpops_db to log the query failure. my patch changes the db_cassa_raw_query log message to debug level, and returns success from the function. I had a quick look to see if there was an elegant way to determine if we should expect results, so we can vary the response code based on query type, but I was unable to find anything other than doing string comparisons on the query, so I opted to not bother with this as it would be erroneous. Please find attached patch. -- Sincerely Jay _______________________________________________ sr-dev mailing list sr-dev@lists.sip-router.org <mailto:sr-dev@lists.sip-router.org> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev-- Daniel-Constantin Mierla -http://www.asipto.com http://twitter.com/#!/miconda <http://twitter.com/#%21/miconda> -http://www.linkedin.com/in/miconda Kamailio World Conference - April 2-4, 2014, Berlin, Germany http://www.kamailioworld.com _______________________________________________ sr-dev mailing list sr-dev@lists.sip-router.org <mailto:sr-dev@lists.sip-router.org> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev-- Sincerely
Jay
I just explicitly testing this.
Results :
A sane query, but table dosnt exist performed as expected :
avp_db_query("INSERT INTO tablenothere ( KEY, added ) VALUES ( '$si', '$Ts' );"); 0(26936) ERROR: db_cassandra [dbcassa_base.cpp:729]: db_cassa_raw_query(): Invalid Request caused error details: unconfigured columnfamily tablenothere.
And insane query where its virtually just crap in a statement also behaved well :
avp_db_query("INSERT INTO tablenothere ( idont enven K'now how to Sql"); 0(26913) ERROR: db_cassandra [dbcassa_base.cpp:729]: db_cassa_raw_query(): Invalid Request caused error details: line 1:55 mismatched character '<EOF>' expecting '''.
Id say the answer to your question is yes, my patch works as expected in this regard.
Jay
On 12 March 2014 19:27, Daniel-Constantin Mierla miconda@gmail.com wrote:
On 12/03/14 10:16, jay binks wrote:
In my test case I was doing an INSERT query... yet db_cassandra would complain there was no result... ( both the log message and return code )
In understand that and you are right here -- even select can have no result (but maybe is setting some other fields there). What I want to clarify is that in case of a query error (e.g., wrong statement or something happened with the connection), is it detected? Not to behave like it was all ok.
Cheers, Daniel
This is the reason I provided the patch.
after a little more testing I have found that I get this log message :
0(23827) ERROR: <core> [db_res.c:130]: db_free_result(): invalid parameter
So far in my testing everything has performed flawlessly, just with a few less log lines :)
in essence this patch simply makes db_cassandra act the same when there is no result set as it does when there are now rows. ( previously it would act like no result set was a big deal )
Jay
On 12 March 2014 18:49, Daniel-Constantin Mierla miconda@gmail.comwrote:
What would be the situation when the query is like SELECT but there is no result. Is the behaviour as expected with the new patch?
Anyone here using cassandra having comments? From my point of view is no problem to push the patch, but I am not using cassandra, so cannot do a proper review.
Cheers, Daniel
On 12/03/14 08:53, jay binks wrote:
If doing a query that returns no results ( Insert etc ) db_cassa_raw_query would cause these ERRORS to be logged
0(22283) ERROR: db_cassandra [dbcassa_base.cpp:739]: db_cassa_raw_query(): The resultype rows was not set, no point trying to parse result. 0(22283) ERROR: avpops [avpops_db.c:333]: db_query_avp(): cannot do the query
db_cassa_raw_query would also return -1 as a failure code which caused avpops_db to log the query failure.
my patch changes the db_cassa_raw_query log message to debug level, and returns success from the function.
I had a quick look to see if there was an elegant way to determine if we should expect results, so we can vary the response code based on query type, but I was unable to find anything other than doing string comparisons on the query, so I opted to not bother with this as it would be erroneous.
Please find attached patch.
-- Sincerely
Jay
sr-dev mailing listsr-dev@lists.sip-router.orghttp://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
-- Daniel-Constantin Mierla - http://www.asipto.comhttp://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Kamailio World Conference - April 2-4, 2014, Berlin, Germanyhttp://www.kamailioworld.com
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
-- Sincerely
Jay
-- Daniel-Constantin Mierla - http://www.asipto.comhttp://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Kamailio World Conference - April 2-4, 2014, Berlin, Germanyhttp://www.kamailioworld.com
Sigh... seems my last patch was not against head...
new patch... git log.. commit 99d50e2da0753d7482ed2884e665e08e235daf5e Author: Jason Penton jason.penton@gmail.com Date: Mon Mar 10 19:49:39 2014 +0200
Sorry all !
On 12 March 2014 19:32, jay binks jaybinks@gmail.com wrote:
I just explicitly testing this.
Results :
A sane query, but table dosnt exist performed as expected :
avp_db_query("INSERT INTO tablenothere ( KEY, added ) VALUES ( '$si', '$Ts' );"); 0(26936) ERROR: db_cassandra [dbcassa_base.cpp:729]: db_cassa_raw_query(): Invalid Request caused error details: unconfigured columnfamily tablenothere.
And insane query where its virtually just crap in a statement also behaved well :
avp_db_query("INSERT INTO tablenothere ( idont enven K'now how to Sql"); 0(26913) ERROR: db_cassandra [dbcassa_base.cpp:729]: db_cassa_raw_query(): Invalid Request caused error details: line 1:55 mismatched character '<EOF>' expecting '''.
Id say the answer to your question is yes, my patch works as expected in this regard.
Jay
On 12 March 2014 19:27, Daniel-Constantin Mierla miconda@gmail.comwrote:
On 12/03/14 10:16, jay binks wrote:
In my test case I was doing an INSERT query... yet db_cassandra would complain there was no result... ( both the log message and return code )
In understand that and you are right here -- even select can have no result (but maybe is setting some other fields there). What I want to clarify is that in case of a query error (e.g., wrong statement or something happened with the connection), is it detected? Not to behave like it was all ok.
Cheers, Daniel
This is the reason I provided the patch.
after a little more testing I have found that I get this log message :
0(23827) ERROR: <core> [db_res.c:130]: db_free_result(): invalid parameter
So far in my testing everything has performed flawlessly, just with a few less log lines :)
in essence this patch simply makes db_cassandra act the same when there is no result set as it does when there are now rows. ( previously it would act like no result set was a big deal )
Jay
On 12 March 2014 18:49, Daniel-Constantin Mierla miconda@gmail.comwrote:
What would be the situation when the query is like SELECT but there is no result. Is the behaviour as expected with the new patch?
Anyone here using cassandra having comments? From my point of view is no problem to push the patch, but I am not using cassandra, so cannot do a proper review.
Cheers, Daniel
On 12/03/14 08:53, jay binks wrote:
If doing a query that returns no results ( Insert etc ) db_cassa_raw_query would cause these ERRORS to be logged
0(22283) ERROR: db_cassandra [dbcassa_base.cpp:739]: db_cassa_raw_query(): The resultype rows was not set, no point trying to parse result. 0(22283) ERROR: avpops [avpops_db.c:333]: db_query_avp(): cannot do the query
db_cassa_raw_query would also return -1 as a failure code which caused avpops_db to log the query failure.
my patch changes the db_cassa_raw_query log message to debug level, and returns success from the function.
I had a quick look to see if there was an elegant way to determine if we should expect results, so we can vary the response code based on query type, but I was unable to find anything other than doing string comparisons on the query, so I opted to not bother with this as it would be erroneous.
Please find attached patch.
-- Sincerely
Jay
sr-dev mailing listsr-dev@lists.sip-router.orghttp://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
-- Daniel-Constantin Mierla - http://www.asipto.comhttp://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Kamailio World Conference - April 2-4, 2014, Berlin, Germanyhttp://www.kamailioworld.com
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
-- Sincerely
Jay
-- Daniel-Constantin Mierla - http://www.asipto.comhttp://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Kamailio World Conference - April 2-4, 2014, Berlin, Germanyhttp://www.kamailioworld.com
-- Sincerely
Jay
I tried this one and it doesn't apply either. Is the right patch for master head?
Cheers, Daniel
On 12/03/14 10:49, jay binks wrote:
Sigh... seems my last patch was not against head...
new patch... git log.. commit 99d50e2da0753d7482ed2884e665e08e235daf5e Author: Jason Penton <jason.penton@gmail.com mailto:jason.penton@gmail.com> Date: Mon Mar 10 19:49:39 2014 +0200
Sorry all !
On 12 March 2014 19:32, jay binks <jaybinks@gmail.com mailto:jaybinks@gmail.com> wrote:
I just explicitly testing this. Results : A sane query, but table dosnt exist performed as expected : avp_db_query("INSERT INTO tablenothere ( KEY, added ) VALUES ( '$si', '$Ts' );"); 0(26936) ERROR: db_cassandra [dbcassa_base.cpp:729]: db_cassa_raw_query(): Invalid Request caused error details: unconfigured columnfamily tablenothere. And insane query where its virtually just crap in a statement also behaved well : avp_db_query("INSERT INTO tablenothere ( idont enven K'now how to Sql"); 0(26913) ERROR: db_cassandra [dbcassa_base.cpp:729]: db_cassa_raw_query(): Invalid Request caused error details: line 1:55 mismatched character '<EOF>' expecting '''. Id say the answer to your question is yes, my patch works as expected in this regard. Jay On 12 March 2014 19:27, Daniel-Constantin Mierla <miconda@gmail.com <mailto:miconda@gmail.com>> wrote: On 12/03/14 10:16, jay binks wrote:In my test case I was doing an INSERT query... yet db_cassandra would complain there was no result... ( both the log message and return code )In understand that and you are right here -- even select can have no result (but maybe is setting some other fields there). What I want to clarify is that in case of a query error (e.g., wrong statement or something happened with the connection), is it detected? Not to behave like it was all ok. Cheers, DanielThis is the reason I provided the patch. after a little more testing I have found that I get this log message : 0(23827) ERROR: <core> [db_res.c:130]: db_free_result(): invalid parameter So far in my testing everything has performed flawlessly, just with a few less log lines :) in essence this patch simply makes db_cassandra act the same when there is no result set as it does when there are now rows. ( previously it would act like no result set was a big deal ) Jay On 12 March 2014 18:49, Daniel-Constantin Mierla <miconda@gmail.com <mailto:miconda@gmail.com>> wrote: What would be the situation when the query is like SELECT but there is no result. Is the behaviour as expected with the new patch? Anyone here using cassandra having comments? From my point of view is no problem to push the patch, but I am not using cassandra, so cannot do a proper review. Cheers, Daniel On 12/03/14 08:53, jay binks wrote:If doing a query that returns no results ( Insert etc ) db_cassa_raw_query would cause these ERRORS to be logged 0(22283) ERROR: db_cassandra [dbcassa_base.cpp:739]: db_cassa_raw_query(): The resultype rows was not set, no point trying to parse result. 0(22283) ERROR: avpops [avpops_db.c:333]: db_query_avp(): cannot do the query db_cassa_raw_query would also return -1 as a failure code which caused avpops_db to log the query failure. my patch changes the db_cassa_raw_query log message to debug level, and returns success from the function. I had a quick look to see if there was an elegant way to determine if we should expect results, so we can vary the response code based on query type, but I was unable to find anything other than doing string comparisons on the query, so I opted to not bother with this as it would be erroneous. Please find attached patch. -- Sincerely Jay _______________________________________________ sr-dev mailing list sr-dev@lists.sip-router.org <mailto:sr-dev@lists.sip-router.org> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev-- Daniel-Constantin Mierla -http://www.asipto.com http://twitter.com/#!/miconda <http://twitter.com/#%21/miconda> -http://www.linkedin.com/in/miconda Kamailio World Conference - April 2-4, 2014, Berlin, Germany http://www.kamailioworld.com _______________________________________________ sr-dev mailing list sr-dev@lists.sip-router.org <mailto:sr-dev@lists.sip-router.org> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev -- Sincerely Jay-- Daniel-Constantin Mierla -http://www.asipto.com http://twitter.com/#!/miconda <http://twitter.com/#%21/miconda> -http://www.linkedin.com/in/miconda Kamailio World Conference - April 2-4, 2014, Berlin, Germany http://www.kamailioworld.com -- Sincerely Jay-- Sincerely
Jay
Im not sure whats going on... I have a bunch of patches and im now having all kinds of trouble after stashing, and moving up to git head.
back to all sorts of things being broken.
Sorry to trouble.... hopefully I can work through these issues again and update patches..
On 12 March 2014 19:52, Daniel-Constantin Mierla miconda@gmail.com wrote:
I tried this one and it doesn't apply either. Is the right patch for master head?
Cheers, Daniel
On 12/03/14 10:49, jay binks wrote:
Sigh... seems my last patch was not against head...
new patch... git log.. commit 99d50e2da0753d7482ed2884e665e08e235daf5e Author: Jason Penton jason.penton@gmail.com Date: Mon Mar 10 19:49:39 2014 +0200
Sorry all !
On 12 March 2014 19:32, jay binks jaybinks@gmail.com wrote:
I just explicitly testing this.
Results :
A sane query, but table dosnt exist performed as expected :
avp_db_query("INSERT INTO tablenothere ( KEY, added ) VALUES ( '$si', '$Ts' );"); 0(26936) ERROR: db_cassandra [dbcassa_base.cpp:729]: db_cassa_raw_query(): Invalid Request caused error details: unconfigured columnfamily tablenothere.
And insane query where its virtually just crap in a statement also behaved well :
avp_db_query("INSERT INTO tablenothere ( idont enven K'now how to Sql"); 0(26913) ERROR: db_cassandra [dbcassa_base.cpp:729]: db_cassa_raw_query(): Invalid Request caused error details: line 1:55 mismatched character '<EOF>' expecting '''.
Id say the answer to your question is yes, my patch works as expected in this regard.
Jay
On 12 March 2014 19:27, Daniel-Constantin Mierla miconda@gmail.comwrote:
On 12/03/14 10:16, jay binks wrote:
In my test case I was doing an INSERT query... yet db_cassandra would complain there was no result... ( both the log message and return code )
In understand that and you are right here -- even select can have no result (but maybe is setting some other fields there). What I want to clarify is that in case of a query error (e.g., wrong statement or something happened with the connection), is it detected? Not to behave like it was all ok.
Cheers, Daniel
This is the reason I provided the patch.
after a little more testing I have found that I get this log message :
0(23827) ERROR: <core> [db_res.c:130]: db_free_result(): invalid parameter
So far in my testing everything has performed flawlessly, just with a few less log lines :)
in essence this patch simply makes db_cassandra act the same when there is no result set as it does when there are now rows. ( previously it would act like no result set was a big deal )
Jay
On 12 March 2014 18:49, Daniel-Constantin Mierla miconda@gmail.comwrote:
What would be the situation when the query is like SELECT but there is no result. Is the behaviour as expected with the new patch?
Anyone here using cassandra having comments? From my point of view is no problem to push the patch, but I am not using cassandra, so cannot do a proper review.
Cheers, Daniel
On 12/03/14 08:53, jay binks wrote:
If doing a query that returns no results ( Insert etc ) db_cassa_raw_query would cause these ERRORS to be logged
0(22283) ERROR: db_cassandra [dbcassa_base.cpp:739]: db_cassa_raw_query(): The resultype rows was not set, no point trying to parse result. 0(22283) ERROR: avpops [avpops_db.c:333]: db_query_avp(): cannot do the query
db_cassa_raw_query would also return -1 as a failure code which caused avpops_db to log the query failure.
my patch changes the db_cassa_raw_query log message to debug level, and returns success from the function.
I had a quick look to see if there was an elegant way to determine if we should expect results, so we can vary the response code based on query type, but I was unable to find anything other than doing string comparisons on the query, so I opted to not bother with this as it would be erroneous.
Please find attached patch.
-- Sincerely
Jay
sr-dev mailing listsr-dev@lists.sip-router.orghttp://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
-- Daniel-Constantin Mierla - http://www.asipto.comhttp://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Kamailio World Conference - April 2-4, 2014, Berlin, Germanyhttp://www.kamailioworld.com
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
-- Sincerely
Jay
-- Daniel-Constantin Mierla - http://www.asipto.comhttp://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Kamailio World Conference - April 2-4, 2014, Berlin, Germanyhttp://www.kamailioworld.com
-- Sincerely
Jay
-- Sincerely
Jay
-- Daniel-Constantin Mierla - http://www.asipto.comhttp://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Kamailio World Conference - April 2-4, 2014, Berlin, Germanyhttp://www.kamailioworld.com
Ok so this patch should now be correct... sorry, took me a while to get back to this project.
please let me know if this patches cleanly.
On 12 March 2014 20:26, jay binks jaybinks@gmail.com wrote:
Im not sure whats going on... I have a bunch of patches and im now having all kinds of trouble after stashing, and moving up to git head.
back to all sorts of things being broken.
Sorry to trouble.... hopefully I can work through these issues again and update patches..
On 12 March 2014 19:52, Daniel-Constantin Mierla miconda@gmail.comwrote:
I tried this one and it doesn't apply either. Is the right patch for master head?
Cheers, Daniel
On 12/03/14 10:49, jay binks wrote:
Sigh... seems my last patch was not against head...
new patch... git log.. commit 99d50e2da0753d7482ed2884e665e08e235daf5e Author: Jason Penton jason.penton@gmail.com Date: Mon Mar 10 19:49:39 2014 +0200
Sorry all !
On 12 March 2014 19:32, jay binks jaybinks@gmail.com wrote:
I just explicitly testing this.
Results :
A sane query, but table dosnt exist performed as expected :
avp_db_query("INSERT INTO tablenothere ( KEY, added ) VALUES ( '$si', '$Ts' );"); 0(26936) ERROR: db_cassandra [dbcassa_base.cpp:729]: db_cassa_raw_query(): Invalid Request caused error details: unconfigured columnfamily tablenothere.
And insane query where its virtually just crap in a statement also behaved well :
avp_db_query("INSERT INTO tablenothere ( idont enven K'now how to Sql"); 0(26913) ERROR: db_cassandra [dbcassa_base.cpp:729]: db_cassa_raw_query(): Invalid Request caused error details: line 1:55 mismatched character '<EOF>' expecting '''.
Id say the answer to your question is yes, my patch works as expected in this regard.
Jay
On 12 March 2014 19:27, Daniel-Constantin Mierla miconda@gmail.comwrote:
On 12/03/14 10:16, jay binks wrote:
In my test case I was doing an INSERT query... yet db_cassandra would complain there was no result... ( both the log message and return code )
In understand that and you are right here -- even select can have no result (but maybe is setting some other fields there). What I want to clarify is that in case of a query error (e.g., wrong statement or something happened with the connection), is it detected? Not to behave like it was all ok.
Cheers, Daniel
This is the reason I provided the patch.
after a little more testing I have found that I get this log message :
0(23827) ERROR: <core> [db_res.c:130]: db_free_result(): invalid parameter
So far in my testing everything has performed flawlessly, just with a few less log lines :)
in essence this patch simply makes db_cassandra act the same when there is no result set as it does when there are now rows. ( previously it would act like no result set was a big deal )
Jay
On 12 March 2014 18:49, Daniel-Constantin Mierla miconda@gmail.comwrote:
What would be the situation when the query is like SELECT but there is no result. Is the behaviour as expected with the new patch?
Anyone here using cassandra having comments? From my point of view is no problem to push the patch, but I am not using cassandra, so cannot do a proper review.
Cheers, Daniel
On 12/03/14 08:53, jay binks wrote:
If doing a query that returns no results ( Insert etc ) db_cassa_raw_query would cause these ERRORS to be logged
0(22283) ERROR: db_cassandra [dbcassa_base.cpp:739]: db_cassa_raw_query(): The resultype rows was not set, no point trying to parse result. 0(22283) ERROR: avpops [avpops_db.c:333]: db_query_avp(): cannot do the query
db_cassa_raw_query would also return -1 as a failure code which caused avpops_db to log the query failure.
my patch changes the db_cassa_raw_query log message to debug level, and returns success from the function.
I had a quick look to see if there was an elegant way to determine if we should expect results, so we can vary the response code based on query type, but I was unable to find anything other than doing string comparisons on the query, so I opted to not bother with this as it would be erroneous.
Please find attached patch.
-- Sincerely
Jay
sr-dev mailing listsr-dev@lists.sip-router.orghttp://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
-- Daniel-Constantin Mierla - http://www.asipto.comhttp://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Kamailio World Conference - April 2-4, 2014, Berlin, Germanyhttp://www.kamailioworld.com
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
-- Sincerely
Jay
-- Daniel-Constantin Mierla - http://www.asipto.comhttp://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Kamailio World Conference - April 2-4, 2014, Berlin, Germanyhttp://www.kamailioworld.com
-- Sincerely
Jay
-- Sincerely
Jay
-- Daniel-Constantin Mierla - http://www.asipto.comhttp://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Kamailio World Conference - April 2-4, 2014, Berlin, Germanyhttp://www.kamailioworld.com
-- Sincerely
Jay
-
Daniel-Constantin Mierla -
jay binks