Laravel create migration file in specific folder

rename_column :table, :old_column, :new_column

You'll probably want to create a separate migration to do this. (Rename FixColumnName as you will.):

script/generate migration FixColumnName
# creates  db/migrate/xxxxxxxxxx_fix_column_name.rb

Then edit the migration to do your will:

# db/migrate/xxxxxxxxxx_fix_column_name.rb
class FixColumnName < ActiveRecord::Migration
  def self.up
    rename_column :table_name, :old_column, :new_column
  end

  def self.down
    # rename back if you need or do something else or do nothing
  end
end

For Rails 3.1 use:

While, the up and down methods still apply, Rails 3.1 receives a change method that "knows how to migrate your database and reverse it when the migration is rolled back without the need to write a separate down method".

See "Active Record Migrations" for more information.

rails g migration FixColumnName

class FixColumnName < ActiveRecord::Migration
  def change
    rename_column :table_name, :old_column, :new_column
  end
end

If you happen to have a whole bunch of columns to rename, or something that would have required repeating the table name over and over again:

rename_column :table_name, :old_column1, :new_column1
rename_column :table_name, :old_column2, :new_column2
...

You could use change_table to keep things a little neater:

class FixColumnNames < ActiveRecord::Migration
  def change
    change_table :table_name do |t|
      t.rename :old_column1, :new_column1
      t.rename :old_column2, :new_column2
      ...
    end
  end
end

Then just db:migrate as usual or however you go about your business.

For Rails 4:

While creating a Migration for renaming a column, Rails 4 generates a change method instead of up and down as mentioned in the above section. The generated change method is:

$ > rails g migration ChangeColumnName

which will create a migration file similar to:

class ChangeColumnName < ActiveRecord::Migration
  def change
    rename_column :table_name, :old_column, :new_column
  end
end

You need to figure out the number of the migration just before the one you want to roll back.

Your app should have a migrations directory, with files in it named like

0000_initial.py
0001_added_some_fields.py
0002_added_some_more_fields.py
0003_deleted_some_stuff.py

Normally, when you run ./manage.py migrate your_app, South runs all new migrations, in order. (It looks at the database tables to decide which ones are 'new').

However, you can also specify any migration by number, and South will migrate your database, either forward or backward, to take it to that point. So, with the example files above, if you have already migrated up to 0003, and you wanted to run 0003 in reverse (undoing it, effectively), you would run

./manage.py migrate your_app 0002

South would look at the database, realise that it has run 0003 already, and determine that it has to run the reverse migration for 0003 in order to get back to 0002.