online_migrations 0.19.3 → 0.19.5

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: 4d8223e51d4016b3752a738ecbc04cc200c94ee44dd3d91a1be2aefbc74060a9
-  data.tar.gz: bbaa8a04c4b730ac33e1503c59782658f6810f9782b4f882ab2b19bd0e0402d2
+  metadata.gz: 9cb60167b94f5ce8556b3f9835949c86f9be4c523eb2c35494de578dea31a2bf
+  data.tar.gz: 20d9d6fcf509bbc25987a2e3bce165c927cacd03502aa908c02aba37dd284774
 SHA512:
-  metadata.gz: 878031d1e81e5a069500e4c9c8f0d2bb9b9b60320e07ce101a7ae8680556a6a8114de4d0f6bf092340ec3651f9bbbb74fdc6e6453db39be3c22f6846b5a2ad94
-  data.tar.gz: 143a618f2d46a8a452c9f32ca87f44e47dffe5268bae00dcff008f54865cf272e20bb6aa4af7243cf642a195e64e9aed8269660f1658ebb3440bff12eeed37df
+  metadata.gz: 03f82fe701b6d2145963f1f2220ac9ed127dc826885455134afc3bb547197d21a1c0307156b6d8b5402c0a521332328eebf45d96a3bb2183804055d866cd3af2
+  data.tar.gz: 94f0bfd73299897757a8b836a9cbd995bb9313c971a6e0076079b783955c26da239098b84df391096128fc0e060ba66ca69e61e16a84013c12d613c7fe4064ce

data/CHANGELOG.md

@@ -1,5 +1,22 @@
 ## master (unreleased)
 
+## 0.19.5 (2024-09-20)
+
+- Fix `add_reference_concurrently` when adding polymorphic references
+
+## 0.19.4 (2024-09-02)
+
+- Fix an edge case for background schema migrations
+
+    If you use background schema migrations, you need to run
+    ```
+    bin/rails generate online_migrations:upgrade
+    bin/rails db:migrate
+    ```
+
+- Fix retrying running stuck background schema migrations
+- Fix renaming columns for tables with long names
+
 ## 0.19.3 (2024-08-09)
 
 - Fix idempotency for `add_index`/`remove_index` for expression indexes

data/README.md

@@ -67,7 +67,7 @@ An operation is classified as dangerous if it either:
 Consider the following migration:
 
 ```ruby
-class AddAdminToUsers < ActiveRecord::Migration[7.1]
+class AddAdminToUsers < ActiveRecord::Migration[7.2]
   def change
     add_column :users, :admin, :boolean, default: false, null: false
   end
@@ -79,7 +79,7 @@ If the `users` table is large, running this migration on a live PostgreSQL < 11
 A safer approach would be to run something like the following:
 
 ```ruby
-class AddAdminToUsers < ActiveRecord::Migration[7.1]
+class AddAdminToUsers < ActiveRecord::Migration[7.2]
   # Do not wrap the migration in a transaction so that locks are held for a shorter time.
   disable_ddl_transaction!
 
@@ -124,7 +124,7 @@ A safer approach is to:
 
 add_column_with_default takes care of all this steps:
 
-class AddAdminToUsers < ActiveRecord::Migration[7.1]
+class AddAdminToUsers < ActiveRecord::Migration[7.2]
   disable_ddl_transaction!
 
   def change
