[PHP] MySQL BigInt in ResultSet given as String

Hej guys,

I’m sorry I don’t really know where does it come from, I’m stuck with that for hours now, when I get a ResultSet object, the field’s type in my MySQL MyISAM DB is BigInt but php/haxe gives me a String instead.
Has anyone met something like that ? Is it linked to MysqliFieldInfo.type (that gives me “8” here ?)
Does anyone have a hint for me please ?

AFAIR php gets all values from mysql as strings. It’s responsibility of ORM to convert them to correct types. For example here’s the code which does that in Haxe: haxe/Mysql.hx at fd994e64a87c05a78fa27a4b7c8c12606fbfb691 · HaxeFoundation/haxe · GitHub

Most of the time BIGINT is used for id numbers.You just pass them around without midification. String representation is perfectly fine for such use case.

What’s the actual issue? Does such representation of BIGINT prevent you from doing something?

Thanks Aleksandr !

Yes but I found this function in php/_std/sys/db/Mysql.hx :

function correctType(value:String, type:Int):Scalar {
		if (value == null)
			return null;
		if (type == Const.MYSQLI_TYPE_BIT || type == Const.MYSQLI_TYPE_TINY || type == Const.MYSQLI_TYPE_SHORT || type == Const.MYSQLI_TYPE_LONG
			|| type == Const.MYSQLI_TYPE_INT24 || type == Const.MYSQLI_TYPE_CHAR) {
			return Syntax.int(value);
		}
		if (type == Const.MYSQLI_TYPE_DECIMAL
			|| type == Const.MYSQLI_TYPE_NEWDECIMAL
			|| type == Const.MYSQLI_TYPE_FLOAT
			|| type == Const.MYSQLI_TYPE_DOUBLE) {
			return Syntax.float(value);
		}
		return value;
	}

So at this point i.e. integers become integers but BigInt bypass all these type tests and results in String.
is it normal ?

In fact at the top level I use record_macros, but I dig a little and come into this function above, so at the end I don’t know if it should be processed by record_macros or upper in this function.
I use BigInt for an amount field, and somewhere I do a comparaison so it results in false because it comapres a haxe Float with a String…

I think this function miss MYSQLI_TYPE_LONGLONG comparaison in its test, right ?
(PHP: Predefined Constants - Manual)

Yes I added this so it ends with this function so I get a Float and it works fine now:

function correctType(value:String, type:Int):Scalar {
		if (value == null)
			return null;
		if (type == Const.MYSQLI_TYPE_BIT || type == Const.MYSQLI_TYPE_TINY || type == Const.MYSQLI_TYPE_SHORT || type == Const.MYSQLI_TYPE_LONG
			|| type == Const.MYSQLI_TYPE_INT24 || type == Const.MYSQLI_TYPE_CHAR) {
			return Syntax.int(value);
		}
		if (type == Const.MYSQLI_TYPE_DECIMAL
			|| type == Const.MYSQLI_TYPE_NEWDECIMAL
			|| type == Const.MYSQLI_TYPE_FLOAT
			|| type == Const.MYSQLI_TYPE_DOUBLE
			|| type == Const.MYSQLI_TYPE_LONGLONG) {
			return Syntax.float(value);
		}
		return value;
	}

I guess 32bit servers gone extinct nowadays, so it’s probably ok to do that.
But you should move it to previous if because it’s an integer value.

Hi Aleksandr,
I set it as Float because in record-macros typedef SBigInt = Null<Float> , do you think it should be changed for Int as well in record-macros please ?

And at the end, do you want I write an Issue in Haxe github for that, do you plan to add that in Haxe distrib or no ?

Yes. Because semantically it’s an integer. Otherwise you could accidentally assign a real float value in it and Haxe compiler would not error out.

Yes, please. We need to track 32/64-related issues. But I doubt we should change this in std for now.