8a72f5c427
This commit adds the module `FromUnion`, which provides the class method
`from_union`. This simplifies the process of selecting data from the
result of a UNION, and reduces the likelihood of making mistakes. As a
result, instead of this:
union = Gitlab::SQL::Union.new([foo, bar])
Foo.from("(#{union.to_sql}) #{Foo.table_name}")
We can now write this instead:
Foo.from_union([foo, bar])
This commit also includes some changes to make this new setup work
properly. For example, a bug in Rails 4
(https://github.com/rails/rails/issues/24193) would break the use of
`from("sub-query-here").includes(:relation)` in certain cases. There was
also a CI query which appeared to repeat a lot of conditions from an
outer query on an inner query, which isn't necessary.
Finally, we include a RuboCop cop to ensure developers use this new
module, instead of using Gitlab::SQL::Union directly.
Fixes https://gitlab.com/gitlab-org/gitlab-ce/issues/51307
25 lines
689 B
Ruby
25 lines
689 B
Ruby
# frozen_string_literal: true
|
|
|
|
require 'spec_helper'
|
|
require 'rubocop'
|
|
require 'rubocop/rspec/support'
|
|
require_relative '../../../../rubocop/cop/gitlab/union'
|
|
|
|
describe RuboCop::Cop::Gitlab::Union do
|
|
include CopHelper
|
|
|
|
subject(:cop) { described_class.new }
|
|
|
|
it 'flags the use of Gitlab::SQL::Union.new' do
|
|
expect_offense(<<~SOURCE)
|
|
Gitlab::SQL::Union.new([foo])
|
|
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Use the `FromUnion` concern, instead of using `Gitlab::SQL::Union` directly
|
|
SOURCE
|
|
end
|
|
|
|
it 'does not flag the use of Gitlab::SQL::Union in a spec' do
|
|
allow(cop).to receive(:in_spec?).and_return(true)
|
|
|
|
expect_no_offenses('Gitlab::SQL::Union.new([foo])')
|
|
end
|
|
end
|