[sr-dev] db_cassandra - db_cassa_raw_query & INSERT query

Daniel-Constantin Mierla miconda at gmail.com
Wed Mar 12 10:27:25 CET 2014


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 at gmail.com 
> <mailto:miconda at 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 at lists.sip-router.org  <mailto:sr-dev at 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 at lists.sip-router.org <mailto:sr-dev at 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://www.linkedin.com/in/miconda
Kamailio World Conference - April 2-4, 2014, Berlin, Germany
http://www.kamailioworld.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-dev/attachments/20140312/4f690ed6/attachment-0001.html>


More information about the sr-dev mailing list