It might happen you want to make the reference column have a unique
value, or you want to create partial indexes. So instead of only
accepting a `true` value, also accept a hash of options.
{change_column_type,rename_column}_concurrently both copy data from one column
to another during a migration, which should not be done on GitLab.com. Instead,
we should use background migrations.
remove_column should only be used in the up (or change) step of a migration if
it's a post-deployment migration. Otherwise there will be downtime due to the
ActiveRecord column cache, which we can avoid by using the IgnorableColumn
concern in combination with a post-deployment migration.
add_column_with_default is implemented in terms of update_column_in_batches, but
update_column_in_batches can be used independently. Neither of these should be
used on the specified large tables, because they will cause issues on large
instances like GitLab.com.
This also ignores the cop for all existing migrations, renaming
AddColumnWithDefaultToLargeTable where appropriate.
This adds a Rubocop rule to enforce the use of
add_concurrent_foreign_key instead of the regular add_foreign_key
method. This cop has been disabled for existing migrations so we don't
need to change those.
