I have a collumn in my model which is a :decimal, :precision-
10, :scale=>2 It needs to hold numbers
from 0 to 4294967295.
This is the output from inet_aton('xxx.xxx.xxx.xxx') in mysql. I NEED
to have an unsigned integer or else it MUST be big int for other, less
flexible databases.
The development migrations work great. The correct table is built and
the number range is fine.
However, if I try to use the test feature built into rails projects,
it creates a table in the name_test database with the :decimal column
turned into an :integer(10). Of course, the fixtures will not load
and I am hooped.
No one seems to have run across this? I even emailed Dave Thomas of
'Agile Web Development with Rails: Second Edition, 2nd Edition' fame.
He said he uses :decimal columns all the time and never has any
problems.
Maybe no one has tried to put a number like 2190349144 into a test
fixture.
I have a collumn in my model which is a :decimal, :precision-
10, :scale=>2 It needs to hold numbers
from 0 to 4294967295.
This is the output from inet_aton('xxx.xxx.xxx.xxx') in mysql.
Shouldn't we disregard the underlying 32-bits, and store IP address numbers in "dotted octet notation" as strings? If '192.168.2.100' was (literally) good enough for our grandparents, isn't it good enough for us?
The dotted decimal version as a string requires a lot of error
checking to eliminate invalid ip addresses. Also, it doesn't sort
well at all. Internally, most of the networking commands use the long
integer value (which you can test by going: "ping 174260237")and
seeing that it works fine but translates the number back to
'10.99.0.13'
No, I think there is a perfectly valid reason to want to store the ip
number as an integer.
(and I could possible be someone's grandfather!)