[OpenSIPS-Users] MySQL Type: FIELD_TYPE_NEWDECIMAL (246) uses DB_INT result type but should use float

[Calvin Ellison]

Copying Brett's reply back to the list. I deleted some of the previous
conversation to avoid "message too large".

I also noticed DB_DOUBLE is missing from /avpops/avpops_db.c but I don't
know C well enough to do the needful. Do you know what should be done to
make it a string?

Here's my updated /db_mysql/res.c. I did as you suggested and
moved MYSQL_TYPE_NEWDECIMAL along with its #if condition to just after
MYSQL_TYPE_FLOAT so it is DB_DOUBLE not DB_INT. It looks like the same
change is needed for MYSQL_TYPE_DECIMAL since this can also be non-integer,
but I didn't touch that.

                switch(fields[col].type) {
                        case MYSQL_TYPE_TINY:
                        case MYSQL_TYPE_SHORT:
                        case MYSQL_TYPE_LONG:
                        case MYSQL_TYPE_INT24:
                        case MYSQL_TYPE_DECIMAL:
                        case MYSQL_TYPE_TIMESTAMP:
                                LM_DBG("use DB_INT result type\n");
                                RES_TYPES(_r)[col] = DB_INT;
                                break;

                        case MYSQL_TYPE_FLOAT:
                        #if MYSQL_VERSION_ID > 49999
                        case MYSQL_TYPE_NEWDECIMAL:
                        #endif
                        case MYSQL_TYPE_DOUBLE:
                                LM_DBG("use DB_DOUBLE result type\n");
                                RES_TYPES(_r)[col] = DB_DOUBLE;
                                break;


Regards,

*Calvin Ellison*
Senior Voice Operations Engineer
calvin.ellison at voxox.com
On Mon, Mar 9, 2020 at 2:50 PM Brett Nemeroff <brett at nemeroff.com> wrote:

> Hey Calvin, my reply to you got blocked by the list auto-moderator for
> being too large. I have no idea why? Here’s my reply:
>
> Hey Calvin,
> Glad that helped. I'd need to see how you fixed res.c to know why that
> isn't working. However, most likely it's because of a lack of proper
> support of doubles. if you take a look at:
> /avpops/avpops_db.c
>
> You'll see in there that it checks the AVP type and there is no type for
> DB_DOUBLE from what I can see. I'm surprised this hasn't come up more
> often.
>
> I don't think the fix would be too hard, at least to make it more usable.
> You can see the handing in avpops_db isn't super. It's basically coheresing
> the returned values to an INT or a STRING. You could do the same by asking
> for a CAST or having the function cast the value before returning (ie: if
> your SP returned only strings and integers, you would not see this issue.)
>
>
> On Mon, Mar 9, 2020 at 2:23 PM Calvin Ellison <calvin.ellison at voxox.com>
> wrote:
>
>> Updating the C code per Brett's suggestion resolved that specific error:
>>
>> DBG:db_mysql:db_mysql_str2val: converting DOUBLE [0.0018]
>>
>> Now there is a warning when trying to print that avp:
>>
>> WARNING:avpops:db_query_avp_print_results: Unknown type 2
>>
>> I don't really care about this particular variable, but if the same issue
>> were to come up again in another context then what fix is needed to print
>> this as a string?
>>
>> Regards,
>>
>> *Calvin Ellison*
>> Senior Voice Operations Engineer
>> calvin.ellison at voxox.com
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20200309/b01b11d1/attachment.html>