In Chad Fowler’s list of 20 Rails Development No-No’s, he included “seed data in migrations” as a bad thing.

I can definitely say that I do this. Almost every project has some. On my last big rails project, there was seed data in the migrations.

We put seed data into migrations for several reasons. It was convenient. Seed data often went with other DB changes, so we just put it all in one place. Also, we didn’t have a lot of time to figure out where to put the seed data, and the “best practice” that I was aware of (“just use schema.rb”) was quite inadequate: it didn’t push in the seed data that the application needed in order to function; and it would have destroyed all of the application’s data on upgrades.

A commenter added:

we pull this out into a separate rake task (load seed data). This allows the seed data to adapt as the project adapts. If you have a lookup table with several sentinel values, then when you want to update that list, you need to be aware that you added them in a previous migration.

Another commenter says:

About using seed data in migrations, I think it’s Ok as long as you useSQL to load data into the database and don’t rely on models cause’ they will eventually change or be removed from the project.

On my last big rails project, we used the models to load seed data sometimes, and we used fixtures other times. The problem with fixtures is that they’re not designed for seed data, so it’s a bit of a pain to configure them correctly, and if you reload them in a later migration, you have to tell the fixtures that it’s OK to load data into the same table again.  When we used the model classes, we usually had to reset the column information before we used them, or create temp classes that were just used in the migrations. One of the approaches pointed out by these commenters would have been helpful.