Skip to content

Commit

Permalink
Updated migration version in examples [skip ci]
Browse files Browse the repository at this point in the history
  • Loading branch information
@ankane
ankane committed Oct 17, 2023
1 parent 0bed73b commit 2aa498b
Showing 1 changed file with 33 additions and 33 deletions.
66 changes: 33 additions & 33 deletions README.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -43,7 +43,7 @@ end
Deploy the code, then wrap this step in a safety_assured { ... } block.
class RemoveColumn < ActiveRecord::Migration[7.0]
class RemoveColumn < ActiveRecord::Migration[7.1]
def change
safety_assured { remove_column :users, :name }
end
Expand Down Expand Up @@ -96,7 +96,7 @@ You can also add [custom checks](#custom-checks) or [disable specific checks](#d
Active Record caches database columns at runtime, so if you drop a column, it can cause exceptions until your app reboots.

```ruby
class RemoveSomeColumnFromUsers < ActiveRecord::Migration[7.0]
class RemoveSomeColumnFromUsers < ActiveRecord::Migration[7.1]
def change
remove_column :users, :some_column
end
Expand All @@ -117,7 +117,7 @@ end
3. Write a migration to remove the column (wrap in `safety_assured` block)

```ruby
class RemoveSomeColumnFromUsers < ActiveRecord::Migration[7.0]
class RemoveSomeColumnFromUsers < ActiveRecord::Migration[7.1]
def change
safety_assured { remove_column :users, :some_column }
end
Expand All @@ -134,7 +134,7 @@ end
In earlier versions of Postgres, MySQL, and MariaDB, adding a column with a default value to an existing table causes the entire table to be rewritten. During this time, reads and writes are blocked in Postgres, and writes are blocked in MySQL and MariaDB.

```ruby
class AddSomeColumnToUsers < ActiveRecord::Migration[7.0]
class AddSomeColumnToUsers < ActiveRecord::Migration[7.1]
def change
add_column :users, :some_column, :text, default: "default_value"
end
Expand All @@ -148,7 +148,7 @@ In Postgres 11+, MySQL 8.0.12+, and MariaDB 10.3.2+, this no longer requires a t
Instead, add the column without a default value, then change the default.

```ruby
class AddSomeColumnToUsers < ActiveRecord::Migration[7.0]
class AddSomeColumnToUsers < ActiveRecord::Migration[7.1]
def up
add_column :users, :some_column, :text
change_column_default :users, :some_column, "default_value"
Expand All @@ -169,7 +169,7 @@ See the next section for how to backfill.
Active Record creates a transaction around each migration, and backfilling in the same transaction that alters a table keeps the table locked for the [duration of the backfill](https://wework.github.io/data/2015/11/05/add-columns-with-default-values-to-large-tables-in-rails-postgres/).

```ruby
class AddSomeColumnToUsers < ActiveRecord::Migration[7.0]
class AddSomeColumnToUsers < ActiveRecord::Migration[7.1]
def change
add_column :users, :some_column, :text
User.update_all some_column: "default_value"
Expand All @@ -184,7 +184,7 @@ Also, running a single query to update data can cause issues for large tables.
There are three keys to backfilling safely: batching, throttling, and running it outside a transaction. Use the Rails console or a separate migration with `disable_ddl_transaction!`.

```ruby
class BackfillSomeColumn < ActiveRecord::Migration[7.0]
class BackfillSomeColumn < ActiveRecord::Migration[7.1]
disable_ddl_transaction!

def up
Expand All @@ -203,7 +203,7 @@ end
Adding a stored generated column causes the entire table to be rewritten. During this time, reads and writes are blocked in Postgres, and writes are blocked in MySQL and MariaDB.

```ruby
class AddSomeColumnToUsers < ActiveRecord::Migration[7.0]
class AddSomeColumnToUsers < ActiveRecord::Migration[7.1]
def change
add_column :users, :some_column, :virtual, type: :string, as: "...", stored: true
end
Expand All @@ -221,7 +221,7 @@ Add a non-generated column and use callbacks or triggers instead (or a virtual g
Changing the type of a column causes the entire table to be rewritten. During this time, reads and writes are blocked in Postgres, and writes are blocked in MySQL and MariaDB.

```ruby
class ChangeSomeColumnType < ActiveRecord::Migration[7.0]
class ChangeSomeColumnType < ActiveRecord::Migration[7.1]
def change
change_column :users, :some_column, :new_type
end
Expand Down Expand Up @@ -267,7 +267,7 @@ A safer approach is to:
Renaming a column that’s in use will cause errors in your application.

```ruby
class RenameSomeColumn < ActiveRecord::Migration[7.0]
class RenameSomeColumn < ActiveRecord::Migration[7.1]
def change
rename_column :users, :some_column, :new_name
end
Expand All @@ -292,7 +292,7 @@ A safer approach is to:
Renaming a table that’s in use will cause errors in your application.

```ruby
class RenameUsersToCustomers < ActiveRecord::Migration[7.0]
class RenameUsersToCustomers < ActiveRecord::Migration[7.1]
def change
rename_table :users, :customers
end
Expand All @@ -317,7 +317,7 @@ A safer approach is to:
The `force` option can drop an existing table.

```ruby
class CreateUsers < ActiveRecord::Migration[7.0]
class CreateUsers < ActiveRecord::Migration[7.1]
def change
create_table :users, force: true do |t|
# ...
Expand All @@ -331,7 +331,7 @@ end
Create tables without the `force` option.

```ruby
class CreateUsers < ActiveRecord::Migration[7.0]
class CreateUsers < ActiveRecord::Migration[7.1]
def change
create_table :users do |t|
# ...
Expand All @@ -351,7 +351,7 @@ If you intend to drop an existing table, run `drop_table` first.
Adding a check constraint blocks reads and writes in Postgres and blocks writes in MySQL and MariaDB while every row is checked.

```ruby
class AddCheckConstraint < ActiveRecord::Migration[7.0]
class AddCheckConstraint < ActiveRecord::Migration[7.1]
def change
add_check_constraint :users, "price > 0", name: "price_check"
end
Expand All @@ -363,7 +363,7 @@ end
Add the check constraint without validating existing rows:

```ruby
class AddCheckConstraint < ActiveRecord::Migration[7.0]
class AddCheckConstraint < ActiveRecord::Migration[7.1]
def change
add_check_constraint :users, "price > 0", name: "price_check", validate: false
end
Expand All @@ -373,7 +373,7 @@ end
Then validate them in a separate migration.

```ruby
class ValidateCheckConstraint < ActiveRecord::Migration[7.0]
class ValidateCheckConstraint < ActiveRecord::Migration[7.1]
def change
validate_check_constraint :users, name: "price_check"
end
Expand All @@ -389,7 +389,7 @@ end
Strong Migrations can’t ensure safety for raw SQL statements. Make really sure that what you’re doing is safe, then use:

```ruby
class ExecuteSQL < ActiveRecord::Migration[7.0]
class ExecuteSQL < ActiveRecord::Migration[7.1]
def change
safety_assured { execute "..." }
end
Expand All @@ -405,7 +405,7 @@ end
In Postgres, adding an index non-concurrently blocks writes.

```ruby
class AddSomeIndexToUsers < ActiveRecord::Migration[7.0]
class AddSomeIndexToUsers < ActiveRecord::Migration[7.1]
def change
add_index :users, :some_column
end
Expand All @@ -417,7 +417,7 @@ end
Add indexes concurrently.

```ruby
class AddSomeIndexToUsers < ActiveRecord::Migration[7.0]
class AddSomeIndexToUsers < ActiveRecord::Migration[7.1]
disable_ddl_transaction!

def change
Expand All @@ -443,7 +443,7 @@ rails g index table column
Rails adds an index non-concurrently to references by default, which blocks writes in Postgres.

```ruby
class AddReferenceToUsers < ActiveRecord::Migration[7.0]
class AddReferenceToUsers < ActiveRecord::Migration[7.1]
def change
add_reference :users, :city
end
Expand All @@ -455,7 +455,7 @@ end
Make sure the index is added concurrently.

```ruby
class AddReferenceToUsers < ActiveRecord::Migration[7.0]
class AddReferenceToUsers < ActiveRecord::Migration[7.1]
disable_ddl_transaction!

def change
Expand All @@ -473,7 +473,7 @@ end
In Postgres, adding a foreign key blocks writes on both tables.

```ruby
class AddForeignKeyOnUsers < ActiveRecord::Migration[7.0]
class AddForeignKeyOnUsers < ActiveRecord::Migration[7.1]
def change
add_foreign_key :users, :orders
end
Expand All @@ -483,7 +483,7 @@ end
or

```ruby
class AddReferenceToUsers < ActiveRecord::Migration[7.0]
class AddReferenceToUsers < ActiveRecord::Migration[7.1]
def change
add_reference :users, :order, foreign_key: true
end
Expand All @@ -495,7 +495,7 @@ end
Add the foreign key without validating existing rows:

```ruby
class AddForeignKeyOnUsers < ActiveRecord::Migration[7.0]
class AddForeignKeyOnUsers < ActiveRecord::Migration[7.1]
def change
add_foreign_key :users, :orders, validate: false
end
Expand All @@ -505,7 +505,7 @@ end
Then validate them in a separate migration.

```ruby
class ValidateForeignKeyOnUsers < ActiveRecord::Migration[7.0]
class ValidateForeignKeyOnUsers < ActiveRecord::Migration[7.1]
def change
validate_foreign_key :users, :orders
end
Expand Down Expand Up @@ -537,7 +537,7 @@ end
In Postgres, there’s no equality operator for the `json` column type, which can cause errors for existing `SELECT DISTINCT` queries in your application.

```ruby
class AddPropertiesToUsers < ActiveRecord::Migration[7.0]
class AddPropertiesToUsers < ActiveRecord::Migration[7.1]
def change
add_column :users, :properties, :json
end
Expand All @@ -549,7 +549,7 @@ end
Use `jsonb` instead.

```ruby
class AddPropertiesToUsers < ActiveRecord::Migration[7.0]
class AddPropertiesToUsers < ActiveRecord::Migration[7.1]
def change
add_column :users, :properties, :jsonb
end
Expand All @@ -565,7 +565,7 @@ end
In Postgres, setting `NOT NULL` on an existing column blocks reads and writes while every row is checked.

```ruby
class SetSomeColumnNotNull < ActiveRecord::Migration[7.0]
class SetSomeColumnNotNull < ActiveRecord::Migration[7.1]
def change
change_column_null :users, :some_column, false
end
Expand All @@ -579,7 +579,7 @@ Instead, add a check constraint.
For Rails 6.1, use:

```ruby
class SetSomeColumnNotNull < ActiveRecord::Migration[7.0]
class SetSomeColumnNotNull < ActiveRecord::Migration[7.1]
def change
add_check_constraint :users, "some_column IS NOT NULL", name: "users_some_column_null", validate: false
end
Expand All @@ -603,7 +603,7 @@ Then validate it in a separate migration. A `NOT NULL` check constraint is [func
For Rails 6.1, use:

```ruby
class ValidateSomeColumnNotNull < ActiveRecord::Migration[7.0]
class ValidateSomeColumnNotNull < ActiveRecord::Migration[7.1]
def change
validate_check_constraint :users, name: "users_some_column_null"

Expand Down Expand Up @@ -669,7 +669,7 @@ config.active_record.partial_inserts = false
Adding a non-unique index with more than three columns rarely improves performance.

```ruby
class AddSomeIndexToUsers < ActiveRecord::Migration[7.0]
class AddSomeIndexToUsers < ActiveRecord::Migration[7.1]
def change
add_index :users, [:a, :b, :c, :d]
end
Expand All @@ -681,7 +681,7 @@ end
Instead, start an index with columns that narrow down the results the most.

```ruby
class AddSomeIndexToUsers < ActiveRecord::Migration[7.0]
class AddSomeIndexToUsers < ActiveRecord::Migration[7.1]
def change
add_index :users, [:b, :d]
end
Expand All @@ -695,7 +695,7 @@ For Postgres, be sure to add them concurrently.
To mark a step in the migration as safe, despite using a method that might otherwise be dangerous, wrap it in a `safety_assured` block.

```ruby
class MySafeMigration < ActiveRecord::Migration[7.0]
class MySafeMigration < ActiveRecord::Migration[7.1]
def change
safety_assured { remove_column :users, :some_column }
end
Expand Down

0 comments on commit 2aa498b

Please sign in to comment.