Is it bad form to change multiple tables in a single Rails migration file?

Question

I wrote a migration file with the following code:

class AddScheduleIdToPlayers < ActiveRecord::Migration
  def change
        add_column :players, :schedule_id, :integer
        add_column :schedules, :coach_id, :integer
  end
end

Is it bad form to not create two migration files, one for each change, or is this fine?

This SEEMED like my same question... but we want to add an "updated_by" field to nearly all of our models. Can we just do this in a single migration AddUpdatedByToMostObjects? — Alien Life Form, Mar 04 '15 at 19:51

Pointless One · Accepted Answer · 2012-11-12T19:41:31.923

You want to keep related changes together. For example, if you implement bidirectional relation and add columns/tables to suffice AR relations you want to keep those in one migration.

If changes in schema are not related to each other (parts of different features, for example) it's better to keep them in separate migrations.

I do a mental experiment when I'm not sure. I try to break up migration for the smallest possible pieces and then check if my feature still works if I take down only one of the pieces. If it is that piece is likely doesn't belong to this migration.

Yours look to me like it can be split into two migrations. It seem to be you have two features here. One is about adding schedules for players and another for adding coaches to schedules.

Is it bad form to change multiple tables in a single Rails migration file?

1 Answers1