online_migrations 0.8.2 → 0.9.1

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: b4f89ce12461dd3b786e98ecbc1afc315a5013a0967e90b9307d47b080924723
-  data.tar.gz: 797f19c861514e843a7d6e6f3222d19f36b77fc30ff3cc1ac2808591fa339f75
+  metadata.gz: 3dcce4daf35232504ad0f681e81c147d71bc9a1e34004cd387c50a89f6ef66df
+  data.tar.gz: 0ae067917657f91f5956589cb1720faf6232fff7259b906ff69dd8bf13c35ecb
 SHA512:
-  metadata.gz: c4458f5096fc180bb27411fc800db6dce588473373c0945abf2121b67591dc031badb498582681e55128055a85105600be1de8851818e93bf1108f42d43dd24c
-  data.tar.gz: ec49dd203d5ded9638d623af2b35b6ca1980a182a54ecf57bcbaf9d910cfe8f3e2cbd0f90c7e4d94f76236be91ef373b50e29a65e59be6e12ef6b55ad21de91b
+  metadata.gz: 9652ccc8a70af95729cfe33fd039ad5c5120a6d497b8b5334463dbc6ea5f5d4440f9cfbd948f40127f7f3a2a89ec5b2ad4a0032c85907fadb368192127aba6f1
+  data.tar.gz: a5da561d0357d0f58aeaf29bd83688cd08c67e9f85dae7b7c806e347c49c2bc3a0c8410f25449cc37d952be7079be030ec591df8a9a6e072e5a1acd82d7a2a7c

data/CHANGELOG.md

@@ -1,5 +1,19 @@
 ## master (unreleased)
 
+## 0.9.1 (2023-10-30)
+
+- Fix copying expression indexes when changing column type
+
+## 0.9.0 (2023-10-27)
+
+- Add ability to use custom raw sql for `backfill_column_for_type_change`'s `type_cast_function`
+
+    ```ruby
+    backfill_column_for_type_change(:users, :company_id, type_cast_function: Arel.sql("company_id::integer"))
+    ```
+
+- Fix version safety with `revert`
+
 ## 0.8.2 (2023-09-26)
 
 - Promote check constraint to `NOT NULL` on PostgreSQL >= 12 when changing column type

data/README.md

@@ -55,7 +55,7 @@ An operation is classified as dangerous if it either:
 Consider the following migration:
 
 ```ruby
-class AddAdminToUsers < ActiveRecord::Migration[7.0]
+class AddAdminToUsers < ActiveRecord::Migration[7.1]
   def change
     add_column :users, :admin, :boolean, default: false, null: false
   end
@@ -67,7 +67,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.0]
+class AddAdminToUsers < ActiveRecord::Migration[7.1]
   # Do not wrap the migration in a transaction so that locks are held for a shorter time.
   disable_ddl_transaction!
 
@@ -112,7 +112,7 @@ A safer approach is to:
 
 add_column_with_default takes care of all this steps:
 
-class AddAdminToUsers < ActiveRecord::Migration[7.0]
+class AddAdminToUsers < ActiveRecord::Migration[7.1]
   disable_ddl_transaction!
 
   def change
@@ -166,7 +166,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 RemoveNameFromUsers < ActiveRecord::Migration[7.0]
+class RemoveNameFromUsers < ActiveRecord::Migration[7.1]
   def change
     remove_column :users, :name
   end
@@ -195,7 +195,7 @@ end
 3. Wrap column removing in a `safety_assured` block:
 
   ```ruby
-  class RemoveNameFromUsers < ActiveRecord::Migration[7.0]
+  class RemoveNameFromUsers < ActiveRecord::Migration[7.1]
     def change
       safety_assured { remove_column :users, :name }
     end
@@ -212,7 +212,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.0]
+class AddAdminToUsers < ActiveRecord::Migration[7.1]
   def change
     add_column :users, :admin, :boolean, default: false
   end
