class ActiveRecord::Migration

are in a Migration with self.disable_ddl_transaction!.
Remember that you can still open your own transactions, even if you
end
end
execute “ALTER TYPE model_size ADD VALUE ‘new_value’”
def up
disable_ddl_transaction!
class ChangeEnum < ActiveRecord::Migration[7.0]

you can turn the automatic transactions off.
can’t execute inside a transaction though, and for these situations
automatically be wrapped in a transaction. There are queries that you
If the database adapter supports DDL transactions, all migrations will
== Transactional Migrations
ActiveRecord::Migration::CommandRecorder.
For a list of commands that are reversible, please see
the migration is moving down.
ActiveRecord::IrreversibleMigration exception will be raised when
If a command cannot be reversed, an
as before.
and down in these cases, you should define the up and down methods
Some commands cannot be reversed. If you care to define how to move up
automatically figure out how to drop the table on the way down.
This migration will create the horses table for you on the way up, and
end
end
end
t.column :remind_at, :datetime
t.column :content, :text
create_table(:horses) do |t|
def change
class TenderloveMigration < ActiveRecord::Migration[7.0]

migration like this:
To define a reversible migration, define the change method in your
how to execute the down commands for you.
You simply supply the up logic, and the Migration system figures out
Reversible migrations are migrations that know how to go down for you.
== Reversible Migrations
In application.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
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.all.each do |p|
say_with_time “Updating salaries…” do
…
def 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.all.each do |p|
Person.reset_column_information
add_column :people, :salary, :integer
def up
class AddPeopleSalary < ActiveRecord::Migration[7.0]

