strong_migrations 0.7.8 → 1.0.0

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: 38cd87929d4889113bc2cc13aa786965c8b86fadf05d1d0439e2c927becfef61
-  data.tar.gz: 0f17d511058c0bd1852adcddf9a2e978b8e407002ddf201be7aedb6c797dd294
+  metadata.gz: a22e260ec0e3e09954c65535725a3ddc4439b9cf94182a21cf5963e12d8485fe
+  data.tar.gz: 865633da561d77e615df16a9a00f8524a95bf73edc5590e3932855aaf544d4f7
 SHA512:
-  metadata.gz: d28ef8e2d9cd837fac0a5e72743e1b88e7ef268ce9660e5119c27b50cc0e5215ae20e36a8be570a987e967f4a8bdf47ccd68eb6ee66f7188b787d3d64596c514
-  data.tar.gz: f1e012eed6af3ebcc0ffbf5a1f4b90438ee054597f41a9420a3645af8535fff4cb3ef64b69abdc547fbf20a14658b03f0492395ad46c6bfc79b26726424c81c4
+  metadata.gz: f9b4df7a67aae2c8e1f7c58327b0e7e298261a33d9810dff4b5634bee3e000f1b26e64ad7b3997c8fc6c1cfef3a5cbeabe35ecbe508ed902679e3c9a720ecfb8
+  data.tar.gz: f4a7ecb6e64c40d1be1025a978387b94b9c2e47897cc25568c32dc32043292bc8fe14c9e6471108a4d84a1b1704459707f4fcf8a25227b7a86d8bcf2237dc19d

data/CHANGELOG.md

@@ -1,3 +1,41 @@
+## 1.0.0 (2022-03-21)
+
+New safe operations with MySQL and MariaDB
+
+- Setting `NOT NULL` on an existing column with strict mode enabled
+
+New safe operations with Postgres
+
+- Changing between `text` and `citext` when not indexed
+- Changing a `string` column to a `citext` column when not indexed
+- Changing a `citext` column to a `string` column with no `:limit` when not indexed
+- Changing a `cidr` column to an `inet` column
+- Increasing `:precision` of an `interval` or `time` column
+
+New unsafe operations with Postgres
+
+- Adding a column with a callable default value
+- Decreasing `:precision` of a `datetime` column
+- Decreasing `:limit` of a `timestamptz` column
+- Passing a default value to `change_column_null`
+
+Other
+
+- Added experimental support for lock timeout retries
+- Added `target_sql_mode` option
+- Added error for `change_column_null` with default value with `safe_by_default` option
+- Fixed instructions for `remove_columns` with options
+- Dropped support for Postgres < 10, MySQL < 5.7, and MariaDB < 10.2
+
+## 0.8.0 (2022-02-09)
+
+- Fixed error with versioned schema with Active Record 7.0.2+
+- Dropped support for Ruby < 2.6 and Active Record < 5.2
+
+## 0.7.9 (2021-12-15)
+
+- Fixed error with multiple databases with Active Record 7
+
 ## 0.7.8 (2021-08-03)
 
 - Fixed issue with `add_reference ..., foreign_key: {to_table: ...}` with `safe_by_default`

data/LICENSE.txt

@@ -1,4 +1,4 @@
-Copyright (c) 2013 Bob Remeika and David Waller, 2015-2021 Andrew Kane
+Copyright (c) 2013 Bob Remeika and David Waller, 2015-2022 Andrew Kane
 
 MIT License
 

data/README.md

@@ -4,7 +4,7 @@ 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)
 
@@ -15,7 +15,7 @@ Supports for PostgreSQL, MySQL, and MariaDB
 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.0]
   def change
     safety_assured { remove_column :users, :name }
   end