@@ -178,7 +178,7 @@ You can also add [custom checks](docs/configuring.md#custom-checks) or [disable
 Active Record caches database columns at runtime, so if you drop a column, it can cause exceptions until your app reboots.
 
 ```ruby
-class RemoveNameFromUsers < ActiveRecord::Migration[7.1]
+class RemoveNameFromUsers < ActiveRecord::Migration[7.2]
   def change
     remove_column :users, :name
   end
@@ -199,7 +199,7 @@ end
 3. Wrap column removing in a `safety_assured` block:
 
    ```ruby
-   class RemoveNameFromUsers < ActiveRecord::Migration[7.1]
+   class RemoveNameFromUsers < ActiveRecord::Migration[7.2]
      def change
        safety_assured { remove_column :users, :name }
      end
@@ -216,7 +216,7 @@ end
 In earlier versions of PostgreSQL adding a column with a non-null default value to an existing table blocks reads and writes while the entire table is rewritten.
 
 ```ruby
-class AddAdminToUsers < ActiveRecord::Migration[7.1]
+class AddAdminToUsers < ActiveRecord::Migration[7.2]
   def change
     add_column :users, :admin, :boolean, default: false
   end
@@ -236,7 +236,7 @@ A safer approach is to:
 `add_column_with_default` helper takes care of all this steps:
 
 ```ruby
-class AddAdminToUsers < ActiveRecord::Migration[7.1]
+class AddAdminToUsers < ActiveRecord::Migration[7.2]
   disable_ddl_transaction!
 
   def change
@@ -254,7 +254,7 @@ end
 Active Record wraps each migration in a transaction, 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 AddAdminToUsers < ActiveRecord::Migration[7.1]
+class AddAdminToUsers < ActiveRecord::Migration[7.2]
   def change
     add_column :users, :admin, :boolean
     User.update_all(admin: false)
@@ -269,13 +269,13 @@ 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 a `update_column_in_batches` helper in a separate migration with `disable_ddl_transaction!`.
 
 ```ruby
-class AddAdminToUsers < ActiveRecord::Migration[7.1]
+class AddAdminToUsers < ActiveRecord::Migration[7.2]
   def change
     add_column :users, :admin, :boolean
   end
 end
 
-class BackfillUsersAdminColumn < ActiveRecord::Migration[7.1]
+class BackfillUsersAdminColumn < ActiveRecord::Migration[7.2]
   disable_ddl_transaction!
 
   def up
@@ -294,7 +294,7 @@ end
 Changing the type of an existing column blocks reads and writes while the entire table is rewritten.
 
 ```ruby
-class ChangeFilesSizeType < ActiveRecord::Migration[7.1]
+class ChangeFilesSizeType < ActiveRecord::Migration[7.2]
   def change
     change_column :files, :size, :bigint
   end
@@ -338,7 +338,7 @@ A safer approach can be accomplished in several steps:
 1. Create a new column and keep column's data in sync:
 
    ```ruby
-   class InitializeChangeFilesSizeType < ActiveRecord::Migration[7.1]
+   class InitializeChangeFilesSizeType < ActiveRecord::Migration[7.2]
      def change
        initialize_column_type_change :files, :size, :bigint
      end
@@ -351,7 +351,7 @@ A safer approach can be accomplished in several steps:
 2. Backfill data from the old column to the new column:
 
    ```ruby
-   class BackfillChangeFilesSizeType < ActiveRecord::Migration[7.1]
+   class BackfillChangeFilesSizeType < ActiveRecord::Migration[7.2]
      disable_ddl_transaction!
 
      def up
@@ -372,7 +372,7 @@ during writes works automatically). For most column type changes, this does not
 5. Copy indexes, foreign keys, check constraints, NOT NULL constraint, swap new column in place:
 
    ```ruby
-   class FinalizeChangeFilesSizeType < ActiveRecord::Migration[7.1]
+   class FinalizeChangeFilesSizeType < ActiveRecord::Migration[7.2]
      disable_ddl_transaction!
 
      def change
@@ -385,7 +385,7 @@ during writes works automatically). For most column type changes, this does not
 7. Finally, if everything works as expected, remove copy trigger and old column:
 
    ```ruby
-   class CleanupChangeFilesSizeType < ActiveRecord::Migration[7.1]
+   class CleanupChangeFilesSizeType < ActiveRecord::Migration[7.2]
      def up
        cleanup_column_type_change :files, :size
      end
@@ -406,7 +406,7 @@ during writes works automatically). For most column type changes, this does not
 Renaming a column that's in use will cause errors in your application.
 
 ```ruby
-class RenameUsersNameToFirstName < ActiveRecord::Migration[7.1]
+class RenameUsersNameToFirstName < ActiveRecord::Migration[7.2]
   def change
     rename_column :users, :name, :first_name
   end
@@ -477,7 +477,7 @@ nor any data/indexes/foreign keys copying will be made, so will be instantaneous
 It will use a combination of a VIEW and column aliasing to work with both column names simultaneously
 
    ```ruby
-   class InitializeRenameUsersNameToFirstName < ActiveRecord::Migration[7.1]
+   class InitializeRenameUsersNameToFirstName < ActiveRecord::Migration[7.2]
      def change
        initialize_column_rename :users, :name, :first_name
      end
@@ -500,7 +500,7 @@ It will use a combination of a VIEW and column aliasing to work with both column
 9. Remove the VIEW created in step 3 and finally rename the column:
 
    ```ruby
-   class FinalizeRenameUsersNameToFirstName < ActiveRecord::Migration[7.1]
+   class FinalizeRenameUsersNameToFirstName < ActiveRecord::Migration[7.2]
      def change
        finalize_column_rename :users, :name, :first_name
      end
@@ -516,7 +516,7 @@ It will use a combination of a VIEW and column aliasing to work with both column
 Renaming a table that's in use will cause errors in your application.
 
 ```ruby
-class RenameClientsToUsers < ActiveRecord::Migration[7.1]
+class RenameClientsToUsers < ActiveRecord::Migration[7.2]
   def change
     rename_table :clients, :users
   end
@@ -571,7 +571,7 @@ To work around this limitation, we need to tell Active Record to acquire this in
 3. Create a VIEW:
 
    ```ruby
-   class InitializeRenameClientsToUsers < ActiveRecord::Migration[7.1]
+   class InitializeRenameClientsToUsers < ActiveRecord::Migration[7.2]
      def change
        initialize_table_rename :clients, :users
      end
@@ -584,7 +584,7 @@ To work around this limitation, we need to tell Active Record to acquire this in
 7. Remove the VIEW created in step 3:
 
    ```ruby
