strong_migrations 2.0.0 → 2.0.1

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: c963e6ef1e6a07f02f06e4a9838738df97014adaa3892bb8a8f11de2eb640455
-  data.tar.gz: f50bf92538e55ce8059340adc77ee4697656824b2ad2ca3f5a34a5b1ceb82bc5
+  metadata.gz: f129ef6d517a5adcc4091152f856c32b06cc0b5e4f8f2f3c0ff9ca854ba966c9
+  data.tar.gz: c649028a58aa6f11c598fd5b23e5a2ccec85ffc5b9de596c62ee7a6385f26b1e
 SHA512:
-  metadata.gz: 04e219c413e77a0ac48465b9387f780d0c15e7e18871f9dfcddb6a8fb2a1cad990d0e612b22e141fdca2da8ead445d5fe8622fcf56648d1b3ff45bcdcfd18788
-  data.tar.gz: 95e7d2ef43b677e975f8ac1ee5ad81b165ea6e0558acbd60448addc085b1a96e39cbf37b288ffd92ae8862e2dbf53f0abb3f21de6f208b806b3c18c9d64977f0
+  metadata.gz: ba0ad1239d5dae5f01b2f92e00f3f5296241d5f9b908ab7d7f342ce1c7136b9c681973e8dc2752e3a25da333eaa880091cb352170f29a645a9209e45babaa965
+  data.tar.gz: 4764de588facf1cafa101fd9fdffc9bc27c821eff7613c9ca8c5e6e877674495d53c3bd8f5a45bcc8abfe2ca0105f53a8ad950c62c713eed01e3891619790553

data/CHANGELOG.md

@@ -1,3 +1,7 @@
+## 2.0.1 (2024-10-14)
+
+- Fixed issue with `alphabetize_schema` and virtual columns
+
 ## 2.0.0 (2024-06-28)
 
 - Improved install generator for Trilogy

data/README.md

@@ -43,7 +43,7 @@ end
 
 Deploy the code, then wrap this step in a safety_assured { ... } block.
 
-class RemoveColumn < ActiveRecord::Migration[7.1]
+class RemoveColumn < ActiveRecord::Migration[7.2]
   def change
     safety_assured { remove_column :users, :name }
   end
@@ -98,7 +98,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[7.1]
+class RemoveSomeColumnFromUsers < ActiveRecord::Migration[7.2]
   def change
     remove_column :users, :some_column
   end
@@ -119,7 +119,7 @@ end
 3. Write a migration to remove the column (wrap in `safety_assured` block)
 
   ```ruby
-  class RemoveSomeColumnFromUsers < ActiveRecord::Migration[7.1]
+  class RemoveSomeColumnFromUsers < ActiveRecord::Migration[7.2]
     def change
       safety_assured { remove_column :users, :some_column }
     end
@@ -136,7 +136,7 @@ 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[7.1]
+class ChangeSomeColumnType < ActiveRecord::Migration[7.2]
   def change
     change_column :users, :some_column, :new_type
   end
@@ -182,7 +182,7 @@ A safer approach is to:
 Renaming a column that’s in use will cause errors in your application.
 
 ```ruby
-class RenameSomeColumn < ActiveRecord::Migration[7.1]
+class RenameSomeColumn < ActiveRecord::Migration[7.2]
   def change
     rename_column :users, :some_column, :new_name
   end