latest column data from after the new column was added. Example:
Base#reset_column_information in order to ensure that the model has the
immediately after. In that case, you’ll need to make a call to
Sometimes you’ll want to add a column in a migration and populate it
== Using a model after changing its table
end
end
execute “ALTER TABLE ‘pages_linked_pages` DROP INDEX `page_id_linked_page_id`”
def down
end
execute “ALTER TABLE `pages_linked_pages` ADD UNIQUE `page_id_linked_page_id` (`page_id`,`linked_page_id`)”
def up
class MakeJoinUnique < ActiveRecord::Migration[7.0]

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 down
end
remove_column :items, :completed_items_count
remove_column :items, :incomplete_items_count
def up
class RemoveUnnecessaryItemAttributes < ActiveRecord::Migration[7.0]

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 down
end
Tag.all.each { |tag| tag.destroy if tag.pages.empty? }
def up
class RemoveEmptyTags < ActiveRecord::Migration[7.0]

Not all migrations change the schema. Some just fix the data:
== More examples
that step will fail and you’ll have some manual work to do.
If any of the migrations throw an ActiveRecord::IrreversibleMigration exception,
the latest two migrations.
wish to rollback last few migrations. bin/rails db:rollback STEP=2 will rollback
you wish to downgrade. Alternatively, you can also use the STEP option if you
bin/rails db:rollback 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 command, 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
bin/rails db:migrate. This will update the database by running all of the
To run migrations against the currently configured database, use
end
end
add_column :tablenames, :fieldname, :string
def change
class AddFieldnameToTablename < ActiveRecord::Migration[7.0]
This will generate the file timestamp_add_fieldname_to_tablename.rb, which will look like this:
bin/rails generate migration add_fieldname_to_tablename fieldname:string
There is a special syntactic shortcut to generate migrations that add fields to a table.
UTC formatted date and time that the migration was generated.
in the db/migrate/ directory where timestamp is the
create an empty migration file timestamp_my_new_migration.rb
where MyNewMigration is the name of your migration. The generator will
bin/rails 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
exception in their down method.
Migrations of that kind should raise an ActiveRecord::IrreversibleMigration
Some transformations are destructive in a manner that cannot be reversed.
== Irreversible transformations
columns (created_at and updated_at) from the table definition.
* remove_timestamps(table_name, options): Removes the timestamp
reference(s) on table_name specified by ref_name.
* remove_reference(table_name, ref_name, options): Removes the
specified by index_name.
* remove_index(table_name, name: index_name): Removes the index
specified by column_names.
* remove_index(table_name, column: column_names): Removes the index
given foreign key from the table called table_name.
* remove_foreign_key(from_table, to_table = nil, **options): Removes the
columns from the table definition.
* remove_columns(table_name, *column_names): Removes the given
named column_name from the table called table_name.
* remove_column(table_name, column_name, type, options): Removes the column
specified by the given arguments.
* drop_join_table(table_1, table_2, options): Drops the join table
* drop_table(name): Drops the table called name.
=== Deletion
to new_name.
* rename_table(old_name, new_name): Renames the table called old_name
* rename_index(table_name, old_name, new_name): Renames an index.
a column but keeps the type and content.
* rename_column(table_name, column_name, new_column_name): Renames
can then add/remove columns, indexes, or foreign keys to it.
the table called name. It makes the table object available to a block that
* change_table(name, options): Allows to make column alterations to
details.
ActiveRecord::ConnectionAdapters::SchemaStatements#change_column_null for
indicates whether the value can be NULL. See
Sets or removes a NOT NULL constraint on column_name. The null flag
* change_column_null(table_name, column_name, null, default = nil):
as default_or_changes will make this change reversible in the migration.
table_name. Passing a hash containing :from and :to
Sets a default value for column_name defined by default_or_changes on
* change_column_default(table_name, column_name, default_or_changes):
the column to a different type using the same parameters as add_column.
* change_column(table_name, column_name, type, options): Changes
=== Modification
and updated_at) columns to table_name.
* add_timestamps(table_name, options): Adds timestamps (created_at
ActiveRecord::ConnectionAdapters::SchemaStatements#add_reference for details.
reference_name_id by default an integer. See
* add_reference(:table_name, :reference_name): Adds a new column
(e.g. { order: { name: :desc } }).
{ name: 'users_name_index', unique: true }) and :order
:name, :unique (e.g.
with the name of the column. Other options include
* add_index(table_name, column_names, options): Adds a new index
the referenced primary key.
foreign key. from_table is the table with the key column, to_table contains
* add_foreign_key(from_table, to_table, options): Adds a new
ActiveRecord::ConnectionAdapters::TableDefinition#column for details.
{ limit: 50, null: false }) – see
Other options include :limit and :null (e.g.
specified by passing an options hash like { default: 11 }.
:date, :binary, :boolean. A default value can be
:decimal, :datetime, :timestamp, :time,
:string, :text, :integer, :float,
named column_name specified to be one of the following types:
to the table called table_name
* add_column(table_name, column_name, type, options): Adds a new column
table definition.
is for fragments like “DEFAULT CHARSET=UTF-8” that are appended to the create
following the same format as add_column. See example above. The options hash
makes the table object available to a block that can then add columns to it,
* create_table(name, options): Creates a table called name and
details.
ActiveRecord::ConnectionAdapters::SchemaStatements#create_join_table for
arguments. See
table having its name as the lexical order of the first two
* create_join_table(table_1, table_2, options): Creates a join
=== Creation
== Available transformations
complete table schema in one block call.
also uses the more advanced create_table syntax where you can specify a
first row in it using the Active Record model that relies on the table. It
This migration first adds the system_settings table, then creates the very
end
end
drop_table :system_settings
def down
end
value: 1
label: ‘Use notice?’,
SystemSetting.create name: ‘notice’,
end
t.integer :position
t.string :type
t.text :value
t.string :label
t.string :name
create_table :system_settings do |t|
def up
class AddSystemSettings < ActiveRecord::Migration[7.0]

Example of a more complex migration that also needs to initialize data:
transformations.
but may also contain regular Ruby code for generating data needed for the
of both the migration specific methods like add_column and remove_column,
required to implement or remove the migration. These methods can consist
two methods up and down that describes the transformations
if you’re backing out of the migration. It shows how all migrations have
This migration will add a boolean flag to the accounts table and remove it
end
end
remove_column :accounts, :ssl_enabled
def down
end
add_column :accounts, :ssl_enabled, :boolean, default: true
def up
class AddSsl < ActiveRecord::Migration[7.0]

Example of a simple migration:
another database that might be one, two, or five versions behind.
that can be checked into version control systems and executed against
migrations, you can describe the transformations in self-contained classes
push that change to other developers and to the production server. With
a new feature work in your local database, but being unsure of how to
databases. It’s a solution to the common problem of adding a field to make
Migrations can manage the evolution of a schema used by several physical
= Active Record Migrations