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?
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,
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!
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
On 04/03/2009 03:39 PM, Alex Balashov wrote:
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");
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.
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
On Friday 03 April 2009, Daniel-Constantin Mierla wrote:
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.
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
-
Alex Balashov -
Daniel-Constantin Mierla -
Henning Westerholt