please read this
http://code.google.com/p/yii/issues/detail?id=3085
and this
http://code.google.com/p/yii/issues/detail?id=3087
And say me please - It’s only I and another man think this behavior is not correct?
please read this
http://code.google.com/p/yii/issues/detail?id=3085
and this
http://code.google.com/p/yii/issues/detail?id=3087
And say me please - It’s only I and another man think this behavior is not correct?
It’s a limitation of the PHP language, on a 32 bit system an int(10) unsigned MySQL datatype will not fit in a PHP int. It will overflow into a float but on a 64 bit system it wont overflow. 2147483647 is the maximum value an int in PHP can represent on a 32 bit system. The maximum value of a int(10) unsigned is 9999999999. Unless Yii is going to limit itself to 64 bit platforms then it’s much safer to use a string just so anything you are doing is consistent across any target platform.
I’have tried to insert 9999999999 into int(10) unsigned field
Do you know what I get in select query?
4294967295 - as I expected
You can check!
Why int(9) unsigned is represented as string?
Also rule length<=10 can validate any string with 10 characters length.
The form after submitting will not show any errors.
So why Yii does not check PHP_INT_SIZE before generating the models?
Ok yeah, there is absolutely no reason to represent an int(9) unsigned as a in string PHP, it’s late here, I misread the ticket. I agree with you on the int(9) unsigned.
No, this is a bad idea, what if I generate the models on a 64 development system and more them to a legacy 32 bit live server? What if I relied on the datatype being int?
I know my example is stupid (dev systems should emulate live systems) but I think it is good to build a rock solid framework, means more Yii jobs in the years to come
yeah
you are right
Thanks phtamas, I did not know this, I have used MySQL for almost twelve years. So you’d think I would have noticed this behaviour, as much as I would love to bash MySQL here, it makes sense that it only for display purposes, since it’s not ANSI spec.