-   class FinalizeRenameClientsToUsers < ActiveRecord::Migration[7.1]
+   class FinalizeRenameClientsToUsers < ActiveRecord::Migration[7.2]
      def change
        finalize_table_rename :clients, :users
      end
@@ -600,7 +600,7 @@ To work around this limitation, we need to tell Active Record to acquire this in
 The `force` option can drop an existing table.
 
 ```ruby
-class CreateUsers < ActiveRecord::Migration[7.1]
+class CreateUsers < ActiveRecord::Migration[7.2]
   def change
     create_table :users, force: true do |t|
       # ...
@@ -614,7 +614,7 @@ end
 Create tables without the `force` option.
 
 ```ruby
-class CreateUsers < ActiveRecord::Migration[7.1]
+class CreateUsers < ActiveRecord::Migration[7.2]
   def change
     create_table :users do |t|
       # ...
@@ -632,7 +632,7 @@ If you intend to drop an existing table, run `drop_table` first.
 Adding a check constraint blocks reads and writes while every row is checked.
 
 ```ruby
-class AddCheckConstraint < ActiveRecord::Migration[7.1]
+class AddCheckConstraint < ActiveRecord::Migration[7.2]
   def change
     add_check_constraint :users, "char_length(name) >= 1", name: "name_check"
   end
@@ -644,7 +644,7 @@ end
 Add the check constraint without validating existing rows, and then validate them in a separate transaction:
 
 ```ruby
-class AddCheckConstraint < ActiveRecord::Migration[7.1]
+class AddCheckConstraint < ActiveRecord::Migration[7.2]
   disable_ddl_transaction!
 
   def change
@@ -663,7 +663,7 @@ end
 Setting `NOT NULL` on an existing column blocks reads and writes while every row is checked.
 
 ```ruby
-class ChangeUsersNameNull < ActiveRecord::Migration[7.1]
+class ChangeUsersNameNull < ActiveRecord::Migration[7.2]
   def change
     change_column_null :users, :name, false
   end
@@ -675,7 +675,7 @@ end
 Instead, add a check constraint and validate it in a separate transaction:
 
 ```ruby
-class ChangeUsersNameNull < ActiveRecord::Migration[7.1]
+class ChangeUsersNameNull < ActiveRecord::Migration[7.2]
   disable_ddl_transaction!
 
   def change
