README.md in strong_migrations-2.0.2 vs README.md in strong_migrations-2.1.0

- old
+ new

@@ -349,10 +349,12 @@ end ``` ### Backfilling data +Note: Strong Migrations does not detect dangerous backfills. + #### Bad 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 @@ -381,10 +383,12 @@ end end end ``` +Note: If backfilling with a method other than `update_all`, use `User.reset_column_information` to ensure the model has up-to-date column information. + ### Adding an index non-concurrently :turtle: Safe by default available #### Bad @@ -606,15 +610,20 @@ Then validate it in a separate migration. Once the check constraint is validated, you can safely set `NOT NULL` on the column and drop the check constraint. ```ruby class ValidateSomeColumnNotNull < ActiveRecord::Migration[7.2] - def change + def up validate_check_constraint :users, name: "users_some_column_null" change_column_null :users, :some_column, false remove_check_constraint :users, name: "users_some_column_null" end + + def down + add_check_constraint :users, "some_column IS NOT NULL", name: "users_some_column_null", validate: false + change_column_null :users, :some_column, true + end end ``` ### Adding a column with a volatile default value @@ -721,11 +730,11 @@ Certain methods like `execute` and `change_table` cannot be inspected and are prevented from running by default. Make sure what you’re doing is really safe and use this pattern. ## Safe by Default -Make operations safe by default. +Make certain operations safe by default. This allows you to write the code under the "Bad" section, but the migration will be performed as if you had written the "Good" version. - adding and removing an index - adding a foreign key - adding a check constraint - setting NOT NULL on an existing column @@ -770,10 +779,20 @@ StrongMigrations.disable_check(:add_index) ``` Check the [source code](https://github.com/ankane/strong_migrations/blob/master/lib/strong_migrations/error_messages.rb) for the list of keys. +## Skip Databases + +Skip checks and other functionality for specific databases with: + +```ruby +StrongMigrations.skip_database(:catalog) +``` + +Note: This does not affect `alphabetize_schema`. + ## Down Migrations / Rollbacks By default, checks are disabled when migrating down. Enable them with: ```ruby @@ -851,10 +870,24 @@ lock_wait_timeout: 10 # sec ``` 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] +## Invalid Indexes + +In Postgres, adding an index non-concurrently can leave behind an invalid index if the lock timeout is reached. Running the migration again can result in an error. + +To automatically remove the invalid index when the migration runs again, use: + +```ruby +StrongMigrations.remove_invalid_indexes = true +``` + +Note: This feature is experimental. + +## Lock Timeout Retries + +Note: This feature is 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)