Our project is currently running Rails 2.0, and I am concerned about
the use of timestamps in migration file names in Rails 2.1. We use
migrations a lot, for both table structure changes and application
data changes, and it can happen that the order in which the migrations
are run matters. Developers are required to update their area to get
the latest changes before checking in, and it frequently happens that
a migration file needs to be renamed prior to check in. But, that is
okay, because it means that the developer wanting to check in the
migration will first have to make sure (by running tests) that the
renumbered migration will still work after the other migrations have
been run. In this way, all the developers have to run the migrations
in the same order.
In the new migration system with timestamps, rake db:migrate just runs
whatever migrations haven’t been run yet. If developer A checks in a
migration, and then developer B does an update before checking in his
migration, B will end up getting A’s migration run after his (which
might affect the outcome of the tests) and after developer A does an
update, A will get B’s migration run last. If the order matters, A’s
database will not be the same as B’s, even though the areas of both
will appear up to date.
This is not a good thing. Yes, conflicts in migration numbers are an
annoyance, but they are an important annoyance, because they force you
to make sure your changes are compatible with ones that are already
checked in.
Is there a configuration option to turn this 2.1 feature off?
–Paul