On 01.10.18 17:50, Juha Heinanen wrote:
> Daniel-Constantin Mierla writes:
>
>> You have to change:
>>
>> if(VAL_TYPE(ROW_VALUES(row) + 11) != DB1_INT) {
>>
>> to something like:
>>
>> if(VAL_TYPE(ROW_VALUES(row) + 11) != DB1_INT && VAL_TYPE(ROW_VALUES(row) +
>> 11) != DB1_UINT) {
> Why do I
Daniel-Constantin Mierla writes:
> You have to change:
>
> if(VAL_TYPE(ROW_VALUES(row) + 11) != DB1_INT) {
>
> to something like:
>
> if(VAL_TYPE(ROW_VALUES(row) + 11) != DB1_INT && VAL_TYPE(ROW_VALUES(row) +
> 11) != DB1_UINT) {
Why do I need to test both DB1_INT and DB1_UINT, since the
On 01.10.18 13:56, Juha Heinanen wrote:
> Daniel-Constantin Mierla writes:
>
>> This update with new database types DB1_UINT and DB1_UBIGINT started on
>> Friday. I expected that only insert/updates with high values to be
>> affected, but it seems that loading is also hit.
> So, for example,
Daniel-Constantin Mierla writes:
> This update with new database types DB1_UINT and DB1_UBIGINT started on
> Friday. I expected that only insert/updates with high values to be
> affected, but it seems that loading is also hit.
So, for example, below DB1_INT should be changed to DB1_UNIT and
Daniel-Constantin Mierla writes:
> Given that it may take some time to propagate the new unsigned types, I
> added a paramter to db_mysql to enable/disable converting to these
> types. By default is off, so it should work as before last Friday.
>
> Can you give another try with latest master
Given that it may take some time to propagate the new unsigned types, I
added a paramter to db_mysql to enable/disable converting to these
types. By default is off, so it should work as before last Friday.
Can you give another try with latest master and see the results?
Cheers,
Daniel
On
On 01.10.18 09:48, Juha Heinanen wrote:
> Daniel-Constantin Mierla writes:
>
>> But as soon as a value goes negative, things get broken. For example,
>> with the modules storing expire/lifetime (e.g., usrloc, dialog) being
>> timestamp + interval, if interval is very long, then the value goes
Daniel-Constantin Mierla writes:
> But as soon as a value goes negative, things get broken. For example,
> with the modules storing expire/lifetime (e.g., usrloc, dialog) being
> timestamp + interval, if interval is very long, then the value goes over
> mid of UNSIGNED, practically becoming
On 01.10.18 09:35, Juha Heinanen wrote:
> Daniel-Constantin Mierla writes:
>
>> It is the same case -- the database schema defined unsigned types of
>> columns although internally only signed types were supported. This works
>> fine as long as the value inserted in the database is a positive
Daniel-Constantin Mierla writes:
> It is the same case -- the database schema defined unsigned types of
> columns although internally only signed types were supported. This works
> fine as long as the value inserted in the database is a positive integer
> (not a negative integer).
I don't have
Just in case someone wants to go ahead and update the code for some
modules, in addition for DB1_INT or DB1_BINGINT, the code has to handle
the type DB1_UINT or DB1_UBINGINT if the database table column has
UNSIGNED type. All types have to be taken in consideration, because only
MySQL defines the
It is the same case -- the database schema defined unsigned types of
columns although internally only signed types were supported. This works
fine as long as the value inserted in the database is a positive integer
(not a negative integer).
Will review all database table definitions and update
Daniel-Constantin Mierla writes:
> This was related to adding support for UNSIGNED types. So far we had
> only signed types in DB API, but latest MySQL version is inserting 0
> without any error when the actual value is a signed negative value.
>
> Should be fixed now in latest master, try with
This was related to adding support for UNSIGNED types. So far we had
only signed types in DB API, but latest MySQL version is inserting 0
without any error when the actual value is a signed negative value.
Should be fixed now in latest master, try with it and see if all fine now.
Cheers,
Daniel
Daniel-Constantin Mierla writes:
> I just pushed a patch for it, can you test and see if all goes fine with
> your config?
cfg_rpc module error is now gone, but got another one:
Oct 1 08:37:19 char /usr/bin/sip-proxy[26419]: ERROR: [db.c:419]:
db_table_version(): invalid type (8) or nul (0)
I just pushed a patch for it, can you test and see if all goes fine with
your config?
Cheers,
Daniel
On 30.09.18 17:42, Juha Heinanen wrote:
> I have one local module and updated its module interface to the new
> one. Then I build K, started it and got a crash. I thought that it
> must my
I have one local module and updated its module interface to the new
one. Then I build K, started it and got a crash. I thought that it
must my mistake in the module interface update, but when I looked at the
core dump, it did point to another module:
(gdb) where
#0 0x5643e66fd349 in
17 matches
Mail list logo
