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:
This is not very dynamic - what have fixtures been invented for?!
Then I found the rake db:bootstrap task from
- Re-creates the whole schema by running all migrations using :force =>
true (as far as I see it).
- Loads all fixture files in db/bootstrap into the database (e.g.
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:
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
Thanks for your opinion and constructive feedback, further suggestions