Question

Currently, for each table in my database, I add columns in several steps (ie. I add columns by migrating new files on multiple occasions). This results in a large number of migration files (~50 or so?). This seems very un-DRY.

I end up with large “add-details_to” files mixed with single entry “add_(column_name)_to” files, making it difficult to tell which file was used to migrate which column.

Is there a way to DRY up the migration files so that I have a single migration file for each table?

For example, if I add multiple columns in a single migration, then decide I want to remove one of those columns, what is the best practice?

1) create a down migration for the one column I want to remove

2) rollback the entire multiple-column migration, then create a new up migration with only the columns I want.

I currently follow 1, but it seems to me that 2 would allow me to get rid of my initial mistake migration files, thereby avoiding the lots-of-migration-files-for-each-table problem.

Any thoughts would be appreciated!

Answer 1

I think in general it’s a good option to just let your migration files grow and just manage the growing requirements through tests. shoulda-matchers is a great tool for this.

I definitely do not like the idea of down migrations, especially after its up has been run on the server (few exceptions if the down is against the immediate migration). I would rather create another migration to do what would have been done in the down. Though, I will admit there are times down is the way to go.

But at the end this all depends on where you are in your app. If working on a feature locally and want to consolidate, I could see you doing that, where you are doing a db:migrate:redo till you get what you need on your current migration. However, once you push something up (especially to production) I’d add another migration.