Change BIGINT native PHP type back to int

[db-mobile]

Originally BIGINT was mapped to PHP native type int back in 2005. This was changed to string in revision 56f6a84.

Apparently 32-bit PHP types were incapable of storing the full range of BIGINT without running out of bounds. This should not be an issue in times of 64 bit and the minimum required version of PHP being 7.4 for Propel2.

This solution however preserves the old behavior on 32 bit systems.

[PhilinTv]

@db-mobile it's a good idea!

But there is a BC-break to the current 64x systems: they currently run strings and will get inconsistent BIGINT definition.
If you agree, it's a major change, could you please provide an optional enablement (BC) of the correct BIGINT?

[hsegnitz]

Ahoi,

if I'm not mistaken, PHP_INT_MAX on 64bit is 63bit + 1bit for the sign.
At least with MySQL "BIGINT UNSIGNED" uses that extra bit to extend the range upwards to allow numbers up to (2x PHP_INT_MAX) +1.
That means it would still be out of bounds for PHP as PHP Integers are always signed. I guess they would be cast to float then and lose precision.

[PhilinTv]

@hsegnitz you are right, we would also have a stability issue here for >2^63 ints.
However statistically there are no practical use cases that would get to this issue (metrics in IoT 1 event/ns = 292 years) and there are not ORMs that support unsigned bigint without custom conversion.

If there are no contra, I'd proceed with the change and notify about the 2^63 limit in documentation.
If it will be once relevant we can introduce a custom conversion for bigint as well. :)