@@ -67,7 +67,6 @@ Potentially dangerous operations:
 - [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:
@@ -76,6 +75,7 @@ Postgres-specific checks:
 - [adding a reference](#adding-a-reference)
 - [adding a foreign key](#adding-a-foreign-key)
 - [adding a json column](#adding-a-json-column)
+- [setting NOT NULL on an existing column](#setting-not-null-on-an-existing-column)
 
 Best practices:
 
@@ -90,7 +90,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.0]
   def change
     remove_column :users, :some_column
   end
@@ -111,7 +111,7 @@ end
 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.0]
     def change
       safety_assured { remove_column :users, :some_column }
     end
@@ -119,6 +119,7 @@ end
   ```
 
 4. Deploy and run migration
+5. Remove the line added in step 1
 
 ### Adding a column with a default value
 
@@ -127,7 +128,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[6.1]
+class AddSomeColumnToUsers < ActiveRecord::Migration[7.0]
   def change
     add_column :users, :some_column, :text, default: "default_value"
   end
@@ -141,7 +142,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[6.1]
+class AddSomeColumnToUsers < ActiveRecord::Migration[7.0]
   def up
     add_column :users, :some_column, :text
     change_column_default :users, :some_column, "default_value"
@@ -162,7 +163,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.0]
   def change
     add_column :users, :some_column, :text
     User.update_all some_column: "default_value"
@@ -177,7 +178,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.0]
   disable_ddl_transaction!
 
   def up
@@ -196,26 +197,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.0]
   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 255 up to 255, increasing `:limit` from over 255 to the max
 
 #### Good
 
@@ -235,7 +243,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.0]
   def change
     rename_column :users, :some_column, :new_name
   end
@@ -260,7 +268,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.0]
   def change
     rename_table :users, :customers
   end
@@ -285,7 +293,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.0]
   def change
     create_table :users, force: true do |t|
       # ...
@@ -299,7 +307,7 @@ end
 Create tables without the `force` option.
 
 ```ruby
-class CreateUsers < ActiveRecord::Migration[6.1]
+class CreateUsers < ActiveRecord::Migration[7.0]
   def change
     create_table :users do |t|
       # ...
@@ -319,7 +327,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.0]
   def change
     add_check_constraint :users, "price > 0", name: "price_check"
   end
@@ -331,7 +339,7 @@ end
 Add the check constraint without validating existing rows:
 
 ```ruby
-class AddCheckConstraint < ActiveRecord::Migration[6.1]
+class AddCheckConstraint < ActiveRecord::Migration[7.0]
   def change
     add_check_constraint :users, "price > 0", name: "price_check", validate: false
   end
@@ -341,7 +349,7 @@ end
 Then validate them in a separate migration.
 
 ```ruby
-class ValidateCheckConstraint < ActiveRecord::Migration[6.1]
+class ValidateCheckConstraint < ActiveRecord::Migration[7.0]
   def change
     validate_check_constraint :users, name: "price_check"
   end
@@ -352,92 +360,12 @@ 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
-
-:turtle: Safe by default available
-
-#### Bad
-
-Setting `NOT NULL` on an existing column blocks reads and writes while every row is checked.
-
-```ruby
-class SetSomeColumnNotNull < ActiveRecord::Migration[6.1]
-  def change
-    change_column_null :users, :some_column, false
-  end
-end
-```
-
-#### Good - Postgres
-
-Instead, add a check constraint.
-
-For Rails 6.1, use:
-
-```ruby
-class SetSomeColumnNotNull < ActiveRecord::Migration[6.1]
-  def change
-    add_check_constraint :users, "some_column IS NOT NULL", name: "users_some_column_null", validate: false
-  end
-end
-```
-
-For Rails < 6.1, use:
-
-```ruby
-class SetSomeColumnNotNull < ActiveRecord::Migration[6.0]
-  def change
-    safety_assured do
-      execute 'ALTER TABLE "users" ADD CONSTRAINT "users_some_column_null" CHECK ("some_column" IS NOT NULL) NOT VALID'
-    end
-  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.
-
-For Rails 6.1, use:
-
-```ruby
-class ValidateSomeColumnNotNull < ActiveRecord::Migration[6.1]
-  def change
-    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
-```
-
-For Rails < 6.1, use:
-
-```ruby
-class ValidateSomeColumnNotNull < ActiveRecord::Migration[6.0]
-  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
-  end
-end
-```
-
-#### Good - MySQL and MariaDB
-
-[Let us know](https://github.com/ankane/strong_migrations/issues/new) if you have a safe way to do this.
-
 ### 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[6.1]
+class ExecuteSQL < ActiveRecord::Migration[7.0]
   def change
     safety_assured { execute "..." }
   end
@@ -453,7 +381,7 @@ end
 In Postgres, adding an index non-concurrently blocks writes.
 
 ```ruby
-class AddSomeIndexToUsers < ActiveRecord::Migration[6.1]
+class AddSomeIndexToUsers < ActiveRecord::Migration[7.0]
   def change
     add_index :users, :some_column
   end
@@ -465,7 +393,7 @@ end
 Add indexes concurrently.
 
 ```ruby
-class AddSomeIndexToUsers < ActiveRecord::Migration[6.1]
+class AddSomeIndexToUsers < ActiveRecord::Migration[7.0]
   disable_ddl_transaction!
 
   def change
@@ -491,7 +419,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[6.1]
+class AddReferenceToUsers < ActiveRecord::Migration[7.0]
   def change
     add_reference :users, :city
   end
@@ -503,7 +431,7 @@ end
 Make sure the index is added concurrently.
 
 ```ruby
-class AddReferenceToUsers < ActiveRecord::Migration[6.1]
+class AddReferenceToUsers < ActiveRecord::Migration[7.0]
   disable_ddl_transaction!
 
   def change
@@ -521,7 +449,7 @@ end
 In Postgres, adding a foreign key blocks writes on both tables.
 
 ```ruby
-class AddForeignKeyOnUsers < ActiveRecord::Migration[6.1]
+class AddForeignKeyOnUsers < ActiveRecord::Migration[7.0]
   def change
     add_foreign_key :users, :orders
   end
@@ -531,7 +459,7 @@ end
 or
 
 ```ruby
-class AddReferenceToUsers < ActiveRecord::Migration[6.1]
+class AddReferenceToUsers < ActiveRecord::Migration[7.0]
   def change
     add_reference :users, :order, foreign_key: true
   end
@@ -540,74 +468,124 @@ end
 
 #### Good
 
-Add the foreign key without validating existing rows, then validate them in a separate migration.
-
-For Rails 5.2+, use:
+Add the foreign key without validating existing rows:
 
 ```ruby
-class AddForeignKeyOnUsers < ActiveRecord::Migration[6.1]
+class AddForeignKeyOnUsers < ActiveRecord::Migration[7.0]
   def change
     add_foreign_key :users, :orders, validate: false
   end
 end
 ```
 
-Then:
+Then validate them in a separate migration.
 
 ```ruby
-class ValidateForeignKeyOnUsers < ActiveRecord::Migration[6.1]
+class ValidateForeignKeyOnUsers < ActiveRecord::Migration[7.0]
   def change
     validate_foreign_key :users, :orders
   end
 end
 ```
 
-For Rails < 5.2, use:
+### Adding a json 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.
 
 ```ruby
-class AddForeignKeyOnUsers < ActiveRecord::Migration[5.1]
+class AddPropertiesToUsers < ActiveRecord::Migration[7.0]
   def change
-    safety_assured do
-      execute 'ALTER TABLE "users" ADD CONSTRAINT "fk_rails_c1e9b98e31" FOREIGN KEY ("order_id") REFERENCES "orders" ("id") NOT VALID'
-    end
+    add_column :users, :properties, :json
   end
 end
 ```
 
-Then:
+#### Good
+
+Use `jsonb` instead.
 
 ```ruby
-class ValidateForeignKeyOnUsers < ActiveRecord::Migration[5.1]
+class AddPropertiesToUsers < ActiveRecord::Migration[7.0]
   def change
-    safety_assured do
-      execute 'ALTER TABLE "users" VALIDATE CONSTRAINT "fk_rails_c1e9b98e31"'
-    end
+    add_column :users, :properties, :jsonb
   end
 end
 ```
 
-### Adding a json column
+### Setting NOT NULL on an existing column
+
+:turtle: Safe by default available
 
 #### 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.
+In Postgres, setting `NOT NULL` on an existing column blocks reads and writes while every row is checked.
 
 ```ruby
-class AddPropertiesToUsers < ActiveRecord::Migration[6.1]
+class SetSomeColumnNotNull < ActiveRecord::Migration[7.0]
   def change
-    add_column :users, :properties, :json
+    change_column_null :users, :some_column, false
   end
 end
 ```
 
 #### Good
 
-Use `jsonb` instead.
+Instead, add a check constraint.
+
+For Rails 6.1, use:
 
 ```ruby
-class AddPropertiesToUsers < ActiveRecord::Migration[6.1]
+class SetSomeColumnNotNull < ActiveRecord::Migration[7.0]
   def change
-    add_column :users, :properties, :jsonb
+    add_check_constraint :users, "some_column IS NOT NULL", name: "users_some_column_null", validate: false
+  end
+end
+```
+
+For Rails < 6.1, use:
+
+```ruby
+class SetSomeColumnNotNull < ActiveRecord::Migration[6.0]
+  def change
+    safety_assured do
+      execute 'ALTER TABLE "users" ADD CONSTRAINT "users_some_column_null" CHECK ("some_column" IS NOT NULL) NOT VALID'
+    end
+  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.
+
+For Rails 6.1, use:
+
+```ruby
+class ValidateSomeColumnNotNull < ActiveRecord::Migration[7.0]
+  def change
+    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
+```
+
+For Rails < 6.1, use:
+
+```ruby
+class ValidateSomeColumnNotNull < ActiveRecord::Migration[6.0]
+  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
   end
 end
 ```
@@ -619,7 +597,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.0]
   def change
     add_index :users, [:a, :b, :c, :d]
   end
@@ -631,7 +609,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.0]
   def change
     add_index :users, [:b, :d]
   end
@@ -645,7 +623,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.0]
   def change
     safety_assured { remove_column :users, :some_column }
   end
@@ -721,7 +699,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
 
@@ -743,6 +721,25 @@ ALTER ROLE myuser SET statement_timeout = '1h';
 
 Note: If you use PgBouncer in transaction mode, you must set timeouts on the database user.
 
+## Lock Timeout Retries [experimental]
+
+There’s the option to automatically retry statements 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
+```
+
 ## App Timeouts
 
 We recommend adding timeouts to `config/database.yml` to prevent connections from hanging and individual queries from taking up too many resources in controllers, jobs, the Rails console, and other places.

data/lib/strong_migrations/adapters/abstract_adapter.rb

@@ -0,0 +1,61 @@
+module StrongMigrations
+  module Adapters
+    class AbstractAdapter
+      def initialize(checker)
+        @checker = checker
+      end
+
+      def name
+        "Unknown"
+      end
+
+      def min_version
+      end
+
+      def set_statement_timeout(timeout)
+        raise StrongMigrations::Error, "Statement timeout not supported for this database"
+      end
+
+      def set_lock_timeout(timeout)
+        raise StrongMigrations::Error, "Lock timeout not supported for this database"
+      end
+
+      def check_lock_timeout(limit)
+        # do nothing
+      end
+
+      def add_column_default_safe?
+        false
+      end
+
+      def change_type_safe?(table, column, type, options, existing_column, existing_type)
+        false
+      end
+
+      def rewrite_blocks
+        "reads and writes"
+      end
+
+      private
+
+      def connection
+        @checker.send(:connection)
+      end
+
+      def select_all(statement)
+        connection.select_all(statement)
+      end
+
+      def target_version(target_version)
+        target_version ||= StrongMigrations.target_version
+        version =
+          if target_version && StrongMigrations.developer_env?
+            target_version.to_s
+          else
+            yield
+          end
+        Gem::Version.new(version)
+      end
+    end
+  end
+end