fatkodima / online_migrations

Catch unsafe PostgreSQL migrations in development and run them easier in production (code helpers for table/column renaming, changing column type, adding columns with default, background migrations, etc).
https://rubydoc.info/github/fatkodima/online_migrations/
MIT License
602 stars 17 forks source link

add_reference_concurrently with polymorphic option #61

Closed brigidspeed23 closed 5 hours ago

brigidspeed23 commented 16 hours ago

Gem version: 0.19.4 Ruby version: 3.3.4 Rails version: 8.0.0.alpha

Hi !!

We're seeing some undesirable behaviour while running an add_reference_concurrently migration with the polymorphic flag enabled eg

class Btest1Migration < ActiveRecord::Migration[8.0]
  regions :all

  disable_ddl_transaction!

  def up
    add_reference_concurrently :automatic_break_templates, :pay_condition_settable, polymorphic: true
  end
end

When we run the migration the first time, it fails with error ERROR: column "pay_condition_settable_type" does not exist.

We can see from the raw SQL, that the migration only creates the _id column and isn't attempting to create the _type column:

image

This is the first issue: creation column _type is not attempted before creation of index.

Checking the table schema at this point and both the _id and _type columns and the index have not been added (as expected for the migration failing).

Running the migration a second time, and it also fails with error ERROR: column "pay_condition_settable_type" does not exist, however this time we can see from the raw SQL that the there is no attempt to create either the _id or _type column (although neither of these exist) prior to attempting to create the index:

image

This is the second issue: inconsistent behaviour of the migration between subsequent runs.

The first issue might be a fairly simple bug fix, but we'd be interested if anyone has any thoughts or insight on the second issue as well.

Many thanks in advance !!

fatkodima commented 16 hours ago

Thanks for reporting! Yeah, so this is a bug. And the whole operation should be idempotent, so subsequent runs should be no-ops.

I will fix it and release a new version tomorrow.

fatkodima commented 5 hours ago

Can you please confirm that the changes from master actually fixes your problem? And so I will release a new version.