Re: [sr-dev] db_cassandra - db_cassa_raw_query & INSERT query

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 &lt;miconda(a)gmail.com&gt;wrote;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(a)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