Unit Tests do not migrate correctly

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.

Is there a fix for this?

It could be a problem with the schema dumper. In your environment.rb
have your tried changing the schema dumper from :ruby to :sql ?

Fred

You ran the migrations against your development db only I'm guessing.

Maybe rake db:test:prepare would fix this.

Alan9608 wrote:

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?

Thanks Frederick. That solved the test migration.

Thanks Rick. Frederick Cheung came up with the solution.

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!)