Managing migrations

rubyonrails-talk
1

I have a migration "x" that when it runs self.up it adds a new column to a table, and of course when self. down is run it deletes said table...

After I ran this migration I continued to work and in the process added a couple other migrations. After a while I realized that the column migration "x" created was a mistake and I no longer need it. So I ran rake db:migrate:down VERSION=x to delete the column. It worked great, but the problem is whenever I added another migration than ran rake db:migrate, migration "x" ran its self.up again and the column I no longer wanted was built back into my schema.

What the best way to handle something like this? Is it insane to just manually delete a migration file to prevent it from ever being ran again?

Thanks heaps, Elliott

2

What the best way to handle something like this? Is it insane to just manually delete a migration file to prevent it from ever being ran again?

Yeah, you can delete it. It's just a file.

3

Just create another migration that is the opposite of this one.

-Rob

Rob Biedenharn http://agileconsultingllc.com Rob@AgileConsultingLLC.com

4

So, create another migration that would undo what the old problem one does... Would that be considered a better practice over just deleting the one you no longer need or is it just a personal preference?

Thanks

5

So, create another migration that would undo what the old problem one does... Would that be considered a better practice over just deleting the one you no longer need or is it just a personal preference?

If you're in production, or far along in development it's probably best to create the extra migration.

If you're early in development, I'd just delete it to keep things clean.

SH

6

Thanks for the insight.

EG

7

The answer gets a bit more strict if there are multiple developers
involved. In that case, I'd always create the extra migration.

However, if you never checked the migration into source control, then
migrate:down, change it and migrate:up (or just delete it), is the
right thing to do even in a multi-user development environment.

-Rob

8

elliottg wrote:

I have a migration "x" that when it runs self.up it adds a new column to a table, and of course when self. down is run it deletes said table...

After I ran this migration I continued to work and in the process added a couple other migrations. After a while I realized that the column migration "x" created was a mistake and I no longer need it. So I ran rake db:migrate:down VERSION=x to delete the column. It worked great, but the problem is whenever I added another migration than ran rake db:migrate, migration "x" ran its self.up again and the column I no longer wanted was built back into my schema.

What the best way to handle something like this? Is it insane to just manually delete a migration file to prevent it from ever being ran again?

Thanks heaps, Elliott

I'm just editing migration file to add/remove columns and don't create new migrations to the same table until first branch/release version... then add new migration file (for the same table, if needed) and continue to add/remove columns until next branch/release version commit.

It's silly to add migration file for each column change within one version...

tom