Closed taai closed 12 years ago
There are two possible solutions that I can think of right now although I am sure there may be other solutions as well. Nonetheless, I am thinking that maybe it makes sense to create a new field class for big integers, which would utilize maybe Pear's Math_BigInteger class.
The other solution (or temporary workaround) is to use the String field class. Although this won't necessarily provide validation, it would allow you to read and write to the database.
I made a modified version of the DB_ORM_Field_Integer
: https://gist.github.com/3215176
What it does is when possible, use integers, but if system doesn't support 8byte integers and the value exceeds the range of 4byte integers, it uses strings.
This is workaround for systems that doesn't support 8byte integers. And if you are using only 4byte integers or your system supports 8byte integers, it will make no difference. Also, if the integer will be in the range between -2147483648 and 2147483647, it will be converted to ineger.
Crazy, right?! :)
So, what do you think about this solution? I could make a pull request or you can just pull the code from gist. Tell me.
Just merged these changes into Leap.
Support for 8 byte integer is needed!
As for now there is upper_bound set to maximum 4 byte integer value (2147483647):
Event if I do set
max_length
to 19 (not 10 or 11 as in examples), theupper_bound
still is 2147483647, not 9223372036854775807.Of course, you have to keep in mind that bigint is supported only by 64bit systems, but there should be a solution!
Possible solutions: Throw an exception
Or leave value as string, if
max_length
is set to be larger than 10.Update As I can see in the code, that
upper_bound
is a problem only for validation and the values will be converted to 8 byte integers (if system supports that), because nothing more thanintval()
function is used.Any comments/ideas?