@@ -232,7 +232,7 @@ A safer approach is to:
 `add_column_with_default` helper takes care of all this steps:
 
 ```ruby
-class AddAdminToUsers < ActiveRecord::Migration[7.0]
+class AddAdminToUsers < ActiveRecord::Migration[7.1]
   disable_ddl_transaction!
 
   def change
@@ -250,7 +250,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.0]
+class AddAdminToUsers < ActiveRecord::Migration[7.1]
   def change
     add_column :users, :admin, :boolean
     User.update_all(admin: false)
@@ -265,13 +265,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.0]
+class AddAdminToUsers < ActiveRecord::Migration[7.1]
   def change
     add_column :users, :admin, :boolean
   end
 end
 
-class BackfillUsersAdminColumn < ActiveRecord::Migration[7.0]
+class BackfillUsersAdminColumn < ActiveRecord::Migration[7.1]
   disable_ddl_transaction!
 
   def up
@@ -290,7 +290,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.0]
+class ChangeFilesSizeType < ActiveRecord::Migration[7.1]
   def change
     change_column :files, :size, :bigint
   end
@@ -323,7 +323,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.0]
+  class InitializeChangeFilesSizeType < ActiveRecord::Migration[7.1]
     def change
       initialize_column_type_change :files, :size, :bigint
     end
@@ -336,7 +336,7 @@ which will be passed to `add_column` when creating a new column, so you can over
 2. Backfill data from the old column to the new column:
 
   ```ruby
-  class BackfillChangeFilesSizeType < ActiveRecord::Migration[7.0]
+  class BackfillChangeFilesSizeType < ActiveRecord::Migration[7.1]
     disable_ddl_transaction!
 
     def up
@@ -352,7 +352,7 @@ which will be passed to `add_column` when creating a new column, so you can over
 3. Copy indexes, foreign keys, check constraints, NOT NULL constraint, swap new column in place:
 
   ```ruby
-  class FinalizeChangeFilesSizeType < ActiveRecord::Migration[7.0]
+  class FinalizeChangeFilesSizeType < ActiveRecord::Migration[7.1]
     disable_ddl_transaction!
 
     def change
@@ -365,7 +365,7 @@ which will be passed to `add_column` when creating a new column, so you can over
 5. Finally, if everything is working as expected, remove copy trigger and old column:
 
   ```ruby
-  class CleanupChangeFilesSizeType < ActiveRecord::Migration[7.0]
+  class CleanupChangeFilesSizeType < ActiveRecord::Migration[7.1]
     def up
       cleanup_column_type_change :files, :size
     end
@@ -385,7 +385,7 @@ which will be passed to `add_column` when creating a new column, so you can over
 Renaming a column that's in use will cause errors in your application.
 
 ```ruby
-class RenameUsersNameToFirstName < ActiveRecord::Migration[7.0]
+class RenameUsersNameToFirstName < ActiveRecord::Migration[7.1]
   def change
     rename_column :users, :name, :first_name
   end
@@ -454,7 +454,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.0]
+class InitializeRenameUsersNameToFirstName < ActiveRecord::Migration[7.1]
   def change
     initialize_column_rename :users, :name, :first_name
   end
@@ -485,7 +485,7 @@ end
 9. Remove the VIEW created in step 3 and finally rename the column:
 
 ```ruby
-class FinalizeRenameUsersNameToFirstName < ActiveRecord::Migration[7.0]
+class FinalizeRenameUsersNameToFirstName < ActiveRecord::Migration[7.1]
   def change
     finalize_column_rename :users, :name, :first_name
   end
@@ -501,7 +501,7 @@ end
 Renaming a table that's in use will cause errors in your application.
 
 ```ruby
-class RenameClientsToUsers < ActiveRecord::Migration[7.0]
+class RenameClientsToUsers < ActiveRecord::Migration[7.1]
   def change
     rename_table :clients, :users
   end
@@ -556,7 +556,7 @@ OnlineMigrations.config.table_renames = {
 3. Create a VIEW:
 
 ```ruby
-class InitializeRenameClientsToUsers < ActiveRecord::Migration[7.0]
+class InitializeRenameClientsToUsers < ActiveRecord::Migration[7.1]
   def change
     initialize_table_rename :clients, :users
   end
@@ -569,7 +569,7 @@ end
 7. Remove the VIEW created in step 3:
 
 ```ruby
-class FinalizeRenameClientsToUsers < ActiveRecord::Migration[7.0]
+class FinalizeRenameClientsToUsers < ActiveRecord::Migration[7.1]
   def change
     finalize_table_rename :clients, :users
   end
@@ -585,7 +585,7 @@ end
 The `force` option can drop an existing table.
 
 ```ruby
-class CreateUsers < ActiveRecord::Migration[7.0]
+class CreateUsers < ActiveRecord::Migration[7.1]
   def change
     create_table :users, force: true do |t|
       # ...
