| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
|
| |
- 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.
|
| |
|
|
|
|
|
| |
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 cop has been renamed to ActiveRecordSerialize to match the way
"ActiveRecord" is usually written.
|
| |
|
|
|
|
|
|
| |
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).
|
| | |
|
| |
|
|
| |
Resolves the `codeclimate` CI failure
|
| |
|
|
|
| |
This cop adds an offense when `before`, `after`, or `around` are used as
single-line blocks.
|
| |
|
|
| |
'timestamps_with_timezone'
|
| |
|
|
|
|
|
|
| |
One should really use a separate table instead of using polymorphic
associations.
See https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/11168 for
more information.
|
| |
|
|
| |
explicitly set 'status' in 'destroy' actions of controllers
|
| |
|
|
|
| |
This Cop blacklists the use of ActiveRecord's "serialize" method, except
for cases where we already use this.
|
| |
|
|
| |
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.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 reverts commit e00fb2bdc2090e9cabeb1eb35a2672a882cc96e9.
# Conflicts:
# .rubocop.yml
# .rubocop_todo.yml
# lib/gitlab/ci/config/entry/global.rb
# lib/gitlab/ci/config/entry/jobs.rb
# spec/lib/gitlab/ci/config/entry/factory_spec.rb
# spec/lib/gitlab/ci/config/entry/global_spec.rb
# spec/lib/gitlab/ci/config/entry/job_spec.rb
# spec/lib/gitlab/ci/status/build/factory_spec.rb
# spec/lib/gitlab/incoming_email_spec.rb
|
| |
|
|
| |
This reverts commit cb10b725c8929b8b4460f89c9d96c773af39ba6b.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
code fix for aesthetic & conventions
remove unused proc
|
|
|
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.
|
