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, below DB1_INT should be changed to DB1_UNIT and VAL_INT to VAL_UNIT?
-- Juha
if(VAL_NULL(ROW_VALUES(row) + 11)) { defunct_until = 0; } else { if(VAL_TYPE(ROW_VALUES(row) + 11) != DB1_INT) { LM_ERR("lcr_gw defunct at row <%u> is not int\n", i); return 0; } defunct_until = (unsigned int)VAL_INT(ROW_VALUES(row) + 11); if(defunct_until > 4294967294UL) { LM_DBG("skipping disabled gw <%u>\n", gw_id); continue; } }
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) {
Getting the value with VAL_INT(ROW_VALUES(row) + 11) is still ok, because the value is stored in a union and signed/unsigned int uses the same 4 bytes.
The alternative is to remove UNSIGNED from the column definition. Alexander Dubovikov mentioned that there is a MySQl server setting for strict data type usage, that is turned on, but can be turned off via mysql server (or client) config. More info on the issue: apparently, based on checking some of the DB variants libs, only MySQL does the difference with UNSIGNED. The others seem work with signed types only.
I also looked quickly at using flags instead of data type for unsigned (mysql does it like that), but that seems be more complex change in the DB API, because the column is specified as name only, so by changing that to a struct I expect that most of queries will be affected. Maybe pushing that to value type ... needs more analyzis...
Cheers, Daniel