class ActiveRecord::Migration

In environment.rb.
config.active_record.timestamped_migrations = false
off by setting:
If you’d prefer to use numeric prefixes, you can turn timestamped migrations
The prefix is a generation timestamp (in UTC).
20080717013526_your_migration_name.rb
By default, Rails generates migrations that look like:
== Timestamped Migrations
when migrating down, never-applied “interleaved” migrations will be skipped.
never-applied “interleaved” migrations will be automatically applied, and
lower than the current schema version: when migrating up, those
As a result, it is now possible to add migration files that are numbered
contains the version numbers of all the migrations applied.
(automatically) replaced by the schema_migrations table, which
Starting with Rails 2.1, the schema_info table is
version of the schema as of the last applied migration.
schema_info when using migrations. This table contained the
Rails versions 2.0 and prior used to create a table called
== About the schema_migrations table
benchmark for the block when the block completes.
The phrase “Updating salaries…” would then be printed, along with the
end
…
end
end
p.update_attribute :salary, SalaryCalculator.compute(p)
Person.find(:all).each do |p|
say_with_time “Updating salaries…” do
…
def self.up
method:
You can also insert your own messages and benchmarks by using the say_with_time
You can quiet them down by setting ActiveRecord::Migration.verbose = false.
long each step took.
them to the console as they happen, along with benchmarks describing how
By default, migrations will describe the actions they are taking, writing
== Controlling verbosity
end
end
end
p.update_attribute :salary, SalaryCalculator.compute(p)
Person.find(:all).each do |p|
Person.reset_column_information
add_column :people, :salary, :integer
def self.up
class AddPeopleSalary < ActiveRecord::Migration
after the new column was added. Example:
to make a call to Base#reset_column_information in order to ensure that the model has the latest column data from
Sometimes you’ll want to add a column in a migration and populate it immediately after. In that case, you’ll need
== Using a model after changing its table
end
end
execute “ALTER TABLE ‘pages_linked_pages` DROP INDEX `page_id_linked_page_id`”
def self.down
end
execute “ALTER TABLE `pages_linked_pages` ADD UNIQUE `page_id_linked_page_id` (`page_id`,`linked_page_id`)”
def self.up
class MakeJoinUnique < ActiveRecord::Migration
And sometimes you need to do something in SQL not abstracted directly by migrations:
end
end
add_column :items, :completed_items_count
add_column :items, :incomplete_items_count
def self.down
end
remove_column :items, :completed_items_count
remove_column :items, :incomplete_items_count
def self.up
class RemoveUnnecessaryItemAttributes < ActiveRecord::Migration
Others remove columns when they migrate up instead of down:
end
end
raise ActiveRecord::IrreversibleMigration, “Can’t recover the deleted tags”
# not much we can do to restore deleted data
def self.down
end
Tag.find(:all).each { |tag| tag.destroy if tag.pages.empty? }
def self.up
class RemoveEmptyTags < ActiveRecord::Migration
Not all migrations change the schema. Some just fix the data:
== More examples
SQL Server, Sybase, and Oracle (all supported databases except DB2).
Migrations are currently supported in MySQL, PostgreSQL, SQLite,
== Database support
have some manual work to do.
ActiveRecord::IrreversibleMigration exception, that step will fail and you’ll
you wish to downgrade. If any of the migrations throw an
rake db:migrate VERSION=X where X is the version to which
To roll the database back to a previous migration version, use
to match the structure of your database.
invoke the db:schema:dump task, which will update your db/schema.rb file
(see “About the schema_migrations table” section below) if missing. It will also
pending migrations, creating the schema_migrations table
rake db:migrate. This will update the database by running all of the
To run migrations against the currently configured database, use
end
end
remove_column :tablenames, :fieldname
def self.down
end
add_column :tablenames, :fieldname, :string
def self.up
class AddFieldnameToTablename < ActiveRecord::Migration
This will generate the file nnn_add_fieldname_to_tablename, which will look like this:
script/generate migration add_fieldname_to_tablename fieldname:string
There is a special syntactic shortcut to generate migrations that add fields to a table.
MyNewMigration.
You may then edit the self.up and self.down methods of
directory where nnn is the next largest migration number.
create an empty migration file nnn_my_new_migration.rb in the db/migrate/
where MyNewMigration is the name of your migration. The generator will
script/generate migration MyNewMigration
To generate a new migration, you can use
The Rails package has several tools to help create and apply migrations.
== Running migrations from within Rails
an ActiveRecord::IrreversibleMigration exception in their down method.
Some transformations are destructive in a manner that cannot be reversed. Migrations of that kind should raise
== Irreversible transformations
* remove_index(table_name, index_name): Removes the index specified by index_name.
:name and :unique (e.g. { :name => "users_name_index", :unique => true }).
* add_index(table_name, column_names, options): Adds a new index with the name of the column. Other options include
* remove_column(table_name, column_name): Removes the column named column_name from the table called table_name.
parameters as add_column.
* change_column(table_name, column_name, type, options): Changes the column to a different type using the same
* rename_column(table_name, column_name, new_column_name): Renames a column but keeps the type and content.
– see ActiveRecord::ConnectionAdapters::TableDefinition#column for details.
options hash like { :default => 11 }. Other options include :limit and :null (e.g. { :limit => 50, :null => false })
:date, :binary, :boolean. A default value can be specified by passing an
:string, :text, :integer, :float, :decimal, :datetime, :timestamp, :time,
named column_name specified to be one of the following types:
* add_column(table_name, column_name, type, options): Adds a new column to the table called table_name
* rename_table(old_name, new_name): Renames the table called old_name to new_name.
* drop_table(name): Drops the table called name.
fragments like “DEFAULT CHARSET=UTF-8” that are appended to the create table definition.
that can then add columns to it, following the same format as add_column. See example above. The options hash is for
* create_table(name, options) Creates a table called name and makes the table object available to a block
== Available transformations
in one block call.
that relies on the table. It also uses the more advanced create_table syntax where you can specify a complete table schema
This migration first adds the system_settings table, then creates the very first row in it using the Active Record model
end
end
drop_table :system_settings
def self.down
end
SystemSetting.create :name => “notice”, :label => “Use notice?”, :value => 1
end
t.integer :position
t.string :type
t.text :value
t.string :label
t.string :name
create_table :system_settings do |t|
def self.up
class AddSystemSettings < ActiveRecord::Migration
Example of a more complex migration that also needs to initialize data:
but may also contain regular Ruby code for generating data needed for the transformations.
or remove the migration. These methods can consist of both the migration specific methods like add_column and remove_column,
It shows how all migrations have two class methods up and down that describes the transformations required to implement
This migration will add a boolean flag to the accounts table and remove it if you’re backing out of the migration.
end
end
remove_column :accounts, :ssl_enabled
def self.down
end
add_column :accounts, :ssl_enabled, :boolean, :default => 1
def self.up
class AddSsl < ActiveRecord::Migration
Example of a simple migration:
might be one, two, or five versions behind.
in self-contained classes that can be checked into version control systems and executed against another database that
push that change to other developers and to the production server. With migrations, you can describe the transformations
to the common problem of adding a field to make a new feature work in your local database, but being unsure of how to
Migrations can manage the evolution of a schema used by several physical databases. It’s a solution