@@ -207,7 +207,7 @@ A safer approach is to:
 Renaming a table that’s in use will cause errors in your application.
 
 ```ruby
-class RenameUsersToCustomers < ActiveRecord::Migration[7.1]
+class RenameUsersToCustomers < ActiveRecord::Migration[7.2]
   def change
     rename_table :users, :customers
   end
@@ -232,7 +232,7 @@ A safer approach is to:
 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|
       # ...
@@ -246,7 +246,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|
       # ...
@@ -264,7 +264,7 @@ If you intend to drop an existing table, run `drop_table` first.
 Adding an auto-incrementing column (`serial`/`bigserial` in Postgres and `AUTO_INCREMENT` in MySQL and MariaDB) 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 AddIdToCitiesUsers < ActiveRecord::Migration[7.1]
+class AddIdToCitiesUsers < ActiveRecord::Migration[7.2]
   def change
     add_column :cities_users, :id, :primary_key
   end
@@ -284,7 +284,7 @@ Create a new table and migrate the data with the same steps as [renaming a table
 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]
+class AddSomeColumnToUsers < ActiveRecord::Migration[7.2]
   def change
     add_column :users, :some_column, :virtual, type: :string, as: "...", stored: true
   end
@@ -304,7 +304,7 @@ Add a non-generated column and use callbacks or triggers instead (or a virtual g
 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[7.1]
+class AddCheckConstraint < ActiveRecord::Migration[7.2]
   def change
     add_check_constraint :users, "price > 0", name: "price_check"
   end
@@ -316,7 +316,7 @@ end
 Add the check constraint without validating existing rows:
 
 ```ruby
-class AddCheckConstraint < ActiveRecord::Migration[7.1]
+class AddCheckConstraint < ActiveRecord::Migration[7.2]
   def change
     add_check_constraint :users, "price > 0", name: "price_check", validate: false
   end
@@ -326,7 +326,7 @@ end
 Then validate them in a separate migration.
 
 ```ruby
-class ValidateCheckConstraint < ActiveRecord::Migration[7.1]
+class ValidateCheckConstraint < ActiveRecord::Migration[7.2]
   def change
     validate_check_constraint :users, name: "price_check"
   end
@@ -342,7 +342,7 @@ end
 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]
+class ExecuteSQL < ActiveRecord::Migration[7.2]
   def change
     safety_assured { execute "..." }
   end
@@ -356,7 +356,7 @@ end
 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[7.1]
+class AddSomeColumnToUsers < ActiveRecord::Migration[7.2]
   def change
     add_column :users, :some_column, :text
     User.update_all some_column: "default_value"
@@ -371,7 +371,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[7.1]
+class BackfillSomeColumn < ActiveRecord::Migration[7.2]
   disable_ddl_transaction!
 
   def up
@@ -392,7 +392,7 @@ end
 In Postgres, adding an index non-concurrently blocks writes.
 
 ```ruby
-class AddSomeIndexToUsers < ActiveRecord::Migration[7.1]
+class AddSomeIndexToUsers < ActiveRecord::Migration[7.2]
   def change
     add_index :users, :some_column
   end
@@ -404,7 +404,7 @@ end
 Add indexes concurrently.
 
 ```ruby
-class AddSomeIndexToUsers < ActiveRecord::Migration[7.1]
+class AddSomeIndexToUsers < ActiveRecord::Migration[7.2]
   disable_ddl_transaction!
 
   def change
@@ -430,7 +430,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[7.1]
+class AddReferenceToUsers < ActiveRecord::Migration[7.2]
   def change
     add_reference :users, :city
   end
@@ -442,7 +442,7 @@ end
 Make sure the index is added concurrently.
 
 ```ruby
-class AddReferenceToUsers < ActiveRecord::Migration[7.1]
+class AddReferenceToUsers < ActiveRecord::Migration[7.2]
   disable_ddl_transaction!
 
   def change
@@ -460,7 +460,7 @@ end
 In Postgres, adding a foreign key blocks writes on both tables.
 
 ```ruby
-class AddForeignKeyOnUsers < ActiveRecord::Migration[7.1]
+class AddForeignKeyOnUsers < ActiveRecord::Migration[7.2]
   def change
     add_foreign_key :users, :orders
   end
@@ -470,7 +470,7 @@ end
 or
 
 ```ruby
-class AddReferenceToUsers < ActiveRecord::Migration[7.1]
+class AddReferenceToUsers < ActiveRecord::Migration[7.2]
   def change
     add_reference :users, :order, foreign_key: true
   end