@@ -599,7 +599,7 @@ end
 Create tables without the `force` option.
 
 ```ruby
-class CreateUsers < ActiveRecord::Migration[7.0]
+class CreateUsers < ActiveRecord::Migration[7.1]
   def change
     create_table :users do |t|
       # ...
@@ -617,7 +617,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.0]
+class AddCheckConstraint < ActiveRecord::Migration[7.1]
   def change
     add_check_constraint :users, "char_length(name) >= 1", name: "name_check"
   end
@@ -629,7 +629,7 @@ end
 Add the check constraint without validating existing rows, and then validate them in a separate transaction:
 
 ```ruby
-class AddCheckConstraint < ActiveRecord::Migration[7.0]
+class AddCheckConstraint < ActiveRecord::Migration[7.1]
   disable_ddl_transaction!
 
   def change
@@ -648,7 +648,7 @@ end
 Setting `NOT NULL` on an existing column blocks reads and writes while every row is checked.
 
 ```ruby
-class ChangeUsersNameNull < ActiveRecord::Migration[7.0]
+class ChangeUsersNameNull < ActiveRecord::Migration[7.1]
   def change
     change_column_null :users, :name, false
   end
@@ -660,7 +660,7 @@ end
 Instead, add a check constraint and validate it in a separate transaction:
 
 ```ruby
-class ChangeUsersNameNull < ActiveRecord::Migration[7.0]
+class ChangeUsersNameNull < ActiveRecord::Migration[7.1]
   disable_ddl_transaction!
 
   def change
@@ -675,7 +675,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.0]
+class ChangeUsersNameNullDropCheck < ActiveRecord::Migration[7.1]
   def change
     # in PostgreSQL 12+, you can then safely set NOT NULL on the column
     change_column_null :users, :name, false
@@ -689,7 +689,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.0]
+class ExecuteSQL < ActiveRecord::Migration[7.1]
   def change
     safety_assured { execute "..." }
   end
@@ -703,7 +703,7 @@ end
 Adding an index non-concurrently blocks writes.
 
 ```ruby
-class AddIndexOnUsersEmail < ActiveRecord::Migration[7.0]
+class AddIndexOnUsersEmail < ActiveRecord::Migration[7.1]
   def change
     add_index :users, :email, unique: true
   end
@@ -715,7 +715,7 @@ end
 Add indexes concurrently.
 
 ```ruby
-class AddIndexOnUsersEmail < ActiveRecord::Migration[7.0]
+class AddIndexOnUsersEmail < ActiveRecord::Migration[7.1]
   disable_ddl_transaction!
 
   def change
@@ -733,7 +733,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.0]
+class RemoveIndexOnUsersEmail < ActiveRecord::Migration[7.1]
   def change
     remove_index :users, :email
   end
@@ -745,7 +745,7 @@ end
 Remove indexes concurrently.
 
 ```ruby
-class RemoveIndexOnUsersEmail < ActiveRecord::Migration[7.0]
+class RemoveIndexOnUsersEmail < ActiveRecord::Migration[7.1]
   disable_ddl_transaction!
 
   def change
@@ -763,7 +763,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.0]
+class AddIndexOnCreationToProjects < ActiveRecord::Migration[7.1]
   disable_ddl_transaction!
 
   def change
@@ -780,7 +780,7 @@ end
 A safer approach is to create the new index and then delete the old one.
 
 ```ruby
-class AddIndexOnCreationToProjects < ActiveRecord::Migration[7.0]
+class AddIndexOnCreationToProjects < ActiveRecord::Migration[7.1]
   disable_ddl_transaction!
 
   def change
@@ -797,7 +797,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.0]
+class AddUserToProjects < ActiveRecord::Migration[7.1]
   def change
     add_reference :projects, :user, foreign_key: true
   end
@@ -810,7 +810,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.0]
+class AddUserToProjects < ActiveRecord::Migration[7.1]
   disable_ddl_transaction!
 
   def change
@@ -828,7 +828,7 @@ end
 Adding a foreign key blocks writes on both tables.
 
 ```ruby
-class AddForeignKeyToProjectsUser < ActiveRecord::Migration[7.0]
+class AddForeignKeyToProjectsUser < ActiveRecord::Migration[7.1]
   def change
     add_foreign_key :projects, :users
   end
@@ -838,7 +838,7 @@ end
 or
 
 ```ruby
-class AddReferenceToProjectsUser < ActiveRecord::Migration[7.0]
+class AddReferenceToProjectsUser < ActiveRecord::Migration[7.1]
   def change
     add_reference :projects, :user, foreign_key: true
   end
