3 Apr
2009
3 Apr
'09
7:54 a.m.
Greetings,
I just installed 1.5.0 and wired it up to a MySQL 5.0.x database, and it
appears that I am getting empty/null values for BIGINT columns when
accessing them from script.
This is true when I do something like this with SQLOps, for example:
sql_query("test", "SELECT someBigIntColumn FROM tbl",
"ra");
$var(i) = $dbr(ra=>[0,0]);
$var(i) will have an empty value.
Same will be the case if the access subscript is not [0,0] but say, [0,1].
The problem does not seem to be specific to sqlops; the same occurs
with AVPs:
avp_db_query("SELECT someBigIntColumn FROM tbl",
"$avp(S:bigInt)");
This is also empty.
I did a debug and confirmed that the right value for someBigIntColumn is
coming out of the database, and has the right data type. All that works
fine. However, for some reason this value appears to be invisible
within the evaluative scope of the route script.
For now, I am working around it by doing CONVERT(someBigIntColumn,
CHAR(20)) inside the query. However, in principle this means that
BIGINT handling is broken.
Has anyone else run into this? Any insights, or especially, solutions?
--
Alex Balashov
Evariste Systems
Web : http://www.evaristesys.com/
Tel : (+1) (678) 954-0670
Direct : (+1) (678) 954-0671
Mobile : (+1) (678) 237-1775
3 Apr
3 Apr
9:49 a.m.
Hello,
On 04/03/2009 08:54 AM, Alex Balashov wrote:
Greetings,
I just installed 1.5.0 and wired it up to a MySQL 5.0.x database, and it
appears that I am getting empty/null values for BIGINT columns when
accessing them from script.
This is true when I do something like this with SQLOps, for example:
sql_query("test", "SELECT someBigIntColumn FROM tbl",
"ra");
$var(i) = $dbr(ra=>[0,0]);
$var(i) will have an empty value.
Same will be the case if the access subscript is not [0,0] but say, [0,1].
The problem does not seem to be specific to sqlops; the same occurs
with AVPs:
avp_db_query("SELECT someBigIntColumn FROM tbl",
"$avp(S:bigInt)");
This is also empty.
I did a debug and confirmed that the right value for someBigIntColumn is
coming out of the database, and has the right data type. All that works
fine. However, for some reason this value appears to be invisible
within the evaluative scope of the route script.
For now, I am working around it by doing CONVERT(someBigIntColumn,
CHAR(20)) inside the query. However, in principle this means that
BIGINT handling is broken.
Has anyone else run into this? Any insights, or especially, solutions?
pseudo-variables can hold only integer or string values. IIRC, Henning
added bigint inside the mysql module, but that has not support to upper
level of script variables.
Cheers,
Daniel
--
Daniel-Constantin Mierla
http://www.asipto.com/
2:39 p.m.
Daniel,
Daniel-Constantin Mierla wrote:
pseudo-variables can hold only integer or string
values. IIRC, Henning
added bigint inside the mysql module, but that has not support to upper
level of script variables.
It does not work when the value is printed in a string substitution
context either, e.g.
xlog("L_INFO", "$dbr(ra=>[0,0])\n");
I assume that is a consequence of what you said above as well?
I am not sure I understand the point of BIGINT support if the values
cannot be utilised in virtually any way in script. Can you tell me what
it is? It seems that most other variations on the theme of strings and
integers (e.g. smallint, tinyint, boolean, etc.) are usable within script...
Thanks!
--
Alex Balashov
Evariste Systems
Web : http://www.evaristesys.com/
Tel : (+1) (678) 954-0670
Direct : (+1) (678) 954-0671
Mobile : (+1) (678) 237-1775
3:04 p.m.
New subject: [Kamailio-Users] [Kamailio-Devel] BIGINT MySQL problems in 1.5.0.
On Friday 03 April 2009, Alex Balashov wrote:
[..]
I am not sure I understand the point of BIGINT support if the values
cannot be utilised in virtually any way in script. Can you tell me what
it is? It seems that most other variations on the theme of strings and
integers (e.g. smallint, tinyint, boolean, etc.) are usable within
script...
Hi Alex,
you've support in the internal DB API for BIGINT, e.g. you can insert and
query values from your module code. The same issue exists with respect to
double values, they are also not really representable in an AVP, and the
sqlops module report PV_VAL_NULL here too.
Cheers,
Henning
3:36 p.m.
On 04/03/2009 03:39 PM, Alex Balashov wrote:
Daniel,
Daniel-Constantin Mierla wrote:
it is same PV layer
used here, called by xlog module.
A PV values is stored in pv_value_t, and that can hold only int or string.
pseudo-variables can hold only integer or string
values. IIRC,
Henning added bigint inside the mysql module, but that has not
support to upper level of script variables.
It does not work when the value is printed in a string substitution
context either, e.g.
xlog("L_INFO", "$dbr(ra=>[0,0])\n");
I assume that is a consequence of what you said above as well?
Yes.
I am not sure I understand the point of BIGINT support if the values
cannot be utilised in virtually any way in script. Can you tell me
what it is? It seems that most other variations on the theme of
strings and integers (e.g. smallint, tinyint, boolean, etc.) are
usable within script...
bigint is 8B and it is only supported inside the c code by
some db
driver modules.
Cheers,
Daniel
--
Daniel-Constantin Mierla
http://www.asipto.com/
3:01 p.m.
New subject: [Kamailio-Users] [Kamailio-Devel] BIGINT MySQL problems in 1.5.0.
On Friday 03 April 2009, Daniel-Constantin Mierla wrote:
Hi Daniel,
i'll add a note to the avpops and sqlops documentation that BIGINT don't work
with it because of missing support in the underlying AVP infrastructure.
Cheers,
Henning
I just
installed 1.5.0 and wired it up to a MySQL 5.0.x database, and it
appears that I am getting empty/null values for BIGINT columns when
accessing them from script.
[..]
pseudo-variables can hold only integer or string values. IIRC, Henning
added bigint inside the mysql module, but that has not support to upper
level of script variables.
5721
days inactive
5721
days old
5 comments
3 participants
participants (3)
-
Alex Balashov -
Daniel-Constantin Mierla -
Henning Westerholt