@@ -482,7 +482,7 @@ end
 Add the foreign key without validating existing rows:
 
 ```ruby
-class AddForeignKeyOnUsers < ActiveRecord::Migration[7.1]
+class AddForeignKeyOnUsers < ActiveRecord::Migration[7.2]
   def change
     add_foreign_key :users, :orders, validate: false
   end
@@ -492,7 +492,7 @@ end
 Then validate them in a separate migration.
 
 ```ruby
-class ValidateForeignKeyOnUsers < ActiveRecord::Migration[7.1]
+class ValidateForeignKeyOnUsers < ActiveRecord::Migration[7.2]
   def change
     validate_foreign_key :users, :orders
   end
@@ -506,7 +506,7 @@ end
 In Postgres, adding a unique constraint creates a unique index, which blocks reads and writes.
 
 ```ruby
-class AddUniqueConstraint < ActiveRecord::Migration[7.1]
+class AddUniqueConstraint < ActiveRecord::Migration[7.2]
   def change
     add_unique_constraint :users, :some_column
   end
@@ -518,7 +518,7 @@ end
 Create a unique index concurrently, then use it for the constraint.
 
 ```ruby
-class AddUniqueConstraint < ActiveRecord::Migration[7.1]
+class AddUniqueConstraint < ActiveRecord::Migration[7.2]
   disable_ddl_transaction!
 
   def up
@@ -539,7 +539,7 @@ end
 In Postgres, adding an exclusion constraint blocks reads and writes while every row is checked.
 
 ```ruby
-class AddExclusionConstraint < ActiveRecord::Migration[7.1]
+class AddExclusionConstraint < ActiveRecord::Migration[7.2]
   def change
     add_exclusion_constraint :users, "number WITH =", using: :gist
   end
@@ -557,7 +557,7 @@ end
 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 AddPropertiesToUsers < ActiveRecord::Migration[7.1]
+class AddPropertiesToUsers < ActiveRecord::Migration[7.2]
   def change
     add_column :users, :properties, :json
   end
@@ -569,7 +569,7 @@ end
 Use `jsonb` instead.
 
 ```ruby
-class AddPropertiesToUsers < ActiveRecord::Migration[7.1]
+class AddPropertiesToUsers < ActiveRecord::Migration[7.2]
   def change
     add_column :users, :properties, :jsonb
   end
@@ -585,7 +585,7 @@ end
 In Postgres, setting `NOT NULL` on an existing column blocks reads and writes while every row is checked.
 
 ```ruby
-class SetSomeColumnNotNull < ActiveRecord::Migration[7.1]
+class SetSomeColumnNotNull < ActiveRecord::Migration[7.2]
   def change
     change_column_null :users, :some_column, false
   end
@@ -597,7 +597,7 @@ end
 Instead, add a check constraint.
 
 ```ruby
-class SetSomeColumnNotNull < ActiveRecord::Migration[7.1]
+class SetSomeColumnNotNull < ActiveRecord::Migration[7.2]
   def change
     add_check_constraint :users, "some_column IS NOT NULL", name: "users_some_column_null", validate: false
   end
@@ -607,7 +607,7 @@ end
 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.1]
+class ValidateSomeColumnNotNull < ActiveRecord::Migration[7.2]
   def change
     validate_check_constraint :users, name: "users_some_column_null"
     change_column_null :users, :some_column, false
@@ -623,7 +623,7 @@ end
 Adding a column with a volatile default value to an existing table causes the entire table to be rewritten. During this time, reads and writes are blocked.
 
 ```ruby
-class AddSomeColumnToUsers < ActiveRecord::Migration[7.1]
+class AddSomeColumnToUsers < ActiveRecord::Migration[7.2]
   def change
     add_column :users, :some_column, :uuid, default: "gen_random_uuid()"
   end
@@ -635,7 +635,7 @@ end
 Instead, add the column without a default value, then change the default.
 
 ```ruby
-class AddSomeColumnToUsers < ActiveRecord::Migration[7.1]
+class AddSomeColumnToUsers < ActiveRecord::Migration[7.2]
   def up
     add_column :users, :some_column, :uuid
     change_column_default :users, :some_column, from: nil, to: "gen_random_uuid()"