@@ -690,7 +690,7 @@ end
 A `NOT NULL` check constraint is functionally equivalent to setting `NOT NULL` on the column (but it won't show up in `schema.rb` in Rails < 6.1). In PostgreSQL 12+, once the check constraint is validated, you can safely set `NOT NULL` on the column and drop the check constraint.
 
 ```ruby
-class ChangeUsersNameNullDropCheck < ActiveRecord::Migration[7.1]
+class ChangeUsersNameNullDropCheck < ActiveRecord::Migration[7.2]
   def change
     # in PostgreSQL 12+, you can then safely set NOT NULL on the column
     change_column_null :users, :name, false
@@ -704,7 +704,7 @@ end
 Online Migrations does not support inspecting what happens inside an `execute` call, so cannot help you here. Make really sure that what you're doing is safe before proceeding, then wrap it in a `safety_assured { ... }` block:
 
 ```ruby
-class ExecuteSQL < ActiveRecord::Migration[7.1]
+class ExecuteSQL < ActiveRecord::Migration[7.2]
   def change
     safety_assured { execute "..." }
   end
@@ -718,7 +718,7 @@ end
 Adding an index non-concurrently blocks writes.
 
 ```ruby
-class AddIndexOnUsersEmail < ActiveRecord::Migration[7.1]
+class AddIndexOnUsersEmail < ActiveRecord::Migration[7.2]
   def change
     add_index :users, :email, unique: true
   end
@@ -730,7 +730,7 @@ end
 Add indexes concurrently.
 
 ```ruby
-class AddIndexOnUsersEmail < ActiveRecord::Migration[7.1]
+class AddIndexOnUsersEmail < ActiveRecord::Migration[7.2]
   disable_ddl_transaction!
 
   def change
@@ -748,7 +748,7 @@ end
 While actual removing of an index is usually fast, removing it non-concurrently tries to obtain an `ACCESS EXCLUSIVE` lock on the table, waiting for all existing queries to complete and blocking all the subsequent queries (even `SELECT`s) on that table until the lock is obtained and index is removed.
 
 ```ruby
-class RemoveIndexOnUsersEmail < ActiveRecord::Migration[7.1]
+class RemoveIndexOnUsersEmail < ActiveRecord::Migration[7.2]
   def change
     remove_index :users, :email
   end
@@ -760,7 +760,7 @@ end
 Remove indexes concurrently.
 
 ```ruby
-class RemoveIndexOnUsersEmail < ActiveRecord::Migration[7.1]
+class RemoveIndexOnUsersEmail < ActiveRecord::Migration[7.2]
   disable_ddl_transaction!
 
   def change
@@ -778,7 +778,7 @@ end
 Removing an old index before replacing it with the new one might result in slow queries while building the new index.
 
 ```ruby
-class AddIndexOnCreationToProjects < ActiveRecord::Migration[7.1]
+class AddIndexOnCreationToProjects < ActiveRecord::Migration[7.2]
   disable_ddl_transaction!
 
   def change
@@ -795,7 +795,7 @@ end
 A safer approach is to create the new index and then delete the old one.
 
 ```ruby
-class AddIndexOnCreationToProjects < ActiveRecord::Migration[7.1]
+class AddIndexOnCreationToProjects < ActiveRecord::Migration[7.2]
   disable_ddl_transaction!
 
   def change
@@ -812,7 +812,7 @@ end
 Rails adds an index non-concurrently to references by default, which blocks writes. Additionally, if `foreign_key` option (without `validate: false`) is provided, both tables are blocked while it is validated.
 
 ```ruby
-class AddUserToProjects < ActiveRecord::Migration[7.1]
+class AddUserToProjects < ActiveRecord::Migration[7.2]
   def change
     add_reference :projects, :user, foreign_key: true
   end
@@ -825,7 +825,7 @@ Make sure the index is added concurrently and the foreign key is added in a sepa
 Or you can use `add_reference_concurrently` helper. It will create a reference and take care of safely adding index and/or foreign key.
 
 ```ruby
-class AddUserToProjects < ActiveRecord::Migration[7.1]
+class AddUserToProjects < ActiveRecord::Migration[7.2]
   disable_ddl_transaction!
 
   def change
@@ -843,7 +843,7 @@ end
 Adding a foreign key blocks writes on both tables.
 
 ```ruby
-class AddForeignKeyToProjectsUser < ActiveRecord::Migration[7.1]
+class AddForeignKeyToProjectsUser < ActiveRecord::Migration[7.2]
   def change
     add_foreign_key :projects, :users
   end
@@ -853,7 +853,7 @@ end
 or
 
 ```ruby
-class AddReferenceToProjectsUser < ActiveRecord::Migration[7.1]
+class AddReferenceToProjectsUser < ActiveRecord::Migration[7.2]
   def change
     add_reference :projects, :user, foreign_key: true
   end
@@ -865,7 +865,7 @@ end
 Add the foreign key without validating existing rows:
 
 ```ruby
-class AddForeignKeyToProjectsUser < ActiveRecord::Migration[7.1]
+class AddForeignKeyToProjectsUser < ActiveRecord::Migration[7.2]
   def change
     add_foreign_key :projects, :users, validate: false
   end
@@ -875,7 +875,7 @@ end
 Then validate them in a separate migration:
 
 ```ruby
-class ValidateForeignKeyOnProjectsUser < ActiveRecord::Migration[7.1]
+class ValidateForeignKeyOnProjectsUser < ActiveRecord::Migration[7.2]
   def change
     validate_foreign_key :projects, :users
   end
@@ -889,7 +889,7 @@ end
 Adding an exclusion constraint blocks reads and writes while every row is checked.
 
 ```ruby
-class AddExclusionContraint < ActiveRecord::Migration[7.1]
+class AddExclusionContraint < ActiveRecord::Migration[7.2]
   def change
     add_exclusion_constraint :users, "number WITH =", using: :gist
   end
@@ -907,7 +907,7 @@ end
 Adding a unique constraint blocks reads and writes while the underlying index is being built.
 
 ```ruby
-class AddUniqueConstraint < ActiveRecord::Migration[7.1]
+class AddUniqueConstraint < ActiveRecord::Migration[7.2]
   def change
     add_unique_constraint :sections, :position, deferrable: :deferred
   end
@@ -919,7 +919,7 @@ end
 A safer approach is to create a unique index first, and then create a unique key using that index.
 
 ```ruby
-class AddUniqueConstraintAddIndex < ActiveRecord::Migration[7.1]
+class AddUniqueConstraintAddIndex < ActiveRecord::Migration[7.2]
   disable_ddl_transaction!
 
   def change
@@ -929,7 +929,7 @@ end
 ```
 
 ```ruby
-class AddUniqueConstraint < ActiveRecord::Migration[7.1]
+class AddUniqueConstraint < ActiveRecord::Migration[7.2]
   def up
     add_unique_constraint :sections, :position, deferrable: :deferred, using_index: "index_sections_on_position"
   end
@@ -947,7 +947,7 @@ end
 There's no equality operator for the `json` column type, which can cause errors for existing `SELECT DISTINCT` queries in your application.
 
 ```ruby
-class AddSettingsToProjects < ActiveRecord::Migration[7.1]
+class AddSettingsToProjects < ActiveRecord::Migration[7.2]
   def change
     add_column :projects, :settings, :json
   end
@@ -959,7 +959,7 @@ end
 Use `jsonb` instead.
 
 ```ruby
-class AddSettingsToProjects < ActiveRecord::Migration[7.1]
+class AddSettingsToProjects < ActiveRecord::Migration[7.2]
   def change
     add_column :projects, :settings, :jsonb
   end
@@ -973,7 +973,7 @@ end
 Adding a stored generated column causes the entire table to be rewritten. During this time, reads and writes are blocked.
 
 ```ruby
-class AddLowerEmailToUsers < ActiveRecord::Migration[7.1]
+class AddLowerEmailToUsers < ActiveRecord::Migration[7.2]
   def change
     add_column :users, :lower_email, :virtual, type: :string, as: "LOWER(email)", stored: true
   end
@@ -991,7 +991,7 @@ Add a non-generated column and use callbacks or triggers instead.
 When using short integer types as primary key types, [there is a risk](https://m.signalvnoise.com/update-on-basecamp-3-being-stuck-in-read-only-as-of-nov-8-922am-cst/) of running out of IDs on inserts. The default type in Active Record < 5.1 for primary and foreign keys is `INTEGER`, which allows a little over of 2 billion records. Active Record 5.1 changed the default type to `BIGINT`.
 
 ```ruby
-class CreateUsers < ActiveRecord::Migration[7.1]
+class CreateUsers < ActiveRecord::Migration[7.2]
   def change
     create_table :users, id: :integer do |t|
       # ...
@@ -1005,7 +1005,7 @@ end
 Use one of `bigint`, `bigserial`, `uuid` instead.
 
 ```ruby
-class CreateUsers < ActiveRecord::Migration[7.1]
+class CreateUsers < ActiveRecord::Migration[7.2]
   def change
     create_table :users, id: :bigint do |t| # bigint is the default for Active Record >= 5.1
       # ...
@@ -1021,7 +1021,7 @@ end
 Hash index operations are not WAL-logged, so hash indexes might need to be rebuilt with `REINDEX` after a database crash if there were unwritten changes. Also, changes to hash indexes are not replicated over streaming or file-based replication after the initial base backup, so they give wrong answers to queries that subsequently use them. For these reasons, hash index use is discouraged.
 
 ```ruby
-class AddIndexToUsersOnEmail < ActiveRecord::Migration[7.1]
+class AddIndexToUsersOnEmail < ActiveRecord::Migration[7.2]
   def change
     add_index :users, :email, unique: true, using: :hash
   end
@@ -1033,7 +1033,7 @@ end
 Use B-tree indexes instead.
 
 ```ruby
-class AddIndexToUsersOnEmail < ActiveRecord::Migration[7.1]
+class AddIndexToUsersOnEmail < ActiveRecord::Migration[7.2]
   def change
     add_index :users, :email, unique: true # B-tree by default
   end
@@ -1048,7 +1048,7 @@ Adding multiple foreign keys in a single migration blocks writes on all involved
 Avoid adding foreign key more than once per migration file, unless the source and target tables are identical.
 
 ```ruby
-class CreateUserProjects < ActiveRecord::Migration[7.1]
+class CreateUserProjects < ActiveRecord::Migration[7.2]
   def change
     create_table :user_projects do |t|
       t.belongs_to :user, foreign_key: true
@@ -1063,7 +1063,7 @@ end
 Add additional foreign keys in separate migration files. See [adding a foreign key](#adding-a-foreign-key) for how to properly add foreign keys.
 
 ```ruby
-class CreateUserProjects < ActiveRecord::Migration[7.1]
+class CreateUserProjects < ActiveRecord::Migration[7.2]
   def change
     create_table :user_projects do |t|
       t.belongs_to :user, foreign_key: true
@@ -1072,7 +1072,7 @@ class CreateUserProjects < ActiveRecord::Migration[7.1]
   end
 end
 
-class AddForeignKeyFromUserProjectsToProject < ActiveRecord::Migration[7.1]
+class AddForeignKeyFromUserProjectsToProject < ActiveRecord::Migration[7.2]
   def change
     add_foreign_key :user_projects, :projects
   end
@@ -1089,7 +1089,7 @@ Remove all the foreign keys first.
 Assuming, `projects` has foreign keys on `users.id` and `repositories.id`:
 
 ```ruby
-class DropProjects < ActiveRecord::Migration[7.1]
+class DropProjects < ActiveRecord::Migration[7.2]
   def change
     drop_table :projects
   end
@@ -1101,13 +1101,13 @@ end
 Remove all the foreign keys first:
 
 ```ruby
-class RemoveProjectsUserFk < ActiveRecord::Migration[7.1]
+class RemoveProjectsUserFk < ActiveRecord::Migration[7.2]
   def change
     remove_foreign_key :projects, :users
   end
 end
 
-class RemoveProjectsRepositoryFk < ActiveRecord::Migration[7.1]
+class RemoveProjectsRepositoryFk < ActiveRecord::Migration[7.2]
   def change
     remove_foreign_key :projects, :repositories
   end
@@ -1117,7 +1117,7 @@ end
 Then remove the table:
 
 ```ruby
-class DropProjects < ActiveRecord::Migration[7.1]
+class DropProjects < ActiveRecord::Migration[7.2]
   def change
     drop_table :projects
   end
@@ -1134,7 +1134,7 @@ Otherwise, there's a risk of bugs caused by IDs representable by one type but no
 Assuming, there is a `users` table with `bigint` primary key type:
 
 ```ruby
-class AddUserIdToProjects < ActiveRecord::Migration[7.1]
+class AddUserIdToProjects < ActiveRecord::Migration[7.2]
   def change
     add_column :projects, :user_id, :integer
   end
@@ -1148,7 +1148,7 @@ Add a reference column of the same type as a referenced primary key.
 Assuming, there is a `users` table with `bigint` primary key type:
 
 ```ruby
-class AddUserIdToProjects < ActiveRecord::Migration[7.1]
+class AddUserIdToProjects < ActiveRecord::Migration[7.2]
   def change
     add_column :projects, :user_id, :bigint
   end
@@ -1162,7 +1162,7 @@ end
 Adding a single table inheritance column might cause errors in old instances of your application.
 
 ```ruby
-class AddTypeToUsers < ActiveRecord::Migration[7.1]
+class AddTypeToUsers < ActiveRecord::Migration[7.2]
   def change
     add_column :users, :string, :type, default: "Member"
   end
@@ -1194,7 +1194,7 @@ A safer approach is to:
 Active Record < 7 enables partial writes by default, which can cause incorrect values to be inserted when changing the default value of a column.
 
 ```ruby
-class ChangeSomeColumnDefault < ActiveRecord::Migration[7.1]
+class ChangeSomeColumnDefault < ActiveRecord::Migration[7.2]
   def change
     change_column_default :users, :some_column, from: "old", to: "new"
   end
@@ -1222,7 +1222,7 @@ config.active_record.partial_inserts = false
 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.1]
+class MySafeMigration < ActiveRecord::Migration[7.2]
   def change
     safety_assured { remove_column :users, :some_column }
   end

data/docs/background_data_migrations.md

@@ -78,7 +78,7 @@ You can enqueue your background migration to be run by the scheduler via:
 
 ```ruby
 # db/migrate/xxxxxxxxxxxxxx_enqueue_backfill_project_issues_count.rb
-class EnqueueBackfillProjectIssuesCount < ActiveRecord::Migration[7.1]
+class EnqueueBackfillProjectIssuesCount < ActiveRecord::Migration[7.2]
   def up
     enqueue_background_data_migration("BackfillProjectIssuesCount")
   end

data/docs/configuring.md

@@ -156,7 +156,7 @@ This is useful to demystify `online_migrations` inner workings, and to better in
 Consider migration, running on PostgreSQL < 11:
 
 ```ruby
-class AddAdminToUsers < ActiveRecord::Migration[7.1]
+class AddAdminToUsers < ActiveRecord::Migration[7.2]
   disable_ddl_transaction!
 
   def change

data/lib/generators/online_migrations/templates/background_schema_migrations_change_unique_index.rb.tt

@@ -0,0 +1,9 @@
+class BackgroundSchemaMigrationsChangeUniqueIndex < <%= migration_parent %>
+  def change
+    safety_assured do
+      remove_index :background_schema_migrations, name: :index_background_schema_migrations_on_unique_configuration
+      add_index :background_schema_migrations, [:migration_name, :shard, :connection_class_name], unique: true,
+        name: :index_background_schema_migrations_on_unique_configuration
+    end
+  end
+end

data/lib/generators/online_migrations/templates/install_migration.rb.tt

@@ -69,7 +69,8 @@ class InstallOnlineMigrations < <%= migration_parent %>
 
       t.foreign_key :background_schema_migrations, column: :parent_id, on_delete: :cascade
 
-      t.index [:migration_name, :shard], unique: true, name: :index_background_schema_migrations_on_unique_configuration
+      t.index [:migration_name, :shard, :connection_class_name], unique: true,
+        name: :index_background_schema_migrations_on_unique_configuration
     end
   end
 end

data/lib/generators/online_migrations/upgrade_generator.rb

@@ -28,6 +28,12 @@ module OnlineMigrations
           migrations << "create_background_schema_migrations"
         end
 
+        indexes = connection.indexes(BackgroundSchemaMigrations::Migration.table_name)
+        unique_index = indexes.find { |i| i.unique && i.columns.sort == ["connection_class_name", "migration_name", "shard"] }
+        if !unique_index
+          migrations << "background_schema_migrations_change_unique_index"
+        end
+
         migrations
       end
 

data/lib/online_migrations/background_schema_migrations/migration.rb

@@ -62,7 +62,7 @@ module OnlineMigrations
       validates :table_name, presence: true, length: { maximum: MAX_IDENTIFIER_LENGTH }
       validates :definition, presence: true
       validates :migration_name, presence: true, uniqueness: {
-        scope: :shard,
+        scope: [:connection_class_name, :shard],
         message: ->(object, data) do
           message = "(#{data[:value]}) has already been taken."
           if object.index_addition?
@@ -116,6 +116,16 @@ module OnlineMigrations
         end
       end
 
+      # Whether the migration is considered stuck (is running for some configured time).
+      #
+      def stuck?
+        # Composite migrations are not considered stuck.
+        return false if composite?
+
+        stuck_timeout = (statement_timeout || 1.day) + 10.minutes
+        (enqueued? || running?) && updated_at <= stuck_timeout.seconds.ago
+      end
+
       # Mark this migration as ready to be processed again.
       #
       # This is used to manually retrying failed migrations.
@@ -180,7 +190,7 @@ module OnlineMigrations
                   if connection.send(:__index_valid?, name, schema: schema)
                     return
                   else
-                    connection.remove_index(table_name, name: name)
+                    connection.remove_index(table_name, name: name, algorithm: :concurrently)
                   end
                 end
               end
@@ -204,7 +214,7 @@ module OnlineMigrations
 
         def validate_connection_class
           klass = connection_class_name.safe_constantize
-          if !(klass < ActiveRecord::Base)
+          if !(klass <= ActiveRecord::Base)
             errors.add(:connection_class_name, "is not an ActiveRecord::Base child class")
           end
         end

data/lib/online_migrations/background_schema_migrations/migration_helpers.rb

@@ -85,10 +85,15 @@ module OnlineMigrations
       end
 
       # @private
-      def create_background_schema_migration(migration_name, table_name, **options)
-        options.assert_valid_keys(:definition, :max_attempts, :statement_timeout, :connection_class_name)
+      def create_background_schema_migration(migration_name, table_name, connection_class_name: nil, **options)
+        options.assert_valid_keys(:definition, :max_attempts, :statement_timeout)
 
-        Migration.find_or_create_by!(migration_name: migration_name, shard: nil) do |migration|
+        if connection_class_name
+          connection_class_name = __normalize_connection_class_name(connection_class_name)
+        end
+
+        Migration.find_or_create_by!(migration_name: migration_name, shard: nil,
+                                     connection_class_name: connection_class_name) do |migration|
           migration.assign_attributes(**options, table_name: table_name)
 
           shards = Utils.shard_names(migration.connection_class)
@@ -103,6 +108,17 @@ module OnlineMigrations
           end
         end
       end
+
+      private
+        def __normalize_connection_class_name(connection_class_name)
+          if connection_class_name
+            klass = connection_class_name.safe_constantize
+            if klass
+              connection_class = Utils.find_connection_class(klass)
+              connection_class.name if connection_class
+            end
+          end
+        end
     end
   end
 end

data/lib/online_migrations/background_schema_migrations/migration_runner.rb

@@ -68,6 +68,13 @@ module OnlineMigrations
             migration.run
           end
 
+          # Background schema migrations could take a while to run. It is possible, that the process
+          # never reaches this (or the rescue below) line of code. E.g., when it is force quitted
+          # (SIGKILL etc.) and so the migration will end up in the "running" state and the query is
+          # still executing (or already finished) in the database. This migration can either be safely
+          # manually retried or will be picked up in the future by scheduler when it decides that
+          # this migration is stuck.
+
           migration.update!(status: :succeeded, finished_at: Time.current)
 
           ActiveSupport::Notifications.instrument("completed.background_schema_migrations", migration_payload)

data/lib/online_migrations/background_schema_migrations/scheduler.rb

@@ -29,12 +29,13 @@ module OnlineMigrations
 
       private
         def find_migration
-          active_migrations = Migration.running.select(:table_name, :shard).to_a
+          active_migrations = Migration.running.reject(&:stuck?)
           runnable_migrations = Migration.runnable.enqueued.queue_order.to_a + Migration.retriable.queue_order.to_a
 
           runnable_migrations.find do |runnable_migration|
             active_migrations.none? do |active_migration|
-              active_migration.shard == runnable_migration.shard &&
+              active_migration.connection_class_name == runnable_migration.connection_class_name &&
+                active_migration.shard == runnable_migration.shard &&
                 active_migration.table_name == runnable_migration.table_name
             end
           end

data/lib/online_migrations/schema_statements.rb

@@ -179,7 +179,7 @@ module OnlineMigrations
     #
     def initialize_columns_rename(table_name, old_new_column_hash)
       transaction do
-        rename_table_create_view(table_name, old_new_column_hash)
+        __rename_table_and_create_view(table_name, old_new_column_hash)
       end
     end
 
@@ -214,7 +214,9 @@ module OnlineMigrations
     def revert_initialize_columns_rename(table_name, _old_new_column_hash = nil)
       transaction do
         execute("DROP VIEW #{quote_table_name(table_name)}")
-        rename_table("#{table_name}_column_rename", table_name)
+
+        tmp_table = __tmp_table_name_for_column_rename(table_name)
+        rename_table(tmp_table, table_name)
       end
     end
 
@@ -241,7 +243,9 @@ module OnlineMigrations
     def finalize_columns_rename(table_name, old_new_column_hash)
       transaction do
         execute("DROP VIEW #{quote_table_name(table_name)}")
-        rename_table("#{table_name}_column_rename", table_name)
+
+        tmp_table = __tmp_table_name_for_column_rename(table_name)
+        rename_table(tmp_table, table_name)
         old_new_column_hash.each do |column_name, new_column_name|
           rename_column(table_name, column_name, new_column_name)
         end
@@ -273,7 +277,7 @@ module OnlineMigrations
         old_new_column_hash.each do |column_name, new_column_name|
           rename_column(table_name, new_column_name, column_name)
         end
-        rename_table_create_view(table_name, old_new_column_hash)
+        __rename_table_and_create_view(table_name, old_new_column_hash)
       end
     end
 
@@ -643,21 +647,29 @@ module OnlineMigrations
       __ensure_not_in_transaction!
 
       column_name = "#{ref_name}_id"
+      type_column_name = "#{ref_name}_type"
+
       if !column_exists?(table_name, column_name)
         type = options[:type] || :bigint
         allow_null = options.fetch(:null, true)
         add_column(table_name, column_name, type, null: allow_null)
       end
 
+      if !column_exists?(table_name, type_column_name)
+        allow_null = options[:polymorphic].is_a?(Hash) ? options[:polymorphic][:null] : true
+        add_column(table_name, type_column_name, :string, null: allow_null)
+      end
+
       # Always added by default in 5.0+
       index = options.fetch(:index, true)
 
       if index
         index = {} if index == true
         index_columns = [column_name]
+
         if options[:polymorphic]
+          index_columns.unshift(type_column_name)
           index[:name] ||= "index_#{table_name}_on_#{ref_name}"
-          index_columns.unshift("#{ref_name}_type")
         end
 
         add_index(table_name, index_columns, **index.merge(algorithm: :concurrently))
@@ -906,7 +918,8 @@ module OnlineMigrations
       if renamed_tables.key?(table)
         super(renamed_tables[table])
       elsif renamed_columns.key?(table)
-        super("#{table}_column_rename")
+        tmp_table = __tmp_table_name_for_column_rename(table)
+        super(tmp_table)
       else
         super
       end
@@ -1046,8 +1059,9 @@ module OnlineMigrations
         schema ? quote(schema) : "current_schema()"
       end
 
-      def rename_table_create_view(table_name, old_new_column_hash)
-        tmp_table = "#{table_name}_column_rename"
+      def __rename_table_and_create_view(table_name, old_new_column_hash)
+        tmp_table = __tmp_table_name_for_column_rename(table_name)
+
         rename_table(table_name, tmp_table)
         column_mapping = old_new_column_hash.map do |column_name, new_column_name|
           "#{quote_column_name(column_name)} AS #{quote_column_name(new_column_name)}"
@@ -1059,5 +1073,16 @@ module OnlineMigrations
             FROM #{quote_table_name(tmp_table)}
         SQL
       end
+
+      def __tmp_table_name_for_column_rename(table_name)
+        suffix = "_column_rename"
+
+        # On ActiveRecord 7.1 can use table_name_length instead of max_identifier_length,
+        # see https://github.com/rails/rails/pull/45136.
+        # Also we need to account for "_pkey", because older versions does not correctly rename
+        # tables with long names. Remove when supporting newer versions only.
+        prefix_length = max_identifier_length - "_pkey".size - suffix.length
+        table_name[0, prefix_length] + suffix
+      end
   end
 end

data/lib/online_migrations/version.rb

@@ -1,5 +1,5 @@
 # frozen_string_literal: true
 
 module OnlineMigrations
-  VERSION = "0.19.3"
+  VERSION = "0.19.5"
 end

metadata

@@ -1,14 +1,14 @@
 --- !ruby/object:Gem::Specification
 name: online_migrations
 version: !ruby/object:Gem::Version
-  version: 0.19.3
+  version: 0.19.5
 platform: ruby
 authors:
 - fatkodima
 autorequire:
 bindir: bin
 cert_chain: []
-date: 2024-08-08 00:00:00.000000000 Z
+date: 2024-09-19 00:00:00.000000000 Z
 dependencies:
 - !ruby/object:Gem::Dependency
   name: activerecord
@@ -41,6 +41,7 @@ files:
 - lib/generators/online_migrations/install_generator.rb
 - lib/generators/online_migrations/templates/add_sharding_to_online_migrations.rb.tt
 - lib/generators/online_migrations/templates/background_data_migration.rb.tt
+- lib/generators/online_migrations/templates/background_schema_migrations_change_unique_index.rb.tt
 - lib/generators/online_migrations/templates/create_background_schema_migrations.rb.tt
 - lib/generators/online_migrations/templates/initializer.rb.tt
 - lib/generators/online_migrations/templates/install_migration.rb.tt