def change migration rollback

Question

I'm new to rails and I've been playing lately with migrations in order to understand the concept. Sometimes, I made migrations, with the rather new change method, but also with up and down methods, and calling db:rollback didn't work. Therefore, I had to suppress those migrations, and reset my database.

Yet, I was thinking : is there a way of "testing" a migration to understand if the rollback call will work ? Because if we have a filled database, and we implement a rollback that can't be rollbacked, reseting the database could be a problem...

Answer 1

The intentions of migrations is to go forward. You only go back while in development, if something is wrong, but imho only immediately after doing the migration and when a migration is not done on some other computer.

So for instance I create a migration, migrate, see I made a typo, rollback, fix the migration and migrate again.

Now if in the meantime, my super-fast co-worker has already migrated his database with the old migration, he will never know I fixed the migration, so he will still have the typo (since redoing migrations does not change any schema-versions). So if that is the case, instead of fixing/editing old migrations, I prefer adding a new migration that will fix the old migration explicitly, instead of rolling back.

In team-environments, but also when having multiple deployment-platforms, this is the preferred way imho.

Answer 2

It can be tricky to put a lot of code in migrations. Personally I stick to only a few lines that modify the schema i.e only adding/dropping columns, changing column names/datatypes, and adding/dropping indexes.

This, I believe, is why Rails moved to the change API in migrations. As long as you stick to simple schema changes, you'll always be able to rollback without needing to test your migrations.