@@ -850,7 +850,7 @@ end
 Add the foreign key without validating existing rows, and then validate them in a separate transaction.
 
 ```ruby
-class AddForeignKeyToProjectsUser < ActiveRecord::Migration[7.0]
+class AddForeignKeyToProjectsUser < ActiveRecord::Migration[7.1]
   disable_ddl_transaction!
 
   def change
@@ -927,7 +927,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.0]
+class AddSettingsToProjects < ActiveRecord::Migration[7.1]
   def change
     add_column :projects, :settings, :json
   end
@@ -939,7 +939,7 @@ end
 Use `jsonb` instead.
 
 ```ruby
-class AddSettingsToProjects < ActiveRecord::Migration[7.0]
+class AddSettingsToProjects < ActiveRecord::Migration[7.1]
   def change
     add_column :projects, :settings, :jsonb
   end
@@ -953,7 +953,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.0]
+class AddLowerEmailToUsers < ActiveRecord::Migration[7.1]
   def change
     add_column :users, :lower_email, :virtual, type: :string, as: "LOWER(email)", stored: true
   end
@@ -971,7 +971,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.0]
+class CreateUsers < ActiveRecord::Migration[7.1]
   def change
     create_table :users, id: :integer do |t|
       # ...
@@ -985,7 +985,7 @@ end
 Use one of `bigint`, `bigserial`, `uuid` instead.
 
 ```ruby
-class CreateUsers < ActiveRecord::Migration[7.0]
+class CreateUsers < ActiveRecord::Migration[7.1]
   def change
     create_table :users, id: :bigint do |t| # bigint is the default for Active Record >= 5.1
       # ...
@@ -1001,7 +1001,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.0]
+class AddIndexToUsersOnEmail < ActiveRecord::Migration[7.1]
   def change
     add_index :users, :email, unique: true, using: :hash
   end
@@ -1013,7 +1013,7 @@ end
 Use B-tree indexes instead.
 
 ```ruby
-class AddIndexToUsersOnEmail < ActiveRecord::Migration[7.0]
+class AddIndexToUsersOnEmail < ActiveRecord::Migration[7.1]
   def change
     add_index :users, :email, unique: true # B-tree by default
   end
@@ -1028,7 +1028,7 @@ Adding multiple foreign keys in a single migration blocks reads and writes on al
 Avoid adding foreign key more than once per migration file, unless the source and target tables are identical.
 
 ```ruby
-class CreateUserProjects < ActiveRecord::Migration[7.0]
+class CreateUserProjects < ActiveRecord::Migration[7.1]
   def change
     create_table :user_projects do |t|
       t.belongs_to :user, foreign_key: true
@@ -1043,7 +1043,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.0]
+class CreateUserProjects < ActiveRecord::Migration[7.1]
   def change
     create_table :user_projects do |t|
       t.belongs_to :user, foreign_key: true
@@ -1052,7 +1052,7 @@ class CreateUserProjects < ActiveRecord::Migration[7.0]
   end
 end
 
-class AddForeignKeyFromUserProjectsToProject < ActiveRecord::Migration[7.0]
+class AddForeignKeyFromUserProjectsToProject < ActiveRecord::Migration[7.1]
   def change
     add_foreign_key :user_projects, :projects
   end
@@ -1069,7 +1069,7 @@ Remove all the foreign keys first.
 Assuming, `projects` has foreign keys on `users.id` and `repositories.id`:
 
 ```ruby
-class DropProjects < ActiveRecord::Migration[7.0]
+class DropProjects < ActiveRecord::Migration[7.1]
   def change
     drop_table :projects
   end
@@ -1081,13 +1081,13 @@ end
 Remove all the foreign keys first:
 
 ```ruby
-class RemoveProjectsUserFk < ActiveRecord::Migration[7.0]
+class RemoveProjectsUserFk < ActiveRecord::Migration[7.1]
   def change
     remove_foreign_key :projects, :users
   end
 end
 
-class RemoveProjectsRepositoryFk < ActiveRecord::Migration[7.0]
+class RemoveProjectsRepositoryFk < ActiveRecord::Migration[7.1]
   def change
     remove_foreign_key :projects, :repositories
   end
@@ -1097,7 +1097,7 @@ end
 Then remove the table:
 
 ```ruby
-class DropProjects < ActiveRecord::Migration[7.0]
+class DropProjects < ActiveRecord::Migration[7.1]
   def change
     drop_table :projects
   end
@@ -1114,7 +1114,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.0]
+class AddUserIdToProjects < ActiveRecord::Migration[7.1]
   def change
     add_column :projects, :user_id, :integer
   end
