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
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.
–
Starr H.
My blog: http://starrhorne.com
Check out my Helpdesk RailsKit: http://railskits.com/helpdesk/
On Mar 10, 2009, at 4:52 PM, Starr H. wrote:
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.
–
Starr H.
My blog: http://starrhorne.com
Check out my Helpdesk RailsKit: http://railskits.com/helpdesk/
Just create another migration that is the opposite of this one.
-Rob
Rob B. http://agileconsultingllc.com
[email protected]
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
On Mar 10, 5:02 pm, Rob B. [email protected]
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
On Mar 10, 2009, at 5:37 PM, elliottg wrote:
the one you no longer need or is it just a personal preference?
Starr H.
My blog:http://starrhorne.com
Check out my Helpdesk RailsKit:http://railskits.com/helpdesk/
Rob B. http://agileconsultingllc.com
[email protected]
+1 513-295-4739
Skype: rob.biedenharn
elliottg wrote:
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
–
Tomas Meinlschmidt, MS {MCT, MCP+I, MCSE, AER}, NetApp Filer/NetCache
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
–
Starr H.
My blog: http://starrhorne.com
Check out my Helpdesk RailsKit: http://railskits.com/helpdesk/