gt;>
>> *From: *Users on behalf of Brett
>> Nemeroff
>> *Reply-To: *OpenSIPS users mailling list
>> *Date: *Monday, March 9, 2020 at 1:20 PM
>> *To: *Calvin Ellison , OpenSIPS users mailling
>> list
>> *Subject: *Re: [OpenSIPS-Users] MySQL Type: FI
on using
string variables.
Ben Newlin
From: Users on behalf of Brett Nemeroff
Reply-To: OpenSIPS users mailling list
Date: Monday, March 9, 2020 at 1:20 PM
To: Calvin Ellison , OpenSIPS users mailling list
Subject: Re: [OpenSIPS-Users] MySQL Type: FIELD_TYPE_NEWDECIMAL (246) uses
DB_INT
Glad to have been able to help! Liviu, many thanks for the quick patch!
On Wed, Mar 11, 2020 at 2:24 PM Calvin Ellison
wrote:
> Thanks, Liviu! It turns out the service provider who I'm getting that
> "delay" value from has been watching this thread, and we both appreciate
> the attention and
Thanks, Liviu! It turns out the service provider who I'm getting that
"delay" value from has been watching this thread, and we both appreciate
the attention and immediate response. Thanks also to Brett for his part in
this.
Regards,
*Calvin Ellison*
Senior Voice Operations Engineer
On Wed, Mar
I agree with you. The immediate concern here is not performing calculations
on the value, but that the string provided by avp is not necessarily what
was contained in the database, which is unexpected behavior. And that's OK
so long as the user is aware that the data could be truncated or padded
This is great. Thank you Liviu!
On Wed, Mar 11, 2020 at 12:01 PM Liviu Chircu wrote:
> On 11.03.2020 18:54, Calvin Ellison wrote:
> > Then as Brett suggested, "make it [the default precision] defined in
> > the header file for those who want to recompile it."
>
> This is already in place [1].
>
Calvin,
The issue is more about what you want to do with that data in the opensips
script. Are you really wanting to do floating point math in the script? Or
are you taking those floats (like GPS coordinates) and using them as string
values in a header. If that’s all you want to do, you should
On 11.03.2020 18:54, Calvin Ellison wrote:
Then as Brett suggested, "make it [the default precision] defined in
the header file for those who want to recompile it."
This is already in place [1].
I suggest we add the modparam once someone really needs it. But feel
free to submit a PR
Or perhaps a direct way to tell avpops what precision to use for a given
field, as an exported parameter?
double_precision (string)
The number of decimal places to use when converting decimal, floating, and
other double type values to avp string
If no db_id reference number is given, 0 is assumed
On 11.03.2020 17:50, Brett Nemeroff wrote:
As a middle ground, instead of extending db_val_t, what if you used
the cues from the DB driver to enforce the digits of precision while
casting to a STRING
But the double->string cast is done super late, within avpops, only as
it's walking through
Liviu,
In my opinion, way too much work for almost no value. I wouldn’t worry
about it. I think the 8 digits of precision is ok for now really. Certainly
meets my needs.
As a middle ground, instead of extending db_val_t, what if you used the
cues from the DB driver to enforce the digits of
On 10.03.2020 20:55, Brett Nemeroff wrote:
Can you inspect the DB type to derive a precision for the STRING
format? Then maybe default to 8 if you can't derive it?
We probably could, but looking at db/db_val.h +75, you can see that the
generic db_val_t type has no support for storing the
Actually, I think that may be a good idea Liviu,
Can you inspect the DB type to derive a precision for the STRING format?
Then maybe default to 8 if you can't derive it? I think that gives us the
best of everything. But it does require a column datatype inspection. What
do you think?
-Brett
On
On Tue, Mar 10, 2020 at 10:31 AM Brett Nemeroff wrote:
> Liviu,
> My preference would be to default to 8, but make it defined in the header
> file for those who want to recompile it. 6 is ok, it’s usually the minimum
> precision that is acceptable.
>
My comment about significant digits was with
Liviu,
My preference would be to default to 8, but make it defined in the header
file for those who want to recompile it. 6 is ok, it’s usually the minimum
precision that is acceptable.
Thanks!!
On Tue, Mar 10, 2020 at 12:19 PM Liviu Chircu wrote:
> On 10.03.2020 19:07, Calvin Ellison wrote:
>
On 10.03.2020 19:07, Calvin Ellison wrote:
However, when printed it appears as "0.001900". If that his how thing
string would be passed to mathops, etc., it would cause problems for
anyone interested in significant digits.
Indeed, the "%lf" format specified in C truncates double numbers down
The patch appears to be working as intended with regards to storing and
later using the decimal value as a string:
Mar 10 09:50:15 localhost /usr/sbin/opensips[27541]:
DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7f8ecd2b5d68)[14]=[delay]
Mar 10 09:50:15 localhost /usr/sbin/opensips[27541]:
Totally agree that this is the right thing to do. I just wanted the list to
know it’s a STRING. I don’t think it’s obvious.
Thanks again!!
On Tue, Mar 10, 2020 at 11:45 AM Liviu Chircu wrote:
> On 10.03.2020 18:39, Brett Nemeroff wrote:
> > This isn’t really a problem unless you are going to
On 10.03.2020 18:39, Brett Nemeroff wrote:
This isn’t really a problem unless you are going to math it or push it
into something else without casting it.
I agree, but at script level, there is no support for manipulating
"long" integers,
let along "double" precision integers. So casting the
Liviu,
Thanks for the quick fix! I can’t believe this hasn’t been more of an
issue. But then again, it may be a weird thing to want a double in the
script context since you can’t or at least shouldn’t be doing a lot of high
level stuff there.
Calvin / Liviu,
I haven’t tested this fix yet, but I
On 10.03.2020 00:25, Calvin Ellison wrote:
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
Calvin,
If you look at the code blocks, I’d start by mirroring one of the string
type conversion code blocks and see how you do. You should see it repeated
a bunch of times (in avpops_db.c). I’m away from the code right now, so I
can only be of limited help at the moment.
-Brett
On Mon, Mar 9,
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
sers mailling list
> *Date: *Monday, March 9, 2020 at 1:20 PM
> *To: *Calvin Ellison , OpenSIPS users mailling
> list
> *Subject: *Re: [OpenSIPS-Users] MySQL Type: FIELD_TYPE_NEWDECIMAL (246)
> uses DB_INT result type but should use float
>
>
>
> Can you just statical
Can you just statically put a integer in there? Like say, 0?
I actually think this is a bug. You are using 2.4.7? I don’t see this fixed
in newer versions.
The bug is on Line 81 of res.c. It incorrectly assumes that
MYSQL_TYPE_NEWDECIMAL is an INT. This should be easy for you to attempt to
fix
The problem, as I see it, is that the MariaDB server is indicating this
field is a floating-point (FIELD_TYPE_NEWDECIMAL), but OpenSIPS is casting
that integer (DB_INT).
I don't really need the delay field but I have no way to exclude it from
the result and avp_db_query want every field mapped to
Hello Calvin,
Looks like your coerecing a float into an integer field. I think it's your
delay field. What do you expect to happen here? I mean that seriously. If
the delay field is an integer, you can't put anything but an integer in it
if you have no access to change the database type.
It appears that OpenSIPS is assuming an incorrect integer data type on a
field that is a floating-point value. I have no access to change the field
type in the database. What can be done?
Server version: 10.2.31-MariaDB MariaDB Server
Query and response attached
async(avp_db_query("call
28 matches
Mail list logo
