# Migrations with corresponding fixtures? **URL:** \ **Category:** Rails\ **Created:** [March 29, 2007, 10:49pm UTC](https://www.ruby-forum.com/t/migrations-with-corresponding-fixtures/90559 "2007-03-29T22:49:05Z")\ **Posts on this page:** 2\ **Page:** 1
**Author:** ![josh](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/45deac/32.png) [@josh](https://www.ruby-forum.com/u/josh)\ **Post date:** [March 29, 2007, 10:49pm UTC](https://www.ruby-forum.com/t/migrations-with-corresponding-fixtures/90559/1 "2007-03-29T22:49:05Z")
Hi all In my migrations I often like to create some basic model data that will be needed in the application (e.g. a list of common countries). Till now I hard-coded them directly into the migration scripts: Country.create!(…) This is not very dynamic - what have fixtures been invented for?! Then I found the rake db:bootstrap task from [RailsNotes — The Ruby on Rails guides you wished you had.](http://www.railsweenie.com/forums/2/topics/778) which 1. Re-creates the whole schema by running all migrations using :force =\> true (as far as I see it). 2. Loads all fixture files in db/bootstrap into the database (e.g. countries.yml). This is quite cool, but it does only allow me to migrate to the latest migration schema, so I’d like to go some steps further. What I want is a fixtures-file-schema based on migration numbers, not on model names. So 001\_add\_some\_basic\_countries.yml will be loaded after the migration 001\_xxx.rb is run. This would also allow to migrate back and forth to a specific state, not only to the latest schema version what rake db:bootstrap does. It should be possible, too, to create more than one fixture file per migration number, e.g. 002\_add\_some\_basic\_smurfs and 002\_add\_some\_more\_countries which both should be run after migration 002 was executed. Even better would be a directory structure that allows to create specific fixtures for each environment: db/migration/fixtures/development/001\_some\_test\_countries.rb db/migration/fixtures/development/002\_some\_smurfs\_that\_dont\_really\_exist.rb db/migration/fixtures/development/002\_some\_more\_countries.rb db/migration/fixtures/production/001\_basically\_needed\_countries.rb db/migration/fixtures/production/002\_really\_existing\_smurfs.rb So in the development database I maybe can have some test users (or smurfs 😉 ) with which I can test my features etc. But in production mode these users would be superflously, so there I would only add a God Administrator smurf for example. I’d like to enhance the rake db:migrate task so it fits my need. Anybody sees problems with the existing sense of how to use migrations or what migrations are really meant for? Is this a good idea, generally? If so, I will try to implement this behavior and release it as a plugin in some time… 🙂 Thanks for your opinion and constructive feedback, further suggestions are welcome! Josh ---
**Author:** ![josh](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/45deac/32.png) [@josh](https://www.ruby-forum.com/u/josh)\ **Post date:** [March 30, 2007, 7:52am UTC](https://www.ruby-forum.com/t/migrations-with-corresponding-fixtures/90559/2 "2007-03-30T07:52:57Z")
Hi Josh / List Did you ever get anywhere with this ? I have an existing db and I want to utilise migrations. I ignored them initially as I couldn’t (and still can’t) find a way to dump the existing DATA into the schema.rb ? How have others approached this ? I guess i can dump all existing data to yaml or something (links below are broken) but I really wanted to keep the data AND the defintions close together in the migrations files as they are dependent. It seems like such an obvious oversight that I am sure I am missing something ! Any thoughts out there ? Cheers Matt On Mar 30, 6:49 am, Joshua M. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)