*Development: (Before going live and before production even exists)
Occasionally I will end up with a development DB that is full of cruft
and I want to reset. So I drop the development DB and rebuild.
*Production: After months of development, I'm ready to put an app into
production, so I contract with a hosting site and build it from
Both of these scenarios are intended to be solved with db:schema:load.
That task isn't working for you because you're putting seed data into
migrations. In turn, you feel pain from db:schema:load because it
doesn't include your seed data. I think the problem here is seed data
in migrations, not migrations vs schema.
What both these scenarios have in common is that the ruby schema
dumper is inadequate (no DB-specific stuff supported) and the sql
schema dumper is also inadequate (no non-DDL available, such as seed
In my mind, this is a perfect case for SQL schema dumper. You have a
db-specific schema that uses tricks not accessible by the Ruby dumper.
If you split out the concern of seed data, I think a lot of your
problems go away.
Migrations work beautifully to address these problems
in a very Rails-like way (no plugin required!) and using syntax I've
already invested in. I can add an Admin user, a Guest user and their
authorizations and be able to use the app after rake db:migrate.
Again, I think this is a mistake and it was certainly not what
migrations were designed for. They lead to all the pains and problems
you're describing with migrations.
I fully realize that people are misusing migrations in this way
because they were missing a seed system and just grabbed something
that had the same vague outline. But I think the problem then is to
consider how to best do seeding. Not to twist migrations into a seed
It is unfortunate that such a great tool (migrations) can't also be
used to build the test DB. As it is now, I occasionally find my
migrations fail due to subtle DB-side changes or model changes. The
only way to keep them fresh is to manually rebuild a database from
time to time. But it sure would be nice if they could be used in the
day-to-day of building the test DB.
Again, this is a symptom of wanting to run migrations all the time and
thus needing to make sure they'll work for all eternity. I think
that's a waste of time and hard too. You might very well have old
migrations that depend on classes and methods that are no longer
around. I've seen some of the hoops that people jump through to keep
legacy behavior intact for migrations and it sure ain't pretty.
So in summary, what we need is a seed system as either a best
practice, plugin, or core (doubtful, it doesn't feel like a Most
People, Most of The Time concern) and stop trying to turn migrations
(or even fixtures) into a seed system.