[sr-dev] db_cassandra - db_cassa_raw_query & INSERT query
Daniel-Constantin Mierla
miconda at gmail.com
Wed Mar 12 10:52:31 CET 2014
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 at gmail.com
> <mailto:jason.penton at gmail.com>>
> Date: Mon Mar 10 19:49:39 2014 +0200
>
> Sorry all !
>
>
>
> On 12 March 2014 19:32, jay binks <jaybinks at gmail.com
> <mailto:jaybinks at 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 at gmail.com <mailto:miconda at 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 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://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
--
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/a2180b77/attachment-0001.html>
More information about the sr-dev
mailing list