mastodon/db/migrate/20171201000000_change_account_id_nonnullable_in_lists.rb

# frozen_string_literal: true

class ChangeAccountIdNonnullableInLists < ActiveRecord::Migration[5.2]
  def change
    safety_assured do
      change_column_null :lists, :account_id, false
    end
  end
end
Enable Rubocop Style/FrozenStringLiteralComment (#23793) 2023-07-12 07:47:08 +00:00			`# frozen_string_literal: true`

Update strong-migrations-enabled migrations from 5.0 and 5.1 to 5.2 (#24275) 2023-03-27 14:09:10 +00:00			`class ChangeAccountIdNonnullableInLists < ActiveRecord::Migration[5.2]`
Change account_id non-nullable in lists (#5979) 2017-12-12 03:11:17 +00:00			`def change`
Fix old migrations failing because of strong_migrations update (#12692) Fixes #12690 The `strong_migrations` update from ba2eac8824a85aa9541f8070ed7bcd22b9982cc8 introduced a check for `change_column_null` specific to Postgres. This rejects old migrations. This commit just wraps old migrations with `safety_assured` to bypass this check. Alternatives would have been to: - Disable that check entirely (a possibility added in that same `strong_migrations` version) for Mastodon, but it makes sense to write new migrations without such a strong lock. - Rewrite the old migrations to do it in a way that do not require an exclusive lock. I thought fixing those old migrations for performance wasn't worth the pain. Also, if I understand correctly, the next version of `strong_migrations` is going to include a helper to do that. We could update those migrations at that point. 2019-12-29 04:39:08 +00:00			`safety_assured do`
			`change_column_null :lists, :account_id, false`
			`end`
Change account_id non-nullable in lists (#5979) 2017-12-12 03:11:17 +00:00			`end`
			`end`