1 Migration Overview
Migrations are a convenient way to evolve your database schema over time in a reproducible way. They use a Ruby DSL so that you don't have to write SQL by hand, allowing your schema and changes to be database independent. We recommend that you read the guides for Active Record Basics and the Active Record Associations to learn more about some of the concepts mentioned here.
You can think of each migration as being a new 'version' of the database. A schema starts off with nothing in it, and each migration modifies it to add or remove tables, columns, or indexes. Active Record knows how to update your schema along this timeline, bringing it from whatever point it is in the history to the latest version. Read more about how Rails knows which migration in the timeline to run.
Active Record updates your db/schema.rb
file to match the up-to-date structure
of your database. Here's an example of a migration:
# db/migrate/20240502100843_create_products.rb
class CreateProducts < ActiveRecord::Migration[7.2]
def change
create_table :products do |t|
t.string :name
t.text :description
t.timestamps
end
end
end
This migration adds a table called products
with a string column called name
and a text column called description
. A primary key column called id
will
also be added implicitly, as it's the default primary key for all Active Record
models. The timestamps
macro adds two columns, created_at
and updated_at
.
These special columns are automatically managed by Active Record if they exist.
# db/schema.rb
ActiveRecord::Schema[7.2].define(version: 2024_05_02_100843) do
# These are extensions that must be enabled in order to support this database
enable_extension "plpgsql"
create_table "products", force: :cascade do |t|
t.string "name"
t.text "description"
t.datetime "created_at", null: false
t.datetime "updated_at", null: false
end
end
We define the change that we want to happen moving forward in time. Before this migration is run, there will be no table. After it is run, the table will exist. Active Record knows how to reverse this migration as well; if we roll this migration back, it will remove the table. Read more about rolling back migrations in the Rolling Back section.
After defining the change that we want to occur moving forward in time, it's essential to consider the reversibility of the migration. While Active Record can manage the forward progression of the migration, ensuring the creation of the table, the concept of reversibility becomes crucial. With reversible migrations, not only does the migration create the table when applied, but it also enables smooth rollback functionality. In case of reverting the migration above, Active Record intelligently handles the removal of the table, maintaining database consistency throughout the process. See the Reversing Migrations section for more details.
2 Generating Migration Files
2.1 Creating a Standalone Migration
Migrations are stored as files in the db/migrate
directory, one for each
migration class.
The name of the file is of the form YYYYMMDDHHMMSS_create_products.rb
, it
contains a UTC timestamp identifying the migration followed by an underscore
followed by the name of the migration. The name of the migration class
(CamelCased version) should match the latter part of the file name.
For example, 20240502100843_create_products.rb
should define class
CreateProducts
and 20240502101659_add_details_to_products.rb
should define
class AddDetailsToProducts
. Rails uses this timestamp to determine which
migration should be run and in what order, so if you're copying a migration from
another application or generating a file yourself, be aware of its position in
the order. You can read more about how the timestamps are used in the Rails
Migration Version Control section.
When generating a migration, Active Record automatically prepends the current timestamp to the file name of the migration. For example, running the command below will create an empty migration file whereby the filename is made up of a timestamp prepended to the underscored name of the migration.
$ bin/rails generate migration AddPartNumberToProducts
# db/migrate/20240502101659_add_part_number_to_products.rb
class AddPartNumberToProducts < ActiveRecord::Migration[7.2]
def change
end
end
The generator can do much more than prepend a timestamp to the file name. Based on naming conventions and additional (optional) arguments it can also start fleshing out the migration.
The following sections will cover the various ways you can create migrations based on conventions and additional arguments.
2.2 Creating a New Table
When you want to create a new table in your database, you can use a migration with the format "CreateXXX" followed by a list of column names and types. This will generate a migration file that sets up the table with the specified columns.
$ bin/rails generate migration CreateProducts name:string part_number:string
generates
class CreateProducts < ActiveRecord::Migration[7.2]
def change
create_table :products do |t|
t.string :name
t.string :part_number
t.timestamps
end
end
end
The generated file with its contents is just a starting point, and you can add
or remove from it as you see fit by editing the
db/migrate/YYYYMMDDHHMMSS_create_products.rb
file.
2.3 Adding Columns
When you want to add a new column to an existing table in your database, you can
use a migration with the format "AddColumnToTable" followed by a list of column
names and types. This will generate a migration file containing the appropriate
add_column
statements.
$ bin/rails generate migration AddPartNumberToProducts part_number:string
This will generate the following migration:
class AddPartNumberToProducts < ActiveRecord::Migration[7.2]
def change
add_column :products, :part_number, :string
end
end
If you'd like to add an index on the new column, you can do that as well.
$ bin/rails generate migration AddPartNumberToProducts part_number:string:index
This will generate the appropriate add_column
and add_index
statements:
class AddPartNumberToProducts < ActiveRecord::Migration[7.2]
def change
add_column :products, :part_number, :string
add_index :products, :part_number
end
end
You are not limited to one magically generated column. For example:
$ bin/rails generate migration AddDetailsToProducts part_number:string price:decimal
This will generate a schema migration which adds two additional columns to the
products
table.
class AddDetailsToProducts < ActiveRecord::Migration[7.2]
def change
add_column :products, :part_number, :string
add_column :products, :price, :decimal
end
end
2.4 Removing Columns
Similarly, if the migration name is of the form "RemoveColumnFromTable" and is
followed by a list of column names and types then a migration containing the
appropriate remove_column
statements will be created.
$ bin/rails generate migration RemovePartNumberFromProducts part_number:string
This will generate the appropriate remove_column
statements:
class RemovePartNumberFromProducts < ActiveRecord::Migration[7.2]
def change
remove_column :products, :part_number, :string
end
end
2.5 Creating Associations
Active Record associations are used to define relationships between different models in your application, allowing them to interact with each other through their relationships and making it easier to work with related data. To learn more about associations, you can refer to the Association Basics guide.
One common use case for associations is creating foreign key references between
tables. The generator accepts column types such as references
to facilitate
this process. References are a shorthand for creating columns,
indexes, foreign keys, or even polymorphic association columns.
For example,
$ bin/rails generate migration AddUserRefToProducts user:references
generates the following add_reference
call:
class AddUserRefToProducts < ActiveRecord::Migration[7.2]
def change
add_reference :products, :user, null: false, foreign_key: true
end
end
The above migration creates a foreign key called user_id
in the products
table, where user_id
is a reference to the id
column in the users
table.
It also creates an index for the user_id
column. The schema looks as follows:
create_table "products", force: :cascade do |t|
t.bigint "user_id", null: false
t.index ["user_id"], name: "index_products_on_user_id"
end
belongs_to
is an alias of references
, so the above could be alternatively
written as:
$ bin/rails generate migration AddUserRefToProducts user:belongs_to
generating a migration and schema that is the same as above.
There is also a generator which will produce join tables if JoinTable
is part
of the name:
$ bin/rails generate migration CreateJoinTableUserProduct user product
will produce the following migration:
class CreateJoinTableUserProduct < ActiveRecord::Migration[7.2]
def change
create_join_table :users, :products do |t|
# t.index [:user_id, :product_id]
# t.index [:product_id, :user_id]
end
end
end
2.6 Other Generators that Create Migrations
In addition to the migration
generator, the model
, resource
, and
scaffold
generators will create migrations appropriate for adding a new model.
This migration will already contain instructions for creating the relevant
table. If you tell Rails what columns you want, then statements for adding these
columns will also be created. For example, running:
$ bin/rails generate model Product name:string description:text
This will create a migration that looks like this:
class CreateProducts < ActiveRecord::Migration[7.2]
def change
create_table :products do |t|
t.string :name
t.text :description
t.timestamps
end
end
end
You can append as many column name/type pairs as you want.
2.7 Passing Modifiers
When generating migrations, you can pass commonly used type modifiers directly on the command line. These modifiers, enclosed by curly braces and following the field type, allow you to tailor the characteristics of your database columns without needing to manually edit the migration file afterward.
For instance, running:
$ bin/rails generate migration AddDetailsToProducts 'price:decimal{5,2}' supplier:references{polymorphic}
will produce a migration that looks like this
class AddDetailsToProducts < ActiveRecord::Migration[7.2]
def change
add_column :products, :price, :decimal, precision: 5, scale: 2
add_reference :products, :supplier, polymorphic: true
end
end
For further help with generators, run bin/rails generate --help
.
Alternatively, you can also run bin/rails generate model --help
or bin/rails
generate migration --help
for help with specific generators.
3 Updating Migrations
Once you have created your migration file using one of the generators from the
above section, you can update the generated
migration file in the db/migrate
folder to define further changes you want to
make to your database schema.
3.1 Creating a Table
The create_table
method is one of the most fundamental migration type, but
most of the time, will be generated for you from using a model, resource, or
scaffold generator. A typical use would be
create_table :products do |t|
t.string :name
end
This method creates a products
table with a column called name
.
3.1.1 Associations
If you're creating a table for a model that has an association, you can use the
:references
type to create the appropriate column type. For example:
create_table :products do |t|
t.references :category
end
This will create a category_id
column. Alternatively, you can use belongs_to
as an alias for references
:
create_table :products do |t|
t.belongs_to :category
end
You can also specify the column type and index creation using the
:polymorphic
option:
create_table :taggings do |t|
t.references :taggable, polymorphic: true
end
This will create taggable_id
, taggable_type
columns and the appropriate
indexes.
3.1.2 Primary Keys
By default, create_table
will implicitly create a primary key called id
for
you. You can change the name of the column with the :primary_key
option, like
below:
class CreateUsers < ActiveRecord::Migration[7.2]
def change
create_table :users, primary_key: "user_id" do |t|
t.string :username
t.string :email
t.timestamps
end
end
end
This will yield the following schema:
create_table "users", primary_key: "user_id", force: :cascade do |t|
t.string "username"
t.string "email"
t.datetime "created_at", precision: 6, null: false
t.datetime "updated_at", precision: 6, null: false
end
You can also pass an array to :primary_key
for a composite primary key. Read
more about composite primary keys.
class CreateUsers < ActiveRecord::Migration[7.2]
def change
create_table :users, primary_key: [:id, :name] do |t|
t.string :name
t.string :email
t.timestamps
end
end
end
If you don't want a primary key at all, you can pass the option id: false
.
class CreateUsers < ActiveRecord::Migration[7.2]
def change
create_table :users, id: false do |t|
t.string :username
t.string :email
t.timestamps
end
end
end
3.1.3 Database Options
If you need to pass database-specific options you can place an SQL fragment in
the :options
option. For example:
create_table :products, options: "ENGINE=BLACKHOLE" do |t|
t.string :name, null: false
end
This will append ENGINE=BLACKHOLE
to the SQL statement used to create the
table.
An index can be created on the columns created within the create_table
block
by passing index: true
or an options hash to the :index
option:
create_table :users do |t|
t.string :name, index: true
t.string :email, index: { unique: true, name: 'unique_emails' }
end
3.1.4 Comments
You can pass the :comment
option with any description for the table that will
be stored in the database itself and can be viewed with database administration
tools, such as MySQL Workbench or PgAdmin III. Comments can help team members to
better understand the data model and to generate documentation in applications
with large databases. Currently only the MySQL and PostgreSQL adapters support
comments.
class AddDetailsToProducts < ActiveRecord::Migration[7.2]
def change
add_column :products, :price, :decimal, precision: 8, scale: 2, comment: "The price of the product in USD"
add_column :products, :stock_quantity, :integer, comment: "The current stock quantity of the product"
end
end
3.2 Creating a Join Table
The migration method create_join_table
creates an HABTM (has and belongs
to many) join
table. A typical use would be:
create_join_table :products, :categories
This migration will create a categories_products
table with two columns called
category_id
and product_id
.
These columns have the option :null
set to false
by default, meaning that
you must provide a value in order to save a record to this table. This can
be overridden by specifying the :column_options
option:
create_join_table :products, :categories, column_options: { null: true }
By default, the name of the join table comes from the union of the first two
arguments provided to create_join_table, in lexical order. In this case,
the table would be named categories_products
.
The precedence between model names is calculated using the <=>
operator for String
. This means that if the strings are of different lengths,
and the strings are equal when compared up to the shortest length, then the
longer string is considered of higher lexical precedence than the shorter one.
For example, one would expect the tables "paper_boxes" and "papers" to generate
a join table name of "papers_paper_boxes" because of the length of the name
"paper_boxes", but it in fact generates a join table name of
"paper_boxes_papers" (because the underscore '_' is lexicographically less
than 's' in common encodings).
To customize the name of the table, provide a :table_name
option:
create_join_table :products, :categories, table_name: :categorization
This creates a join table with the name categorization
.
Also, create_join_table
accepts a block, which you can use to add indices
(which are not created by default) or any additional columns you so choose.
create_join_table :products, :categories do |t|
t.index :product_id
t.index :category_id
end
3.3 Changing Tables
If you want to change an existing table in place, there is change_table
.
It is used in a similar fashion to create_table
but the object yielded inside
the block has access to a number of special functions, for example:
change_table :products do |t|
t.remove :description, :name
t.string :part_number
t.index :part_number
t.rename :upccode, :upc_code
end
This migration will remove the description
and name
columns, create a new
string column called part_number
and add an index on it. Finally, it renames
the upccode
column to upc_code
.
3.4 Changing Columns
Similar to the remove_column
and add_column
methods we covered
earlier, Rails also provides the change_column
migration method.
change_column :products, :part_number, :text
This changes the column part_number
on products table to be a :text
field.
The change_column
command is irreversible. To ensure your migration
can be safely reverted, you will need to provide your own reversible
migration. See the Reversible Migrations section for more
details.
Besides change_column
, the change_column_null
and
change_column_default
methods are used to change a null constraint and
default values of a column.
change_column_default :products, :approved, from: true, to: false
This changes the default value of the :approved
field from true to false. This
change will only be applied to future records, any existing records do not
change. Use change_column_null
to change a null constraint.
change_column_null :products, :name, false
This sets :name
field on products to a NOT NULL
column. This change applies
to existing records as well, so you need to make sure all existing records have
a :name
that is NOT NULL
.
Setting the null constraint to true
implies that column will accept a null
value, otherwise the NOT NULL
constraint is applied and a value must be passed
in order to persist the record to the database.
You could also write the above change_column_default
migration as
change_column_default :products, :approved, false
, but unlike the previous
example, this would make your migration irreversible.
3.5 Column Modifiers
Column modifiers can be applied when creating or changing a column:
comment
Adds a comment for the column.collation
Specifies the collation for astring
ortext
column.default
Allows to set a default value on the column. Note that if you are using a dynamic value (such as a date), the default will only be calculated the first time (i.e. on the date the migration is applied). Usenil
forNULL
.limit
Sets the maximum number of characters for astring
column and the maximum number of bytes fortext/binary/integer
columns.null
Allows or disallowsNULL
values in the column.precision
Specifies the precision fordecimal/numeric/datetime/time
columns.scale
Specifies the scale for thedecimal
andnumeric
columns, representing the number of digits after the decimal point.
For add_column
or change_column
there is no option for adding indexes.
They need to be added separately using add_index
.
Some adapters may support additional options; see the adapter specific API docs for further information.
null
and default
cannot be specified via command line when generating
migrations.
3.6 References
The add_reference
method allows the creation of an appropriately named column
acting as the connection between one or more associations.
add_reference :users, :role
This migration will create a foreign key column called role_id
in the users
table. role_id
is a reference to the id
column in the roles
table. In
addition, it creates an index for the role_id
column, unless it is explicitly
told not to do so with the index: false
option.
See also the Active Record Associations guide to learn more.
The method add_belongs_to
is an alias of add_reference
.
add_belongs_to :taggings, :taggable, polymorphic: true
The polymorphic option will create two columns on the taggings table which can
be used for polymorphic associations: taggable_type
and taggable_id
.
See this guide to learn more about polymorphic associations.
A foreign key can be created with the foreign_key
option.
add_reference :users, :role, foreign_key: true
For more add_reference
options, visit the API
documentation.
References can also be removed:
remove_reference :products, :user, foreign_key: true, index: false
3.7 Foreign Keys
While it's not required, you might want to add foreign key constraints to guarantee referential integrity.
add_foreign_key :articles, :authors
The add_foreign_key
call adds a new constraint to the articles
table.
The constraint guarantees that a row in the authors
table exists where the
id
column matches the articles.author_id
to ensure all reviewers listed in
the articles table are valid authors listed in the authors table.
When using references
in a migration, you are creating a new column in
the table and you'll have the option to add a foreign key using foreign_key:
true
to that column. However, if you want to add a foreign key to an existing
column, you can use add_foreign_key
.
If the column name of the table to which we're adding the foreign key cannot be
derived from the table with the referenced primary key then you can use the
:column
option to specify the column name. Additionally, you can use the
:primary_key
option if the referenced primary key is not :id
.
For example, to add a foreign key on articles.reviewer
referencing
authors.email
:
add_foreign_key :articles, :authors, column: :reviewer, primary_key: :email
This will add a constraint to the articles
table that guarantees a row in the
authors
table exists where the email
column matches the articles.reviewer
field.
Several other options such as name
, on_delete
, if_not_exists
, validate
,
and deferrable
are supported by add_foreign_key
.
Foreign keys can also be removed using remove_foreign_key
:
# let Active Record figure out the column name
remove_foreign_key :accounts, :branches
# remove foreign key for a specific column
remove_foreign_key :accounts, column: :owner_id
Active Record only supports single column foreign keys. execute
and
structure.sql
are required to use composite foreign keys. See Schema Dumping
and You.
3.8 Composite Primary Keys
Sometimes a single column's value isn't enough to uniquely identify every row of
a table, but a combination of two or more columns does uniquely identify it.
This can be the case when using a legacy database schema without a single id
column as a primary key, or when altering schemas for sharding or multitenancy.
You can create a table with a composite primary key by passing the
:primary_key
option to create_table
with an array value:
class CreateProducts < ActiveRecord::Migration[7.2]
def change
create_table :products, primary_key: [:customer_id, :product_sku] do |t|
t.integer :customer_id
t.string :product_sku
t.text :description
end
end
end
Tables with composite primary keys require passing array values rather than integer IDs to many methods. See also the Active Record Composite Primary Keys guide to learn more.
3.9 Execute SQL
If the helpers provided by Active Record aren't enough, you can use the
execute
method to execute SQL commands. For example,
class UpdateProductPrices < ActiveRecord::Migration[7.2]
def up
execute "UPDATE products SET price = 'free'"
end
def down
execute "UPDATE products SET price = 'original_price' WHERE price = 'free';"
end
end
In this example, we're updating the price
column of the products table to
'free' for all records.
Modifying data directly in migrations should be approached with caution. Consider if this is the best approach for your use case, and be aware of potential drawbacks such as increased complexity and maintenance overhead, risks to data integrity and database portability. See the Data Migrations documentation for more details.
For more details and examples of individual methods, check the API documentation.
In particular the documentation for
ActiveRecord::ConnectionAdapters::SchemaStatements
, which provides the
methods available in the change
, up
and down
methods.
For methods available regarding the object yielded by create_table
, see
ActiveRecord::ConnectionAdapters::TableDefinition
.
And for the object yielded by change_table
, see
ActiveRecord::ConnectionAdapters::Table
.
3.10 Using the change
Method
The change
method is the primary way of writing migrations. It works for the
majority of cases in which Active Record knows how to reverse a migration's
actions automatically. Below are some of the actions that change
supports:
add_check_constraint
add_column
add_foreign_key
add_index
add_reference
add_timestamps
change_column_comment
(must supply:from
and:to
options)change_column_default
(must supply:from
and:to
options)change_column_null
change_table_comment
(must supply:from
and:to
options)create_join_table
create_table
disable_extension
drop_join_table
drop_table
(must supply table creation options and block)enable_extension
remove_check_constraint
(must supply original constraint expression)remove_column
(must supply original type and column options)remove_columns
(must supply original type and column options)remove_foreign_key
(must supply other table and original options)remove_index
(must supply columns and original options)remove_reference
(must supply original options)remove_timestamps
(must supply original options)rename_column
rename_index
rename_table
change_table
is also reversible, as long as the block only calls
reversible operations like the ones listed above.
If you need to use any other methods, you should use reversible
or write the
up
and down
methods instead of using the change
method.
3.11 Using reversible
If you'd like for a migration to do something that Active Record doesn't know
how to reverse, then you can use reversible
to specify what to do when running
a migration and what else to do when reverting it.
class ChangeProductsPrice < ActiveRecord::Migration[7.2]
def change
reversible do |direction|
change_table :products do |t|
direction.up { t.change :price, :string }
direction.down { t.change :price, :integer }
end
end
end
end
This migration will change the type of the price
column to a string, or back
to an integer when the migration is reverted. Notice the block being passed to
direction.up
and direction.down
respectively.
Alternatively, you can use up
and down
instead of change
:
class ChangeProductsPrice < ActiveRecord::Migration[7.2]
def up
change_table :products do |t|
t.change :price, :string
end
end
def down
change_table :products do |t|
t.change :price, :integer
end
end
end
Additionally, reversible
is useful when executing raw SQL queries or
performing database operations that do not have a direct equivalent in
ActiveRecord methods. You can use reversible
to specify what to do when
running a migration and what else to do when reverting it. For example:
class ExampleMigration < ActiveRecord::Migration[7.2]
def change
create_table :distributors do |t|
t.string :zipcode
end
reversible do |direction|
direction.up do
# create a distributors view
execute <<-SQL
CREATE VIEW distributors_view AS
SELECT id, zipcode
FROM distributors;
SQL
end
direction.down do
execute <<-SQL
DROP VIEW distributors_view;
SQL
end
end
add_column :users, :address, :string
end
end
Using reversible
will ensure that the instructions are executed in the right
order too. If the previous example migration is reverted, the down
block will
be run after the users.address
column is removed and before the distributors
table is dropped.
3.12 Using the up
/down
Methods
You can also use the old style of migration using up
and down
methods
instead of the change
method.
The up
method should describe the transformation you'd like to make to your
schema, and the down
method of your migration should revert the
transformations done by the up
method. In other words, the database schema
should be unchanged if you do an up
followed by a down
.
For example, if you create a table in the up
method, you should drop it in the
down
method. It is wise to perform the transformations in precisely the
reverse order they were made in the up
method. The example in the reversible
section is equivalent to:
class ExampleMigration < ActiveRecord::Migration[7.2]
def up
create_table :distributors do |t|
t.string :zipcode
end
# create a distributors view
execute <<-SQL
CREATE VIEW distributors_view AS
SELECT id, zipcode
FROM distributors;
SQL
add_column :users, :address, :string
end
def down
remove_column :users, :address
execute <<-SQL
DROP VIEW distributors_view;
SQL
drop_table :distributors
end
end
3.13 Throwing an error to prevent reverts
Sometimes your migration will do something which is just plain irreversible; for example, it might destroy some data.
In such cases, you can raise ActiveRecord::IrreversibleMigration
in your
down
block.
class IrreversibleMigrationExample < ActiveRecord::Migration[7.2]
def up
drop_table :example_table
end
def down
raise ActiveRecord::IrreversibleMigration, "This migration cannot be reverted because it destroys data."
end
end
If someone tries to revert your migration, an error message will be displayed saying that it can't be done.
3.14 Reverting Previous Migrations
You can use Active Record's ability to rollback migrations using the
revert
method:
require_relative "20121212123456_example_migration"
class FixupExampleMigration < ActiveRecord::Migration[7.2]
def change
revert ExampleMigration
create_table(:apples) do |t|
t.string :variety
end
end
end
The revert
method also accepts a block of instructions to reverse. This could
be useful to revert selected parts of previous migrations.
For example, let's imagine that ExampleMigration
is committed and it is later
decided that a Distributors view is no longer needed.
class DontUseDistributorsViewMigration < ActiveRecord::Migration[7.2]
def change
revert do
# copy-pasted code from ExampleMigration
create_table :distributors do |t|
t.string :zipcode
end
reversible do |direction|
direction.up do
# create a distributors view
execute <<-SQL
CREATE VIEW distributors_view AS
SELECT id, zipcode
FROM distributors;
SQL
end
direction.down do
execute <<-SQL
DROP VIEW distributors_view;
SQL
end
end
# The rest of the migration was ok
end
end
end
The same migration could also have been written without using revert
but this
would have involved a few more steps:
- Reverse the order of
create_table
andreversible
. - Replace
create_table
withdrop_table
. - Finally, replace
up
withdown
and vice-versa.
This is all taken care of by revert
.
4 Running Migrations
Rails provides a set of commands to run certain sets of migrations.
The very first migration related rails command you will use will probably be
bin/rails db:migrate
. In its most basic form it just runs the change
or up
method for all the migrations that have not yet been run. If there are no such
migrations, it exits. It will run these migrations in order based on the date of
the migration.
Note that running the db:migrate
command also invokes the db:schema:dump
command, which will update your db/schema.rb
file to match the structure of
your database.
If you specify a target version, Active Record will run the required migrations (change, up, down) until it has reached the specified version. The version is the numerical prefix on the migration's filename. For example, to migrate to version 20240428000000 run:
$ bin/rails db:migrate VERSION=20240428000000
If version 20240428000000 is greater than the current version (i.e., it is
migrating upwards), this will run the change
(or up
) method on all
migrations up to and including 20240428000000, and will not execute any later
migrations. If migrating downwards, this will run the down
method on all the
migrations down to, but not including, 20240428000000.
4.1 Rolling Back
A common task is to rollback the last migration. For example, if you made a mistake in it and wish to correct it. Rather than tracking down the version number associated with the previous migration you can run:
$ bin/rails db:rollback
This will rollback the latest migration, either by reverting the change
method
or by running the down
method. If you need to undo several migrations you can
provide a STEP
parameter:
$ bin/rails db:rollback STEP=3
The last 3 migrations will be reverted.
In some cases where you modify a local migration and would like to rollback that
specific migration before migrating back up again, you can use the
db:migrate:redo
command. As with the db:rollback
command, you can use the
STEP
parameter if you need to go more than one version back, for example:
$ bin/rails db:migrate:redo STEP=3
You could get the same result using db:migrate
. However, these are there
for convenience so that you do not need to explicitly specify the version to
migrate to.
4.1.1 Transactions
In databases that support DDL transactions, changing the schema in a single transaction, each migration is wrapped in a transaction.
A transaction ensures that if a migration fails partway through, any changes that were successfully applied are rolled back, maintaining database consistency. This means that either all operations within the transaction are executed successfully, or none of them are, preventing the database from being left in an inconsistent state if an error occurs during the transaction.
If the database does not support DDL transactions with statements that change the schema, then when a migration fails, the parts of it that have succeeded will not be rolled back. You will have to rollback the changes manually.
There are queries that you can’t execute inside a transaction though, and for
these situations you can turn the automatic transactions off with
disable_ddl_transaction!
:
class ChangeEnum < ActiveRecord::Migration[7.2]
disable_ddl_transaction!
def up
execute "ALTER TYPE model_size ADD VALUE 'new_value'"
end
end
Remember that you can still open your own transactions, even if you are in a Migration with self.disable_ddl_transaction!.
4.2 Setting Up the Database
The bin/rails db:setup
command will create the database, load the schema, and
initialize it with the seed data.
4.3 Preparing the Database
The bin/rails db:prepare
command is similar to bin/rails db:setup
, but it
operates idempotently, so it can safely be called several times, but it will
only perform the necessary tasks once.
- If the database has not been created yet, the command will run as the
bin/rails db:setup
does. - If the database exists but the tables have not been created, the command will load the schema, run any pending migrations, dump the updated schema, and finally load the seed data. See the Seeding Data documentation for more details.
- If both the database and tables exist but the seed data has not been loaded, the command will only load the seed data.
- If the database, tables, and seed data are all in place, the command will do nothing.
Once the database, tables, and seed data are all established, the command
will not try to reload the seed data, even if the previously loaded seed data or
the existing seed file have been altered or deleted. To reload the seed data,
you can manually run bin/rails db:seed
.
4.4 Resetting the Database
The bin/rails db:reset
command will drop the database and set it up again.
This is functionally equivalent to bin/rails db:drop db:setup
.
This is not the same as running all the migrations. It will only use the
contents of the current db/schema.rb
or db/structure.sql
file. If a
migration can't be rolled back, bin/rails db:reset
may not help you. To find
out more about dumping the schema see Schema Dumping and You section.
4.5 Running Specific Migrations
If you need to run a specific migration up or down, the db:migrate:up
and
db:migrate:down
commands will do that. Just specify the appropriate version
and the corresponding migration will have its change
, up
or down
method
invoked, for example:
$ bin/rails db:migrate:up VERSION=20240428000000
By running this command the change
method (or the up
method) will be
executed for the migration with the version "20240428000000".
First, this command will check whether the migration exists and if it has already been performed and if so, it will do nothing.
If the version specified does not exist, Rails will throw an exception.
$ bin/rails db:migrate VERSION=00000000000000
rails aborted!
ActiveRecord::UnknownMigrationVersionError:
No migration with version number 00000000000000.
4.6 Running Migrations in Different Environments
By default running bin/rails db:migrate
will run in the development
environment.
To run migrations against another environment you can specify it using the
RAILS_ENV
environment variable while running the command. For example to run
migrations against the test
environment you could run:
$ bin/rails db:migrate RAILS_ENV=test
4.7 Changing the Output of Running Migrations
By default migrations tell you exactly what they're doing and how long it took. A migration creating a table and adding an index might produce output like this
== CreateProducts: migrating =================================================
-- create_table(:products)
-> 0.0028s
== CreateProducts: migrated (0.0028s) ========================================
Several methods are provided in migrations that allow you to control all this:
Method | Purpose |
---|---|
suppress_messages |
Takes a block as an argument and suppresses any output generated by the block. |
say |
Takes a message argument and outputs it as is. A second boolean argument can be passed to specify whether to indent or not. |
say_with_time |
Outputs text along with how long it took to run its block. If the block returns an integer it assumes it is the number of rows affected. |
For example, take the following migration:
class CreateProducts < ActiveRecord::Migration[7.2]
def change
suppress_messages do
create_table :products do |t|
t.string :name
t.text :description
t.timestamps
end
end
say "Created a table"
suppress_messages { add_index :products, :name }
say "and an index!", true
say_with_time 'Waiting for a while' do
sleep 10
250
end
end
end
This will generate the following output:
== CreateProducts: migrating =================================================
-- Created a table
-> and an index!
-- Waiting for a while
-> 10.0013s
-> 250 rows
== CreateProducts: migrated (10.0054s) =======================================
If you want Active Record to not output anything, then running bin/rails
db:migrate VERBOSE=false
will suppress all output.
4.8 Rails Migration Version Control
Rails keeps track of which migrations have been run through the
schema_migrations
table in the database. When you run a migration, Rails
inserts a row into the schema_migrations
table with the version number of the
migration, stored in the version
column. This allows Rails to determine which
migrations have already been applied to the database.
For example, if you have a migration file named 20240428000000_create_users.rb, Rails will extract the version number (20240428000000) from the filename and insert it into the schema_migrations table after the migration has been successfully executed.
You can view the contents of the schema_migrations table directly in your database management tool or by using Rails console:
rails dbconsole
Then, within the database console, you can query the schema_migrations table:
SELECT * FROM schema_migrations;
This will show you a list of all migration version numbers that have been applied to the database. Rails uses this information to determine which migrations need to be run when you run rails db:migrate or rails db:migrate:up commands.
5 Changing Existing Migrations
Occasionally you will make a mistake when writing a migration. If you have
already run the migration, then you cannot just edit the migration and run the
migration again: Rails thinks it has already run the migration and so will do
nothing when you run bin/rails db:migrate
. You must rollback the migration
(for example with bin/rails db:rollback
), edit your migration, and then run
bin/rails db:migrate
to run the corrected version.
In general, editing existing migrations that have been already committed to source control is not a good idea. You will be creating extra work for yourself and your co-workers and cause major headaches if the existing version of the migration has already been run on production machines. Instead, you should write a new migration that performs the changes you require.
However, editing a freshly generated migration that has not yet been committed to source control (or, more generally, has not been propagated beyond your development machine) is common.
The revert
method can be helpful when writing a new migration to undo previous
migrations in whole or in part (see Reverting Previous Migrations above).
6 Schema Dumping and You
6.1 What are Schema Files for?
Migrations, mighty as they may be, are not the authoritative source for your database schema. Your database remains the source of truth.
By default, Rails generates db/schema.rb
which attempts to capture the current
state of your database schema.
It tends to be faster and less error prone to create a new instance of your
application's database by loading the schema file via bin/rails db:schema:load
than it is to replay the entire migration history. Old migrations may fail
to apply correctly if those migrations use changing external dependencies or
rely on application code which evolves separately from your migrations.
Schema files are also useful if you want a quick look at what attributes an Active Record object has. This information is not in the model's code and is frequently spread across several migrations, but the information is nicely summed up in the schema file.
6.2 Types of Schema Dumps
The format of the schema dump generated by Rails is controlled by the
config.active_record.schema_format
setting defined in
config/application.rb
. By default, the format is :ruby
, or alternatively can
be set to :sql
.
6.2.1 Using the default :ruby
schema
When :ruby
is selected, then the schema is stored in db/schema.rb
. If you
look at this file you'll find that it looks an awful lot like one very big
migration:
ActiveRecord::Schema[7.2].define(version: 2008_09_06_171750) do
create_table "authors", force: true do |t|
t.string "name"
t.datetime "created_at"
t.datetime "updated_at"
end
create_table "products", force: true do |t|
t.string "name"
t.text "description"
t.datetime "created_at"
t.datetime "updated_at"
t.string "part_number"
end
end
In many ways this is exactly what it is. This file is created by inspecting the
database and expressing its structure using create_table
, add_index
, and so
on.
6.2.2 Using the :sql
schema dumper
However, db/schema.rb
cannot express everything your database may support such
as triggers, sequences, stored procedures, etc.
While migrations may use execute
to create database constructs that are not
supported by the Ruby migration DSL, these constructs may not be able to be
reconstituted by the schema dumper.
If you are using features like these, you should set the schema format to :sql
in order to get an accurate schema file that is useful to create new database
instances.
When the schema format is set to :sql
, the database structure will be dumped
using a tool specific to the database into db/structure.sql
. For example, for
PostgreSQL, the pg_dump
utility is used. For MySQL and MariaDB, this file will
contain the output of SHOW CREATE TABLE
for the various tables.
To load the schema from db/structure.sql
, run bin/rails db:schema:load
.
Loading this file is done by executing the SQL statements it contains. By
definition, this will create a perfect copy of the database's structure.
6.3 Schema Dumps and Source Control
Because schema files are commonly used to create new databases, it is strongly recommended that you check your schema file into source control.
Merge conflicts can occur in your schema file when two branches modify schema.
To resolve these conflicts run bin/rails db:migrate
to regenerate the schema
file.
Newly generated Rails apps will already have the migrations folder included in the git tree, so all you have to do is be sure to add any new migrations you add and commit them.
7 Active Record and Referential Integrity
The Active Record pattern suggests that intelligence should primarily reside in your models rather than in the database. Consequently, features like triggers or constraints, which delegate some of that intelligence back into the database, are not always favored.
Validations such as validates :foreign_key, uniqueness: true
are one way in
which models can enforce data integrity. The :dependent
option on associations
allows models to automatically destroy child objects when the parent is
destroyed. Like anything which operates at the application level, these cannot
guarantee referential integrity and so some people augment them with foreign
key constraints in the database.
In practice, foreign key constraints and unique indexes are generally considered safer when enforced at the database level. Although Active Record does not provide direct support for working with these database-level features, you can still use the execute method to run arbitrary SQL commands.
It's worth emphasizing that while the Active Record pattern emphasizes keeping intelligence within models, neglecting to implement foreign keys and unique constraints at the database level can potentially lead to integrity issues. Therefore, it's advisable to complement the AR pattern with database-level constraints where appropriate. These constraints should have their counterparts explicitly defined in your code using associations and validations to ensure data integrity across both application and database layers.
8 Migrations and Seed Data
The main purpose of the Rails migration feature is to issue commands that modify the schema using a consistent process. Migrations can also be used to add or modify data. This is useful in an existing database that can't be destroyed and recreated, such as a production database.
class AddInitialProducts < ActiveRecord::Migration[7.2]
def up
5.times do |i|
Product.create(name: "Product ##{i}", description: "A product.")
end
end
def down
Product.delete_all
end
end
To add initial data after a database is created, Rails has a built-in 'seeds' feature that speeds up the process. This is especially useful when reloading the database frequently in development and test environments, or when setting up initial data for production.
To get started with this feature, open up db/seeds.rb
and add some Ruby code,
then run bin/rails db:seed
.
The code here should be idempotent so that it can be executed at any point in every environment.
["Action", "Comedy", "Drama", "Horror"].each do |genre_name|
MovieGenre.find_or_create_by!(name: genre_name)
end
This is generally a much cleaner way to set up the database of a blank application.
9 Old Migrations
The db/schema.rb
or db/structure.sql
is a snapshot of the current state of
your database and is the authoritative source for rebuilding that database. This
makes it possible to delete or prune old migration files.
When you delete migration files in the db/migrate/
directory, any environment
where bin/rails db:migrate
was run when those files still existed will hold a
reference to the migration timestamp specific to them inside an internal Rails
database table named schema_migrations
. You can read more about this in the
Rails Migration Version Control section.
If you run the bin/rails db:migrate:status
command, which displays the status
(up or down) of each migration, you should see ********** NO FILE **********
displayed next to any deleted migration file which was once executed on a
specific environment but can no longer be found in the db/migrate/
directory.
9.1 Migrations from Engines
When dealing with migrations from Engines, there's a caveat to consider.
Rake tasks to install migrations from engines are idempotent, meaning they will
have the same result no matter how many times they are called. Migrations
present in the parent application due to a previous installation are skipped,
and missing ones are copied with a new leading timestamp. If you deleted old
engine migrations and ran the install task again, you'd get new files with new
timestamps, and db:migrate
would attempt to run them again.
Thus, you generally want to preserve migrations coming from engines. They have a special comment like this:
# This migration comes from blorgh (originally 20210621082949)
10 Miscellaneous
10.1 Using UUIDs instead of IDs for Primary Keys
By default, Rails uses auto-incrementing integers as primary keys for database records. However, there are scenarios where using Universally Unique Identifiers (UUIDs) as primary keys can be advantageous, especially in distributed systems or when integration with external services is necessary. UUIDs provide a globally unique identifier without relying on a centralized authority for generating IDs.
10.1.1 Enabling UUIDs in Rails
Before using UUIDs in your Rails application, you'll need to ensure that your database supports storing them. Additionally, you may need to configure your database adapter to work with UUIDs.
If you are using a version of PostgreSQL prior to 13, you may still need
to enable the pgcrypto extension to access the gen_random_uuid()
function.
Rails Configuration
In your Rails application configuration file (
config/application.rb
), add the following line to configure Rails to generate UUIDs as primary keys by default:config.generators do |g| g.orm :active_record, primary_key_type: :uuid end
This setting instructs Rails to use UUIDs as the default primary key type for ActiveRecord models.
Adding References with UUIDs:
When creating associations between models using references, ensure that you specify the data type as :uuid to maintain consistency with the primary key type. For example:
create_table :posts, id: :uuid do |t| t.references :author, type: :uuid, foreign_key: true # Other columns... t.timestamps end
In this example, the
author_id
column in the posts table references theid
column of the authors table. By explicitly setting the type to:uuid
, you ensure that the foreign key column matches the data type of the primary key it references. Adjust the syntax accordingly for other associations and databases.Migration Changes
When generating migrations for your models, you'll notice that it specifies the id to be of type
uuid:
$ bin/rails g migration CreateAuthors
class CreateAuthors < ActiveRecord::Migration[7.2] def change create_table :authors, id: :uuid do |t| t.timestamps end end end
which results in the following schema:
create_table "authors", id: :uuid, default: -> { "gen_random_uuid()" }, force: :cascade do |t| t.datetime "created_at", precision: 6, null: false t.datetime "updated_at", precision: 6, null: false end
In this migration, the
id
column is defined as a UUID primary key with a default value generated by thegen_random_uuid()
function.
UUIDs are guaranteed to be globally unique across different systems, making them suitable for distributed architectures. They also simplify integration with external systems or APIs by providing a unique identifier that doesn't rely on centralized ID generation, and unlike auto-incrementing integers, UUIDs don't expose information about the total number of records in a table, which can be beneficial for security purposes.
However, UUIDs can also impact performance due to their size and are harder to index. UUIDs will have worse performance for writes and reads compared with integer primary keys and foreign keys.
Therefore, it's essential to evaluate the trade-offs and consider the specific requirements of your application before deciding to use UUIDs as primary keys.
10.2 Data Migrations
Data migrations involve transforming or moving data within your database. In Rails, it is generally not advised to perform data migrations using migration files. Here’s why:
- Separation of Concerns: Schema changes and data changes have different lifecycles and purposes. Schema changes alter the structure of your database, while data changes alter the content.
- Rollback Complexity: Data migrations can be hard to rollback safely and predictably.
- Performance: Data migrations can take a long time to run and may lock your tables, affecting application performance and availability.
Instead, consider using the
maintenance_tasks
gem. This
gem provides a framework for creating and managing data migrations and other
maintenance tasks in a way that is safe and easy to manage without interfering
with schema migrations.
Feedback
You're encouraged to help improve the quality of this guide.
Please contribute if you see any typos or factual errors. To get started, you can read our documentation contributions section.
You may also find incomplete content or stuff that is not up to date. Please do add any missing documentation for main. Make sure to check Edge Guides first to verify if the issues are already fixed or not on the main branch. Check the Ruby on Rails Guides Guidelines for style and conventions.
If for whatever reason you spot something to fix but cannot patch it yourself, please open an issue.
And last but not least, any kind of discussion regarding Ruby on Rails documentation is very welcome on the official Ruby on Rails Forum.