@@ -1128,7 +1128,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.0]
+class AddUserIdToProjects < ActiveRecord::Migration[7.1]
   def change
     add_column :projects, :user_id, :bigint
   end
@@ -1142,7 +1142,7 @@ end
 Adding a single table inheritance column might cause errors in old instances of your application.
 
 ```ruby
-class AddTypeToUsers < ActiveRecord::Migration[7.0]
+class AddTypeToUsers < ActiveRecord::Migration[7.1]
   def change
     add_column :users, :string, :type, default: "Member"
   end
@@ -1182,7 +1182,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.0]
+class ChangeSomeColumnDefault < ActiveRecord::Migration[7.1]
   def change
     change_column_default :users, :some_column, from: "old", to: "new"
   end
@@ -1210,7 +1210,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.0]
+class MySafeMigration < ActiveRecord::Migration[7.1]
   def change
     safety_assured { remove_column :users, :some_column }
   end

data/docs/configuring.md

@@ -154,7 +154,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.0]
+class AddAdminToUsers < ActiveRecord::Migration[7.1]
   disable_ddl_transaction!
 
   def change

data/lib/online_migrations/change_column_type_helpers.rb

@@ -176,6 +176,7 @@ module OnlineMigrations
     #
     # @example With type casting
     #   backfill_column_for_type_change(:users, :settings, type_cast_function: "jsonb")
+    #   backfill_column_for_type_change(:users, :company_id, type_cast_function: Arel.sql("company_id::integer"))
     #
     # @example Additional batch options
     #   backfill_column_for_type_change(:files, :size, batch_size: 10_000)
@@ -202,7 +203,13 @@ module OnlineMigrations
 
         old_value = Arel::Table.new(table_name)[column_name]
         if (type_cast_function = type_cast_functions.with_indifferent_access[column_name])
-          old_value = Arel::Nodes::NamedFunction.new(type_cast_function.to_s, [old_value])
+          old_value =
+            case type_cast_function
+            when Arel::Nodes::SqlLiteral
+              type_cast_function
+            else
+              Arel::Nodes::NamedFunction.new(type_cast_function.to_s, [old_value])
+            end
         end
 
         [tmp_column, old_value]
@@ -398,9 +405,15 @@ module OnlineMigrations
         to_column    = to_column.to_s
 
         __indexes_for(table_name, from_column).each do |index|
-          new_columns = index.columns.map do |column|
-            column == from_column ? to_column : column
-          end
+          new_columns =
+            # Expression index.
+            if index.columns.is_a?(String)
+              index.columns.gsub(from_column, to_column)
+            else
+              index.columns.map do |column|
+                column == from_column ? to_column : column
+              end
+            end
 
           # This is necessary as we can't properly rename indexes such as "taggings_idx".
           if !index.name.include?(from_column)

data/lib/online_migrations/command_checker.rb

@@ -48,6 +48,10 @@ module OnlineMigrations
     end
     ruby2_keywords(:check) if respond_to?(:ruby2_keywords, true)
 
+    def version_safe?
+      version && version <= OnlineMigrations.config.start_after
+    end
+
     private
       def check_database_version
         return if defined?(@database_version_checked)
@@ -107,7 +111,8 @@ module OnlineMigrations
         self.class.safe ||
           ENV["SAFETY_ASSURED"] ||
           (direction == :down && !OnlineMigrations.config.check_down) ||
-          version <= OnlineMigrations.config.start_after
+          version_safe? ||
+          @migration.reverting?
       end
 
       def version

data/lib/online_migrations/migration.rb

@@ -30,6 +30,15 @@ module OnlineMigrations
     end
     ruby2_keywords(:method_missing) if respond_to?(:ruby2_keywords, true)
 
+    # @private
+    def revert(*args)
+      if command_checker.version_safe?
+        safety_assured { super }
+      else
+        super
+      end
+    end
+
     # Mark a command in the migration as safe, despite using a method that might otherwise be dangerous.
     #
     # @example

data/lib/online_migrations/version.rb

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

metadata

@@ -1,14 +1,14 @@
 --- !ruby/object:Gem::Specification
 name: online_migrations
 version: !ruby/object:Gem::Version
-  version: 0.8.2
+  version: 0.9.1
 platform: ruby
 authors:
 - fatkodima
 autorequire:
 bindir: bin
 cert_chain: []
-date: 2023-09-26 00:00:00.000000000 Z
+date: 2023-10-30 00:00:00.000000000 Z
 dependencies:
 - !ruby/object:Gem::Dependency
   name: activerecord