| 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
|
|
|
|
|
|
- ci_builds -- 33 million rows, 55 GB
- merge_request_diff_files -- 5 million rows, 9 GB (and growing rapidly)
- merge_request_diffs -- 5 million rows, 190 GB
|
|
These indexes are not recorded in the WAL (at least until PostgreSQL
10) and this isn't worth the minor performance improvement over btree
indexes.
|
|
'timestamps_with_timezone'
|
|
Signed-off-by: Rémy Coutable <remy@rymai.me>
|
|
|
|
We're going to add another cop that deals with another aspect of
`add_column_with_default`, so we need to separate them.
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
There are currently two cops for this:
* Migration/AddIndex: checks if indexes are added concurrently
* Migration/ColumnWithDefault: checks if columns with default values are
added in a concurrent manner
Both cops are fairly simple and make no attempt at correcting the code
as this is quite hard to do (e.g. modifications may need to be applied
in various places in the same file). They however should provide enough
to catch people ignoring the comments in generated migrations telling
them to use add_concurrent_index or add_column_with_default.
|
