strong_migrations 0.7.6 → 1.7.0

data/README.md

@@ -4,18 +4,18 @@ Catch unsafe migrations in development
 
 &nbsp;&nbsp;✓&nbsp;&nbsp;Detects potentially dangerous operations<br />&nbsp;&nbsp;✓&nbsp;&nbsp;Prevents them from running by default<br />&nbsp;&nbsp;✓&nbsp;&nbsp;Provides instructions on safer ways to do what you want
 
-Supports for PostgreSQL, MySQL, and MariaDB
+Supports PostgreSQL, MySQL, and MariaDB
 
 :tangerine: Battle-tested at [Instacart](https://www.instacart.com/opensource)
 
-[![Build Status](https://github.com/ankane/strong_migrations/workflows/build/badge.svg?branch=master)](https://github.com/ankane/strong_migrations/actions)
+[![Build Status](https://github.com/ankane/strong_migrations/actions/workflows/build.yml/badge.svg)](https://github.com/ankane/strong_migrations/actions)
 
 ## Installation
 
 Add this line to your application’s Gemfile:
 
 ```ruby
-gem 'strong_migrations'
+gem "strong_migrations"
 ```
 
 And run:
@@ -43,7 +43,7 @@ end
 
 Deploy the code, then wrap this step in a safety_assured { ... } block.
 
-class RemoveColumn < ActiveRecord::Migration[6.1]
+class RemoveColumn < ActiveRecord::Migration[7.1]
   def change
     safety_assured { remove_column :users, :name }
   end
@@ -62,12 +62,12 @@ Potentially dangerous operations:
 - [removing a column](#removing-a-column)
 - [adding a column with a default value](#adding-a-column-with-a-default-value)
 - [backfilling data](#backfilling-data)
+- [adding a stored generated column](#adding-a-stored-generated-column)
 - [changing the type of a column](#changing-the-type-of-a-column)
 - [renaming a column](#renaming-a-column)
 - [renaming a table](#renaming-a-table)
 - [creating a table with the force option](#creating-a-table-with-the-force-option)
 - [adding a check constraint](#adding-a-check-constraint)
-- [setting NOT NULL on an existing column](#setting-not-null-on-an-existing-column)
 - [executing SQL directly](#executing-SQL-directly)
 
 Postgres-specific checks:
@@ -75,7 +75,14 @@ Postgres-specific checks:
 - [adding an index non-concurrently](#adding-an-index-non-concurrently)
 - [adding a reference](#adding-a-reference)
 - [adding a foreign key](#adding-a-foreign-key)
+- [adding a unique constraint](#adding-a-unique-constraint)
+- [adding an exclusion constraint](#adding-an-exclusion-constraint)
 - [adding a json column](#adding-a-json-column)
+- [setting NOT NULL on an existing column](#setting-not-null-on-an-existing-column)
+
+Config-specific checks:
+
+- [changing the default value of a column](#changing-the-default-value-of-a-column)
 
 Best practices:
 
@@ -90,7 +97,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[6.1]
+class RemoveSomeColumnFromUsers < ActiveRecord::Migration[7.1]
   def change
     remove_column :users, :some_column
   end
@@ -107,18 +114,19 @@ end
   end
   ```
 
-2. Deploy code
+2. Deploy the code
 3. Write a migration to remove the column (wrap in `safety_assured` block)
 
   ```ruby
-  class RemoveSomeColumnFromUsers < ActiveRecord::Migration[6.1]
+  class RemoveSomeColumnFromUsers < ActiveRecord::Migration[7.1]
     def change
       safety_assured { remove_column :users, :some_column }
     end
   end
   ```
 
-4. Deploy and run migration
+4. Deploy and run the migration
+5. Remove the line added in step 1
 
 ### Adding a column with a default value
 
@@ -127,21 +135,21 @@ 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[6.1]
+class AddSomeColumnToUsers < ActiveRecord::Migration[7.1]
   def change
     add_column :users, :some_column, :text, default: "default_value"
   end
 end
 ```
 
-In Postgres 11+, MySQL 8.0.12+, and MariaDB 10.3.2+, this no longer requires a table rewrite and is safe.
+In Postgres 11+, MySQL 8.0.12+, and MariaDB 10.3.2+, this no longer requires a table rewrite and is safe (except for volatile functions like `gen_random_uuid()`).
 
 #### Good
 
 Instead, add the column without a default value, then change the default.
 
 ```ruby
-class AddSomeColumnToUsers < ActiveRecord::Migration[6.1]
+class AddSomeColumnToUsers < ActiveRecord::Migration[7.1]
   def up
     add_column :users, :some_column, :text
     change_column_default :users, :some_column, "default_value"
@@ -162,7 +170,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[6.1]
+class AddSomeColumnToUsers < ActiveRecord::Migration[7.1]
   def change
     add_column :users, :some_column, :text
     User.update_all some_column: "default_value"
@@ -177,7 +185,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[6.1]
+class BackfillSomeColumn < ActiveRecord::Migration[7.1]
   disable_ddl_transaction!
 
   def up
@@ -189,6 +197,24 @@ class BackfillSomeColumn < ActiveRecord::Migration[6.1]
 end
 ```
 
+### Adding a stored generated column
+
+#### Bad
+
+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.1]
+  def change
+    add_column :users, :some_column, :virtual, type: :string, as: "...", stored: true
+  end
+end
+```
+
+#### Good
+
+Add a non-generated column and use callbacks or triggers instead (or a virtual generated column with MySQL and MariaDB).
+
 ### Changing the type of a column
 
 #### Bad
@@ -196,26 +222,33 @@ end
 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[6.1]
+class ChangeSomeColumnType < ActiveRecord::Migration[7.1]
   def change
     change_column :users, :some_column, :new_type
   end
 end
 ```
 
-A few changes don’t require a table rewrite (and are safe) in Postgres:
+Some changes don’t require a table rewrite and are safe in Postgres:
 
-- Increasing the length limit of a `varchar` column (or removing the limit)
-- Changing a `varchar` column to a `text` column
-- Changing a `text` column to a `varchar` column with no length limit
-- Increasing the precision of a `decimal` or `numeric` column
-- Making a `decimal` or `numeric` column unconstrained
-- Changing between `timestamp` and `timestamptz` columns when session time zone is UTC in Postgres 12+
+Type | Safe Changes
+--- | ---
+`cidr` | Changing to `inet`
+`citext` | Changing to `text` if not indexed, changing to `string` with no `:limit` if not indexed
+`datetime` | Increasing or removing `:precision`, changing to `timestamptz` when session time zone is UTC in Postgres 12+
+`decimal` | Increasing `:precision` at same `:scale`, removing `:precision` and `:scale`
+`interval` | Increasing or removing `:precision`
+`numeric` | Increasing `:precision` at same `:scale`, removing `:precision` and `:scale`
+`string` | Increasing or removing `:limit`, changing to `text`, changing `citext` if not indexed
+`text` | Changing to `string` with no `:limit`, changing to `citext` if not indexed
+`time` | Increasing or removing `:precision`
+`timestamptz` | Increasing or removing `:limit`, changing to `datetime` when session time zone is UTC in Postgres 12+
 
-And a few in MySQL and MariaDB:
+And some in MySQL and MariaDB:
 
-- Increasing the length limit of a `varchar` column from under 255 up to 255
-- Increasing the length limit of a `varchar` column from over 255 to the max limit
+Type | Safe Changes
+--- | ---
+`string` | Increasing `:limit` from under 63 up to 63, increasing `:limit` from over 63 to the max (the threshold can be different if using an encoding other than `utf8mb4` - for instance, it’s 85 for `utf8mb3` and 255 for `latin1`)
 
 #### Good
 
@@ -235,7 +268,7 @@ A safer approach is to:
 Renaming a column that’s in use will cause errors in your application.
 
 ```ruby
-class RenameSomeColumn < ActiveRecord::Migration[6.1]
+class RenameSomeColumn < ActiveRecord::Migration[7.1]
   def change
     rename_column :users, :some_column, :new_name
   end
@@ -260,7 +293,7 @@ A safer approach is to:
 Renaming a table that’s in use will cause errors in your application.
 
 ```ruby
-class RenameUsersToCustomers < ActiveRecord::Migration[6.1]
+class RenameUsersToCustomers < ActiveRecord::Migration[7.1]
   def change
     rename_table :users, :customers
   end
@@ -273,7 +306,7 @@ A safer approach is to:
 
 1. Create a new table
 2. Write to both tables
-3. Backfill data from the old table to new table
+3. Backfill data from the old table to the new table
 4. Move reads from the old table to the new table
 5. Stop writing to the old table
 6. Drop the old table
@@ -285,7 +318,7 @@ A safer approach is to:
 The `force` option can drop an existing table.
 
 ```ruby
-class CreateUsers < ActiveRecord::Migration[6.1]
+class CreateUsers < ActiveRecord::Migration[7.1]
   def change
     create_table :users, force: true do |t|
       # ...
@@ -299,7 +332,7 @@ end
 Create tables without the `force` option.
 
 ```ruby
-class CreateUsers < ActiveRecord::Migration[6.1]
+class CreateUsers < ActiveRecord::Migration[7.1]
   def change
     create_table :users do |t|
       # ...
@@ -319,7 +352,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[6.1]
+class AddCheckConstraint < ActiveRecord::Migration[7.1]
   def change
     add_check_constraint :users, "price > 0", name: "price_check"
   end
@@ -331,7 +364,7 @@ end
 Add the check constraint without validating existing rows:
 
 ```ruby
-class AddCheckConstraint < ActiveRecord::Migration[6.1]
+class AddCheckConstraint < ActiveRecord::Migration[7.1]
   def change
     add_check_constraint :users, "price > 0", name: "price_check", validate: false
   end
@@ -341,7 +374,7 @@ end
 Then validate them in a separate migration.
 
 ```ruby
-class ValidateCheckConstraint < ActiveRecord::Migration[6.1]
+class ValidateCheckConstraint < ActiveRecord::Migration[7.1]
   def change
     validate_check_constraint :users, name: "price_check"
   end
@@ -352,264 +385,315 @@ end
 
 [Let us know](https://github.com/ankane/strong_migrations/issues/new) if you have a safe way to do this (check constraints can be added with `NOT ENFORCED`, but enforcing blocks writes).
 
-### Setting NOT NULL on an existing column
+### Executing SQL directly
+
+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.1]
+  def change
+    safety_assured { execute "..." }
+  end
+end
+```
+
+### Adding an index non-concurrently
 
 :turtle: Safe by default available
 
 #### Bad
 
-Setting `NOT NULL` on an existing column blocks reads and writes while every row is checked.
+In Postgres, adding an index non-concurrently blocks writes.
 
 ```ruby
-class SetSomeColumnNotNull < ActiveRecord::Migration[6.1]
+class AddSomeIndexToUsers < ActiveRecord::Migration[7.1]
   def change
-    change_column_null :users, :some_column, false
+    add_index :users, :some_column
   end
 end
 ```
 
-#### Good - Postgres
-
-Instead, add a check constraint.
+#### Good
 
-For Rails 6.1, use:
+Add indexes concurrently.
 
 ```ruby
-class SetSomeColumnNotNull < ActiveRecord::Migration[6.1]
+class AddSomeIndexToUsers < ActiveRecord::Migration[7.1]
+  disable_ddl_transaction!
+
   def change
-    add_check_constraint :users, "some_column IS NOT NULL", name: "users_some_column_null", validate: false
+    add_index :users, :some_column, algorithm: :concurrently
   end
 end
 ```
 
-For Rails < 6.1, use:
+If you forget `disable_ddl_transaction!`, the migration will fail. Also, note that indexes on new tables (those created in the same migration) don’t require this.
+
+With [gindex](https://github.com/ankane/gindex), you can generate an index migration instantly with:
+
+```sh
+rails g index table column
+```
+
+### Adding a reference
+
+:turtle: Safe by default available
+
+#### Bad
+
+Rails adds an index non-concurrently to references by default, which blocks writes in Postgres.
 
 ```ruby
-class SetSomeColumnNotNull < ActiveRecord::Migration[6.0]
+class AddReferenceToUsers < ActiveRecord::Migration[7.1]
   def change
-    safety_assured do
-      execute 'ALTER TABLE "users" ADD CONSTRAINT "users_some_column_null" CHECK ("some_column" IS NOT NULL) NOT VALID'
-    end
+    add_reference :users, :city
   end
 end
 ```
 
-Then validate it in a separate migration. A `NOT NULL` check constraint is [functionally equivalent](https://medium.com/doctolib/adding-a-not-null-constraint-on-pg-faster-with-minimal-locking-38b2c00c4d1c) to setting `NOT NULL` on the column (but it won’t show up in `schema.rb` in Rails < 6.1). In Postgres 12+, once the check constraint is validated, you can safely set `NOT NULL` on the column and drop the check constraint.
+#### Good
 
-For Rails 6.1, use:
+Make sure the index is added concurrently.
 
 ```ruby
-class ValidateSomeColumnNotNull < ActiveRecord::Migration[6.1]
-  def change
-    validate_check_constraint :users, name: "users_some_column_null"
+class AddReferenceToUsers < ActiveRecord::Migration[7.1]
+  disable_ddl_transaction!
 
-    # in Postgres 12+, you can then safely set NOT NULL on the column
-    change_column_null :users, :some_column, false
-    remove_check_constraint :users, name: "users_some_column_null"
+  def change
+    add_reference :users, :city, index: {algorithm: :concurrently}
   end
 end
 ```
 
-For Rails < 6.1, use:
+### Adding a foreign key
+
+:turtle: Safe by default available
+
+#### Bad
+
+In Postgres, adding a foreign key blocks writes on both tables.
 
 ```ruby
-class ValidateSomeColumnNotNull < ActiveRecord::Migration[6.0]
+class AddForeignKeyOnUsers < ActiveRecord::Migration[7.1]
   def change
-    safety_assured do
-      execute 'ALTER TABLE "users" VALIDATE CONSTRAINT "users_some_column_null"'
-    end
-
-    # in Postgres 12+, you can then safely set NOT NULL on the column
-    change_column_null :users, :some_column, false
-    safety_assured do
-      execute 'ALTER TABLE "users" DROP CONSTRAINT "users_some_column_null"'
-    end
+    add_foreign_key :users, :orders
   end
 end
 ```
 
-#### Good - MySQL and MariaDB
+or
 
-[Let us know](https://github.com/ankane/strong_migrations/issues/new) if you have a safe way to do this.
+```ruby
+class AddReferenceToUsers < ActiveRecord::Migration[7.1]
+  def change
+    add_reference :users, :order, foreign_key: true
+  end
+end
+```
 
-### Executing SQL directly
+#### Good
 
-Strong Migrations can’t ensure safety for raw SQL statements. Make really sure that what you’re doing is safe, then use:
+Add the foreign key without validating existing rows:
 
 ```ruby
-class ExecuteSQL < ActiveRecord::Migration[6.1]
+class AddForeignKeyOnUsers < ActiveRecord::Migration[7.1]
   def change
-    safety_assured { execute "..." }
+    add_foreign_key :users, :orders, validate: false
   end
 end
 ```
 
-### Adding an index non-concurrently
+Then validate them in a separate migration.
 
-:turtle: Safe by default available
+```ruby
+class ValidateForeignKeyOnUsers < ActiveRecord::Migration[7.1]
+  def change
+    validate_foreign_key :users, :orders
+  end
+end
+```
+
+### Adding a unique constraint
 
 #### Bad
 
-In Postgres, adding an index non-concurrently blocks writes.
+In Postgres, adding a unique constraint creates a unique index, which blocks reads and writes.
 
 ```ruby
-class AddSomeIndexToUsers < ActiveRecord::Migration[6.1]
+class AddUniqueContraint < ActiveRecord::Migration[7.1]
   def change
-    add_index :users, :some_column
+    add_unique_constraint :users, :some_column
   end
 end
 ```
 
 #### Good
 
-Add indexes concurrently.
+Create a unique index concurrently, then use it for the constraint.
 
 ```ruby
-class AddSomeIndexToUsers < ActiveRecord::Migration[6.1]
+class AddUniqueContraint < ActiveRecord::Migration[7.1]
   disable_ddl_transaction!
 
-  def change
-    add_index :users, :some_column, algorithm: :concurrently
+  def up
+    add_index :users, :some_column, unique: true, algorithm: :concurrently
+    add_unique_constraint :users, using_index: "index_users_on_some_column"
+  end
+
+  def down
+    remove_unique_constraint :users, :some_column
   end
 end
 ```
 
-If you forget `disable_ddl_transaction!`, the migration will fail. Also, note that indexes on new tables (those created in the same migration) don’t require this.
+### Adding an exclusion constraint
 
-With [gindex](https://github.com/ankane/gindex), you can generate an index migration instantly with:
+#### Bad
 
-```sh
-rails g index table column
+In Postgres, adding an exclusion constraint blocks reads and writes while every row is checked.
+
+```ruby
+class AddExclusionContraint < ActiveRecord::Migration[7.1]
+  def change
+    add_exclusion_constraint :users, "number WITH =", using: :gist
+  end
+end
 ```
 
-### Adding a reference
+#### Good
 
-:turtle: Safe by default available
+[Let us know](https://github.com/ankane/strong_migrations/issues/new) if you have a safe way to do this (exclusion constraints cannot be marked `NOT VALID`).
+
+### Adding a json column
 
 #### Bad
 
-Rails adds an index non-concurrently to references by default, which blocks writes in Postgres.
+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 AddReferenceToUsers < ActiveRecord::Migration[6.1]
+class AddPropertiesToUsers < ActiveRecord::Migration[7.1]
   def change
-    add_reference :users, :city
+    add_column :users, :properties, :json
   end
 end
 ```
 
 #### Good
 
-Make sure the index is added concurrently.
+Use `jsonb` instead.
 
 ```ruby
-class AddReferenceToUsers < ActiveRecord::Migration[6.1]
-  disable_ddl_transaction!
-
+class AddPropertiesToUsers < ActiveRecord::Migration[7.1]
   def change
-    add_reference :users, :city, index: {algorithm: :concurrently}
+    add_column :users, :properties, :jsonb
   end
 end
 ```
 
-### Adding a foreign key
+### Setting NOT NULL on an existing column
 
 :turtle: Safe by default available
 
 #### Bad
 
-In Postgres, adding a foreign key blocks writes on both tables.
+In Postgres, setting `NOT NULL` on an existing column blocks reads and writes while every row is checked.
 
 ```ruby
-class AddForeignKeyOnUsers < ActiveRecord::Migration[6.1]
+class SetSomeColumnNotNull < ActiveRecord::Migration[7.1]
   def change
-    add_foreign_key :users, :orders
-  end
-end
-```
-
-or
-
-```ruby
-class AddReferenceToUsers < ActiveRecord::Migration[6.1]
-  def change
-    add_reference :users, :order, foreign_key: true
+    change_column_null :users, :some_column, false
   end
 end
 ```
 
 #### Good
 
-Add the foreign key without validating existing rows, then validate them in a separate migration.
+Instead, add a check constraint.
 
-For Rails 5.2+, use:
+For Rails 6.1+, use:
 
 ```ruby
-class AddForeignKeyOnUsers < ActiveRecord::Migration[6.1]
+class SetSomeColumnNotNull < ActiveRecord::Migration[7.1]
   def change
-    add_foreign_key :users, :orders, validate: false
+    add_check_constraint :users, "some_column IS NOT NULL", name: "users_some_column_null", validate: false
   end
 end
 ```
 
-Then:
+For Rails < 6.1, use:
 
 ```ruby
-class ValidateForeignKeyOnUsers < ActiveRecord::Migration[6.1]
+class SetSomeColumnNotNull < ActiveRecord::Migration[6.0]
   def change
-    validate_foreign_key :users, :orders
+    safety_assured do
+      execute 'ALTER TABLE "users" ADD CONSTRAINT "users_some_column_null" CHECK ("some_column" IS NOT NULL) NOT VALID'
+    end
   end
 end
 ```
 
-For Rails < 5.2, use:
+Then validate it in a separate migration. A `NOT NULL` check constraint is [functionally equivalent](https://medium.com/doctolib/adding-a-not-null-constraint-on-pg-faster-with-minimal-locking-38b2c00c4d1c) to setting `NOT NULL` on the column (but it won’t show up in `schema.rb` in Rails < 6.1). In Postgres 12+, once the check constraint is validated, you can safely set `NOT NULL` on the column and drop the check constraint.
+
+For Rails 6.1+, use:
 
 ```ruby
-class AddForeignKeyOnUsers < ActiveRecord::Migration[5.1]
+class ValidateSomeColumnNotNull < ActiveRecord::Migration[7.1]
   def change
-    safety_assured do
-      execute 'ALTER TABLE "users" ADD CONSTRAINT "fk_rails_c1e9b98e31" FOREIGN KEY ("order_id") REFERENCES "orders" ("id") NOT VALID'
-    end
+    validate_check_constraint :users, name: "users_some_column_null"
+
+    # in Postgres 12+, you can then safely set NOT NULL on the column
+    change_column_null :users, :some_column, false
+    remove_check_constraint :users, name: "users_some_column_null"
   end
 end
 ```
 
-Then:
+For Rails < 6.1, use:
 
 ```ruby
-class ValidateForeignKeyOnUsers < ActiveRecord::Migration[5.1]
+class ValidateSomeColumnNotNull < ActiveRecord::Migration[6.0]
   def change
     safety_assured do
-      execute 'ALTER TABLE "users" VALIDATE CONSTRAINT "fk_rails_c1e9b98e31"'
+      execute 'ALTER TABLE "users" VALIDATE CONSTRAINT "users_some_column_null"'
+    end
+
+    # in Postgres 12+, you can then safely set NOT NULL on the column
+    change_column_null :users, :some_column, false
+    safety_assured do
+      execute 'ALTER TABLE "users" DROP CONSTRAINT "users_some_column_null"'
     end
   end
 end
 ```
 
-### Adding a json column
+### Changing the default value of a column
 
 #### Bad
 
-In Postgres, there’s no equality operator for the `json` column type, which can cause errors for existing `SELECT DISTINCT` queries in your application.
+Rails < 7 enables partial writes by default, which can cause incorrect values to be inserted when changing the default value of a column.
 
 ```ruby
-class AddPropertiesToUsers < ActiveRecord::Migration[6.1]
+class ChangeSomeColumnDefault < ActiveRecord::Migration[6.1]
   def change
-    add_column :users, :properties, :json
+    change_column_default :users, :some_column, from: "old", to: "new"
   end
 end
+
+User.create!(some_column: "old") # can insert "new"
 ```
 
 #### Good
 
-Use `jsonb` instead.
+Disable partial writes in `config/application.rb`. For Rails < 7, use:
 
 ```ruby
-class AddPropertiesToUsers < ActiveRecord::Migration[6.1]
-  def change
-    add_column :users, :properties, :jsonb
-  end
-end
+config.active_record.partial_writes = false
+```
+
+For Rails 7+, use:
+
+```ruby
+config.active_record.partial_inserts = false
 ```
 
 ### Keeping non-unique indexes to three columns or less
@@ -619,7 +703,7 @@ end
 Adding a non-unique index with more than three columns rarely improves performance.
 
 ```ruby
-class AddSomeIndexToUsers < ActiveRecord::Migration[6.1]
+class AddSomeIndexToUsers < ActiveRecord::Migration[7.1]
   def change
     add_index :users, [:a, :b, :c, :d]
   end
@@ -631,7 +715,7 @@ end
 Instead, start an index with columns that narrow down the results the most.
 
 ```ruby
-class AddSomeIndexToUsers < ActiveRecord::Migration[6.1]
+class AddSomeIndexToUsers < ActiveRecord::Migration[7.1]
   def change
     add_index :users, [:b, :d]
   end
@@ -645,7 +729,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[6.1]
+class MySafeMigration < ActiveRecord::Migration[7.1]
   def change
     safety_assured { remove_column :users, :some_column }
   end
@@ -703,7 +787,7 @@ Disable specific checks with:
 StrongMigrations.disable_check(:add_index)
 ```
 
-Check the [source code](https://github.com/ankane/strong_migrations/blob/master/lib/strong_migrations.rb) for the list of keys.
+Check the [source code](https://github.com/ankane/strong_migrations/blob/master/lib/strong_migrations/error_messages.rb) for the list of keys.
 
 ## Down Migrations / Rollbacks
 
@@ -721,7 +805,7 @@ To customize specific messages, create an initializer with:
 StrongMigrations.error_messages[:add_column_default] = "Your custom instructions"
 ```
 
-Check the [source code](https://github.com/ankane/strong_migrations/blob/master/lib/strong_migrations.rb) for the list of keys.
+Check the [source code](https://github.com/ankane/strong_migrations/blob/master/lib/strong_migrations/error_messages.rb) for the list of keys.
 
 ## Migration Timeouts
 
@@ -786,12 +870,31 @@ production:
 
 For HTTP connections, Redis, and other services, check out [this guide](https://github.com/ankane/the-ultimate-guide-to-ruby-timeouts).
 
+## Lock Timeout Retries [experimental]
+
+There’s the option to automatically retry statements for migrations when the lock timeout is reached. Here’s how it works:
+
+- If a lock timeout happens outside a transaction, the statement is retried
+- If it happens inside the DDL transaction, the entire migration is retried (only applicable to Postgres)
+
+Add to `config/initializers/strong_migrations.rb`:
+
+```ruby
+StrongMigrations.lock_timeout_retries = 3
+```
+
+Set the delay between retries with:
+
+```ruby
+StrongMigrations.lock_timeout_retry_delay = 10.seconds
+```
+
 ## Existing Migrations
 
 To mark migrations as safe that were created before installing this gem, create an initializer with:
 
 ```ruby
-StrongMigrations.start_after = 20170101000000
+StrongMigrations.start_after = 20230101000000
 ```
 
 Use the version from your latest migration.
@@ -808,6 +911,12 @@ The major version works well for Postgres, while the full version is recommended
 
 For safety, this option only affects development and test environments. In other environments, the actual server version is always used.
 
+If your app has multiple databases with different versions, with Rails 6.1+, you can use:
+
+```ruby
+StrongMigrations.target_version = {primary: 13, catalog: 15}
+```
+
 ## Analyze Tables
 
 Analyze tables automatically (to update planner statistics) after an index is added. Create an initializer with:
@@ -818,19 +927,18 @@ StrongMigrations.auto_analyze = true
 
 ## Faster Migrations
 
-Only dump the schema when adding a new migration. If you use Git, create an initializer with:
+Only dump the schema when adding a new migration. If you use Git, add to `config/environments/development.rb`:
 
-```ruby
-ActiveRecord::Base.dump_schema_after_migration = Rails.env.development? &&
-  `git status db/migrate/ --porcelain`.present?
+```rb
+config.active_record.dump_schema_after_migration = `git status db/migrate/ --porcelain`.present?
 ```
 
 ## Schema Sanity
 
-Columns can flip order in `db/schema.rb` when you have multiple developers. One way to prevent this is to [alphabetize them](https://www.pgrs.net/2008/03/12/alphabetize-schema-rb-columns/). Add to the end of your `Rakefile`:
+Columns can flip order in `db/schema.rb` when you have multiple developers. One way to prevent this is to [alphabetize them](https://www.pgrs.net/2008/03/12/alphabetize-schema-rb-columns/). Add to `config/initializers/strong_migrations.rb`:
 
 ```ruby
-task "db:schema:dump": "strong_migrations:alphabetize_columns"
+StrongMigrations.alphabetize_schema = true
 ```
 
 ## Permissions