@@ -686,7 +686,7 @@ config.active_record.partial_inserts = false
 Adding a non-unique index with more than three columns rarely improves performance.
 
 ```ruby
-class AddSomeIndexToUsers < ActiveRecord::Migration[7.1]
+class AddSomeIndexToUsers < ActiveRecord::Migration[7.2]
   def change
     add_index :users, [:a, :b, :c, :d]
   end
@@ -698,7 +698,7 @@ end
 Instead, start an index with columns that narrow down the results the most.
 
 ```ruby
-class AddSomeIndexToUsers < ActiveRecord::Migration[7.1]
+class AddSomeIndexToUsers < ActiveRecord::Migration[7.2]
   def change
     add_index :users, [:d, :b]
   end
@@ -712,7 +712,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[7.1]
+class MySafeMigration < ActiveRecord::Migration[7.2]
   def change
     safety_assured { remove_column :users, :some_column }
   end
@@ -934,15 +934,18 @@ You probably don’t need this gem for smaller projects, as operations that are
 
 ## Additional Reading
 
-- [Rails Migrations with No Downtime](https://pedro.herokuapp.com/past/2011/7/13/rails_migrations_with_no_downtime/)
 - [PostgreSQL at Scale: Database Schema Changes Without Downtime](https://medium.com/braintree-product-technology/postgresql-at-scale-database-schema-changes-without-downtime-20d3749ed680)
-- [An Overview of DDL Algorithms in MySQL](https://mydbops.wordpress.com/2020/03/04/an-overview-of-ddl-algorithms-in-mysql-covers-mysql-8/)
+- [MySQL InnoDB Online DDL Operations](https://dev.mysql.com/doc/refman/en/innodb-online-ddl-operations.html)
 - [MariaDB InnoDB Online DDL Overview](https://mariadb.com/kb/en/innodb-online-ddl-overview/)
 
 ## Credits
 
 Thanks to Bob Remeika and David Waller for the [original code](https://github.com/foobarfighter/safe-migrations) and [Sean Huber](https://github.com/LendingHome/zero_downtime_migrations) for the bad/good readme format.
 
+## History
+
+View the [changelog](https://github.com/ankane/strong_migrations/blob/master/CHANGELOG.md)
+
 ## Contributing
 
 Everyone is encouraged to help improve this project. Here are a few ways you can help:

data/lib/strong_migrations/schema_dumper.rb

@@ -17,5 +17,16 @@ module StrongMigrations
     def columns(*args, **options)
       @connection.columns(*args, **options).sort_by(&:name)
     end
+
+    # forward private methods with send
+    # method_missing cannot tell how method was called
+    # this is not ideal, but other solutions have drawbacks
+    def send(name, ...)
+      if respond_to?(name, true)
+        super
+      else
+        @connection.send(name, ...)
+      end
+    end
   end
 end

data/lib/strong_migrations/version.rb

@@ -1,3 +1,3 @@
 module StrongMigrations
-  VERSION = "2.0.0"
+  VERSION = "2.0.1"
 end

metadata

@@ -1,7 +1,7 @@
 --- !ruby/object:Gem::Specification
 name: strong_migrations
 version: !ruby/object:Gem::Version
-  version: 2.0.0
+  version: 2.0.1
 platform: ruby
 authors:
 - Andrew Kane
@@ -10,7 +10,7 @@ authors:
 autorequire:
 bindir: bin
 cert_chain: []
-date: 2024-06-28 00:00:00.000000000 Z
+date: 2024-10-15 00:00:00.000000000 Z
 dependencies:
 - !ruby/object:Gem::Dependency
   name: activerecord
@@ -75,7 +75,7 @@ required_rubygems_version: !ruby/object:Gem::Requirement
     - !ruby/object:Gem::Version
       version: '0'
 requirements: []
-rubygems_version: 3.5.11
+rubygems_version: 3.5.16
 signing_key:
 specification_version: 4
 summary: Catch unsafe migrations in development