| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This cop will analyze migrations that add columns with string, and
report an offense if the string has no limit enforced
Related to https://gitlab.com/gitlab-org/gitlab-ce/issues/64505
|
|
|
|
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.
|
|
|
|
These are all over 20 GB on GitLab.com. merge_request_diff_commits is several
hundred gigabytes in size.
|
|
{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.
|
|
|
|
|
|
Signed-off-by: Rémy Coutable <remy@rymai.me>
|
|
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.
|
|
The types `timestamp` and `datetime` are aliases:
https://github.com/rails/rails/blob/v4.2.10/activerecord/lib/active_record/connection_adapters/abstract/schema_definitions.rb#L362-L364
|
|
|
