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.
Replaces all the explicit include metadata syntax in the specs (tag:
true) into the implicit one (:tag).
Added a cop to prevent future errors and handle autocorrection.
This module provides a class method called `each_batch` that can be used
to iterate tables in batches in a more efficient way compared to Rails'
`in_batches` method. This commit also includes a RuboCop cop to
blacklist the use of `in_batches` in favour of this new method.
This is allowed for existing instances so we don't end up 76 offenses
right away, but for new code one should _only_ use this if they _have_
to remove non database data. Even then it's usually better to do this in
a service class as this gives you more control over how to remove the
data (e.g. in bulk).
From the Ruby style guide:
# bad
class FooError < StandardError
end
# okish
class FooError < StandardError; end
# good
FooError = Class.new(StandardError)
This cop does that, but only for error classes (classes where the
superclass ends in 'Error'). We have empty controllers and models, which
are perfectly valid empty classes.
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.
Rémy Coutable