mysql - Rails: does minitest use schema.rb to recreate the test schema? -

i trying bring legacy rails system more current standards having problems getting test database reflect state of schema.rb plus changes made via migrations.

tl;dr running rake minitest:all invoke same code rake db:schema:load?

environment

• rails 3.2.20
• ruby 1.9.3
• minitest gem 4.6.2
• minitest-rails 0.5.2
• mysql 5.1
• local os x, test , production linux

original system state

the system set people not software engineers, didn't know rails, etc. several mysql-specific types added (e.g. unsigned int) not supported using rails' migrations , schema.rb. system used structure.sql , sloppy how kept updated, checked in git, , on.

further, @ point later, decided replace of usual numeric, auto-incrementing primary key id fields varchar containing self-generated guid. field name still id new datatype.

but of hundreds of tests (they did write lot of tests) had been written reference fixture instances based on ids, not fixture names , there dependencies between fixtures, etc. rather updating tests, decided stick old schema (with numeric id) tests, , use new 1 (with varchar guids in id) production.

op takes deep breath...

databases various environments out of sync, there hundreds of migrations, stopped working because "development" database shared , ... know, mess.

i trying fix of this, , move postgresql.

what have done

i dumped schema production database locally using rails_env=production rake db:structure:dump -- produced authoritative structure.sql. created fresh development database, , loaded schema using rake db:structure:load -- compared production , development schemas , same, mysql-specific unsigned int mentioned above.

i move using schema.rb 2 reasons. first, system not depend on mysql. second, when using structure.sql check in file has auto-increment values, db settings , other characteristics of whatever machine ran recent db:migrate. can create issues prefer avoid.

so, locally changed configuration setting :sqlto use :ruby setting produce schema.rb.

but schema.rb doesn't idea of id field being turned varchar -- have made sure of models use declare self.primary_key = :id, created new migration replace of old ones, "rollup migration", content new schema.rb, modified in several ways.

in particular, id field guid varchar set table (from within migration):

class rolledupstateasof20150403 < activerecord::migration    def      # ... other table definitions in system      create_table "users", :id => false, :force => false |t|       t.string   "id", :limit => 36, :default => "", :null => false       t.string   "login"       # , other user fields     end     execute("alter table users add primary key (id);")      #...   end    def down     raise activerecord::irreversiblemigration   end end 

so:

• :id => false prevent migration creating normal id
• :force => false make sure migration doesn't nuke production db
• t.string "id" size , other primary-key-like settings
• execute(alter table ...) @ end declare id primary key

every time create new migration in future, schema.rb updated -- won't accurate (until rid of wacky id fields later). migrations honor normal rails practices moving forward.

once production, staging, development , other databases in sync well.

except when test.

so why isn't working when run minitest?

i running tests minitest follows:

rails_env=test rake db:drop rails_env=test rake db:create rails_env=test rake db:migrate rails_env=test rake minitest:all 

but start seeing errors, , errors due id columns being defined int rather varchar.

if inspect schema before running minitest (after drop, create, , magic migration), correct: funky primary keys varchar desired.

but somewhere during test looks schema getting changed rails standard. can go , inspect schema id columns int.

presumably schema being produced actual schema.rb.

is normal/expected behavior? suggestions how achieve goals, simply:

• migrations work again
• development, test, staging, production databases structurally same
• i need live crazy varchar guid-based id fields now
• i prefer not use structure.sql if possible

ok, believe following true: minitest, or test do run db:schema:load ... or db:structure:load when running in rails_env=test -- can observed running either rake test --trace or rake minitest:all --trace.

so, because schema.rb not recreate database due bizarre use of varchar instead of int field named id... had revert using structure.sql instead.

the rest of solution, including having hand-modified version of schema.rb added first "rollup" migration works nicely, , subsequent migrations fine. time in future i'll turn ids natural form; now, suitable solution, if not elegant.