2014-10-08 09:44:25 -04:00
|
|
|
require 'spec_helper'
|
|
|
|
|
|
|
|
describe SnippetsFinder do
|
2018-01-18 11:07:06 -05:00
|
|
|
include Gitlab::Allowable
|
|
|
|
using RSpec::Parameterized::TableSyntax
|
2014-10-08 09:44:25 -04:00
|
|
|
|
Rewrite SnippetsFinder to improve performance
This completely rewrites the SnippetsFinder class from the ground up in
order to improve its performance. The old code was beyond salvaging. It
was complex, included various Rails 5 workarounds, comments that
shouldn't be necessary, and most important of all: it produced a really
poorly performing database query.
As a result, I opted for rewriting the finder from scratch, instead of
trying to patch the existing code. Instead of trying to reuse as many
existing methods as possible, I opted for defining new methods
specifically meant for the SnippetsFinder. This requires some extra code
here and there, but allows us to have much more control over the
resulting SQL queries. It is these changes that then allow us to produce
a _much_ more efficient query.
To illustrate how bad the old query was, we will use my own snippets as
an example. Currently I have 52 snippets, most of which are global ones.
To retrieve these, you would run the following Ruby code:
user = User.find_by(username: 'yorickpeterse')
SnippetsFinder.new(user, author: user).execute
On GitLab.com the resulting query will take between 10 and 15 seconds to
run, producing the query plan found at
https://explain.depesz.com/s/Y5IX. Apart from the long execution time,
the total number of buffers (the sum of all shared hits) is around 185
GB, though the real number is probably (hopefully) much lower as I doubt
simply summing these numbers produces the true total number of buffers
used.
The new query's plan can be found at https://explain.depesz.com/s/wHdN,
and this query takes between 10 and 100-ish milliseconds to run. The
total number of buffers used is only about 30 MB.
Fixes https://gitlab.com/gitlab-org/gitlab-ce/issues/52639
2018-10-25 11:35:31 -04:00
|
|
|
describe '#initialize' do
|
|
|
|
it 'raises ArgumentError when a project and author are given' do
|
|
|
|
user = build(:user)
|
|
|
|
project = build(:project)
|
2016-11-26 10:37:26 -05:00
|
|
|
|
Rewrite SnippetsFinder to improve performance
This completely rewrites the SnippetsFinder class from the ground up in
order to improve its performance. The old code was beyond salvaging. It
was complex, included various Rails 5 workarounds, comments that
shouldn't be necessary, and most important of all: it produced a really
poorly performing database query.
As a result, I opted for rewriting the finder from scratch, instead of
trying to patch the existing code. Instead of trying to reuse as many
existing methods as possible, I opted for defining new methods
specifically meant for the SnippetsFinder. This requires some extra code
here and there, but allows us to have much more control over the
resulting SQL queries. It is these changes that then allow us to produce
a _much_ more efficient query.
To illustrate how bad the old query was, we will use my own snippets as
an example. Currently I have 52 snippets, most of which are global ones.
To retrieve these, you would run the following Ruby code:
user = User.find_by(username: 'yorickpeterse')
SnippetsFinder.new(user, author: user).execute
On GitLab.com the resulting query will take between 10 and 15 seconds to
run, producing the query plan found at
https://explain.depesz.com/s/Y5IX. Apart from the long execution time,
the total number of buffers (the sum of all shared hits) is around 185
GB, though the real number is probably (hopefully) much lower as I doubt
simply summing these numbers produces the true total number of buffers
used.
The new query's plan can be found at https://explain.depesz.com/s/wHdN,
and this query takes between 10 and 100-ish milliseconds to run. The
total number of buffers used is only about 30 MB.
Fixes https://gitlab.com/gitlab-org/gitlab-ce/issues/52639
2018-10-25 11:35:31 -04:00
|
|
|
expect { described_class.new(user, author: user, project: project) }
|
|
|
|
.to raise_error(ArgumentError)
|
2014-10-08 09:44:25 -04:00
|
|
|
end
|
2016-11-26 10:37:26 -05:00
|
|
|
end
|
|
|
|
|
2017-04-28 18:06:27 -04:00
|
|
|
context 'filter by scope' do
|
2018-01-18 11:07:06 -05:00
|
|
|
let(:user) { create :user }
|
2017-04-28 18:06:27 -04:00
|
|
|
let!(:snippet1) { create(:personal_snippet, :private, author: user) }
|
|
|
|
let!(:snippet2) { create(:personal_snippet, :internal, author: user) }
|
|
|
|
let!(:snippet3) { create(:personal_snippet, :public, author: user) }
|
|
|
|
|
|
|
|
it "returns all snippets for 'all' scope" do
|
2017-05-10 05:21:33 -04:00
|
|
|
snippets = described_class.new(user, scope: :all).execute
|
2017-04-28 18:06:27 -04:00
|
|
|
|
|
|
|
expect(snippets).to include(snippet1, snippet2, snippet3)
|
|
|
|
end
|
|
|
|
|
|
|
|
it "returns all snippets for 'are_private' scope" do
|
2017-05-10 05:21:33 -04:00
|
|
|
snippets = described_class.new(user, scope: :are_private).execute
|
2017-04-28 18:06:27 -04:00
|
|
|
|
|
|
|
expect(snippets).to include(snippet1)
|
|
|
|
expect(snippets).not_to include(snippet2, snippet3)
|
|
|
|
end
|
|
|
|
|
2018-01-18 11:07:06 -05:00
|
|
|
it "returns all snippets for 'are_internal' scope" do
|
2017-05-10 05:21:33 -04:00
|
|
|
snippets = described_class.new(user, scope: :are_internal).execute
|
2017-04-28 18:06:27 -04:00
|
|
|
|
|
|
|
expect(snippets).to include(snippet2)
|
|
|
|
expect(snippets).not_to include(snippet1, snippet3)
|
|
|
|
end
|
|
|
|
|
|
|
|
it "returns all snippets for 'are_private' scope" do
|
2017-05-10 05:21:33 -04:00
|
|
|
snippets = described_class.new(user, scope: :are_public).execute
|
2017-04-28 18:06:27 -04:00
|
|
|
|
|
|
|
expect(snippets).to include(snippet3)
|
|
|
|
expect(snippets).not_to include(snippet1, snippet2)
|
|
|
|
end
|
|
|
|
end
|
|
|
|
|
|
|
|
context 'filter by author' do
|
2018-01-18 11:07:06 -05:00
|
|
|
let(:user) { create :user }
|
|
|
|
let(:user1) { create :user }
|
2016-11-26 10:37:26 -05:00
|
|
|
let!(:snippet1) { create(:personal_snippet, :private, author: user) }
|
|
|
|
let!(:snippet2) { create(:personal_snippet, :internal, author: user) }
|
|
|
|
let!(:snippet3) { create(:personal_snippet, :public, author: user) }
|
2014-10-08 09:44:25 -04:00
|
|
|
|
|
|
|
it "returns all public and internal snippets" do
|
2017-05-10 05:21:33 -04:00
|
|
|
snippets = described_class.new(user1, author: user).execute
|
2017-04-28 18:06:27 -04:00
|
|
|
|
2016-11-26 10:37:26 -05:00
|
|
|
expect(snippets).to include(snippet2, snippet3)
|
|
|
|
expect(snippets).not_to include(snippet1)
|
2014-10-08 09:44:25 -04:00
|
|
|
end
|
|
|
|
|
|
|
|
it "returns internal snippets" do
|
Rewrite SnippetsFinder to improve performance
This completely rewrites the SnippetsFinder class from the ground up in
order to improve its performance. The old code was beyond salvaging. It
was complex, included various Rails 5 workarounds, comments that
shouldn't be necessary, and most important of all: it produced a really
poorly performing database query.
As a result, I opted for rewriting the finder from scratch, instead of
trying to patch the existing code. Instead of trying to reuse as many
existing methods as possible, I opted for defining new methods
specifically meant for the SnippetsFinder. This requires some extra code
here and there, but allows us to have much more control over the
resulting SQL queries. It is these changes that then allow us to produce
a _much_ more efficient query.
To illustrate how bad the old query was, we will use my own snippets as
an example. Currently I have 52 snippets, most of which are global ones.
To retrieve these, you would run the following Ruby code:
user = User.find_by(username: 'yorickpeterse')
SnippetsFinder.new(user, author: user).execute
On GitLab.com the resulting query will take between 10 and 15 seconds to
run, producing the query plan found at
https://explain.depesz.com/s/Y5IX. Apart from the long execution time,
the total number of buffers (the sum of all shared hits) is around 185
GB, though the real number is probably (hopefully) much lower as I doubt
simply summing these numbers produces the true total number of buffers
used.
The new query's plan can be found at https://explain.depesz.com/s/wHdN,
and this query takes between 10 and 100-ish milliseconds to run. The
total number of buffers used is only about 30 MB.
Fixes https://gitlab.com/gitlab-org/gitlab-ce/issues/52639
2018-10-25 11:35:31 -04:00
|
|
|
snippets = described_class.new(user, author: user, scope: :are_internal).execute
|
2017-04-28 18:06:27 -04:00
|
|
|
|
2016-11-26 10:37:26 -05:00
|
|
|
expect(snippets).to include(snippet2)
|
|
|
|
expect(snippets).not_to include(snippet1, snippet3)
|
2014-10-08 09:44:25 -04:00
|
|
|
end
|
|
|
|
|
|
|
|
it "returns private snippets" do
|
Rewrite SnippetsFinder to improve performance
This completely rewrites the SnippetsFinder class from the ground up in
order to improve its performance. The old code was beyond salvaging. It
was complex, included various Rails 5 workarounds, comments that
shouldn't be necessary, and most important of all: it produced a really
poorly performing database query.
As a result, I opted for rewriting the finder from scratch, instead of
trying to patch the existing code. Instead of trying to reuse as many
existing methods as possible, I opted for defining new methods
specifically meant for the SnippetsFinder. This requires some extra code
here and there, but allows us to have much more control over the
resulting SQL queries. It is these changes that then allow us to produce
a _much_ more efficient query.
To illustrate how bad the old query was, we will use my own snippets as
an example. Currently I have 52 snippets, most of which are global ones.
To retrieve these, you would run the following Ruby code:
user = User.find_by(username: 'yorickpeterse')
SnippetsFinder.new(user, author: user).execute
On GitLab.com the resulting query will take between 10 and 15 seconds to
run, producing the query plan found at
https://explain.depesz.com/s/Y5IX. Apart from the long execution time,
the total number of buffers (the sum of all shared hits) is around 185
GB, though the real number is probably (hopefully) much lower as I doubt
simply summing these numbers produces the true total number of buffers
used.
The new query's plan can be found at https://explain.depesz.com/s/wHdN,
and this query takes between 10 and 100-ish milliseconds to run. The
total number of buffers used is only about 30 MB.
Fixes https://gitlab.com/gitlab-org/gitlab-ce/issues/52639
2018-10-25 11:35:31 -04:00
|
|
|
snippets = described_class.new(user, author: user, scope: :are_private).execute
|
2017-04-28 18:06:27 -04:00
|
|
|
|
2016-11-26 10:37:26 -05:00
|
|
|
expect(snippets).to include(snippet1)
|
|
|
|
expect(snippets).not_to include(snippet2, snippet3)
|
2014-10-08 09:44:25 -04:00
|
|
|
end
|
|
|
|
|
|
|
|
it "returns public snippets" do
|
Rewrite SnippetsFinder to improve performance
This completely rewrites the SnippetsFinder class from the ground up in
order to improve its performance. The old code was beyond salvaging. It
was complex, included various Rails 5 workarounds, comments that
shouldn't be necessary, and most important of all: it produced a really
poorly performing database query.
As a result, I opted for rewriting the finder from scratch, instead of
trying to patch the existing code. Instead of trying to reuse as many
existing methods as possible, I opted for defining new methods
specifically meant for the SnippetsFinder. This requires some extra code
here and there, but allows us to have much more control over the
resulting SQL queries. It is these changes that then allow us to produce
a _much_ more efficient query.
To illustrate how bad the old query was, we will use my own snippets as
an example. Currently I have 52 snippets, most of which are global ones.
To retrieve these, you would run the following Ruby code:
user = User.find_by(username: 'yorickpeterse')
SnippetsFinder.new(user, author: user).execute
On GitLab.com the resulting query will take between 10 and 15 seconds to
run, producing the query plan found at
https://explain.depesz.com/s/Y5IX. Apart from the long execution time,
the total number of buffers (the sum of all shared hits) is around 185
GB, though the real number is probably (hopefully) much lower as I doubt
simply summing these numbers produces the true total number of buffers
used.
The new query's plan can be found at https://explain.depesz.com/s/wHdN,
and this query takes between 10 and 100-ish milliseconds to run. The
total number of buffers used is only about 30 MB.
Fixes https://gitlab.com/gitlab-org/gitlab-ce/issues/52639
2018-10-25 11:35:31 -04:00
|
|
|
snippets = described_class.new(user, author: user, scope: :are_public).execute
|
2017-04-28 18:06:27 -04:00
|
|
|
|
2016-11-26 10:37:26 -05:00
|
|
|
expect(snippets).to include(snippet3)
|
|
|
|
expect(snippets).not_to include(snippet1, snippet2)
|
2014-10-08 09:44:25 -04:00
|
|
|
end
|
|
|
|
|
|
|
|
it "returns all snippets" do
|
2017-05-10 05:21:33 -04:00
|
|
|
snippets = described_class.new(user, author: user).execute
|
2017-04-28 18:06:27 -04:00
|
|
|
|
2016-11-26 10:37:26 -05:00
|
|
|
expect(snippets).to include(snippet1, snippet2, snippet3)
|
2014-10-08 09:44:25 -04:00
|
|
|
end
|
2014-10-24 12:24:49 -04:00
|
|
|
|
|
|
|
it "returns only public snippets if unauthenticated user" do
|
2017-05-10 05:21:33 -04:00
|
|
|
snippets = described_class.new(nil, author: user).execute
|
2017-04-28 18:06:27 -04:00
|
|
|
|
2016-11-26 10:37:26 -05:00
|
|
|
expect(snippets).to include(snippet3)
|
|
|
|
expect(snippets).not_to include(snippet2, snippet1)
|
2014-10-24 12:24:49 -04:00
|
|
|
end
|
Rewrite SnippetsFinder to improve performance
This completely rewrites the SnippetsFinder class from the ground up in
order to improve its performance. The old code was beyond salvaging. It
was complex, included various Rails 5 workarounds, comments that
shouldn't be necessary, and most important of all: it produced a really
poorly performing database query.
As a result, I opted for rewriting the finder from scratch, instead of
trying to patch the existing code. Instead of trying to reuse as many
existing methods as possible, I opted for defining new methods
specifically meant for the SnippetsFinder. This requires some extra code
here and there, but allows us to have much more control over the
resulting SQL queries. It is these changes that then allow us to produce
a _much_ more efficient query.
To illustrate how bad the old query was, we will use my own snippets as
an example. Currently I have 52 snippets, most of which are global ones.
To retrieve these, you would run the following Ruby code:
user = User.find_by(username: 'yorickpeterse')
SnippetsFinder.new(user, author: user).execute
On GitLab.com the resulting query will take between 10 and 15 seconds to
run, producing the query plan found at
https://explain.depesz.com/s/Y5IX. Apart from the long execution time,
the total number of buffers (the sum of all shared hits) is around 185
GB, though the real number is probably (hopefully) much lower as I doubt
simply summing these numbers produces the true total number of buffers
used.
The new query's plan can be found at https://explain.depesz.com/s/wHdN,
and this query takes between 10 and 100-ish milliseconds to run. The
total number of buffers used is only about 30 MB.
Fixes https://gitlab.com/gitlab-org/gitlab-ce/issues/52639
2018-10-25 11:35:31 -04:00
|
|
|
|
|
|
|
it 'returns all snippets for an admin' do
|
|
|
|
admin = create(:user, :admin)
|
|
|
|
snippets = described_class.new(admin, author: user).execute
|
|
|
|
|
|
|
|
expect(snippets).to include(snippet1, snippet2, snippet3)
|
|
|
|
end
|
2014-10-08 09:44:25 -04:00
|
|
|
end
|
|
|
|
|
2017-04-28 18:06:27 -04:00
|
|
|
context 'filter by project' do
|
2018-01-18 11:07:06 -05:00
|
|
|
let(:user) { create :user }
|
|
|
|
let(:group) { create :group, :public }
|
|
|
|
let(:project1) { create(:project, :public, group: group) }
|
|
|
|
|
2014-10-08 09:44:25 -04:00
|
|
|
before do
|
2016-03-08 16:40:45 -05:00
|
|
|
@snippet1 = create(:project_snippet, :private, project: project1)
|
|
|
|
@snippet2 = create(:project_snippet, :internal, project: project1)
|
|
|
|
@snippet3 = create(:project_snippet, :public, project: project1)
|
2014-10-08 09:44:25 -04:00
|
|
|
end
|
|
|
|
|
|
|
|
it "returns public snippets for unauthorized user" do
|
2017-05-10 05:21:33 -04:00
|
|
|
snippets = described_class.new(nil, project: project1).execute
|
2017-04-28 18:06:27 -04:00
|
|
|
|
2015-02-12 13:17:35 -05:00
|
|
|
expect(snippets).to include(@snippet3)
|
|
|
|
expect(snippets).not_to include(@snippet1, @snippet2)
|
2014-10-08 09:44:25 -04:00
|
|
|
end
|
|
|
|
|
2016-12-09 17:01:08 -05:00
|
|
|
it "returns public and internal snippets for non project members" do
|
2017-05-10 05:21:33 -04:00
|
|
|
snippets = described_class.new(user, project: project1).execute
|
2017-04-28 18:06:27 -04:00
|
|
|
|
2015-02-12 13:17:35 -05:00
|
|
|
expect(snippets).to include(@snippet2, @snippet3)
|
|
|
|
expect(snippets).not_to include(@snippet1)
|
2014-10-08 09:44:25 -04:00
|
|
|
end
|
|
|
|
|
2016-12-09 17:01:08 -05:00
|
|
|
it "returns public snippets for non project members" do
|
Rewrite SnippetsFinder to improve performance
This completely rewrites the SnippetsFinder class from the ground up in
order to improve its performance. The old code was beyond salvaging. It
was complex, included various Rails 5 workarounds, comments that
shouldn't be necessary, and most important of all: it produced a really
poorly performing database query.
As a result, I opted for rewriting the finder from scratch, instead of
trying to patch the existing code. Instead of trying to reuse as many
existing methods as possible, I opted for defining new methods
specifically meant for the SnippetsFinder. This requires some extra code
here and there, but allows us to have much more control over the
resulting SQL queries. It is these changes that then allow us to produce
a _much_ more efficient query.
To illustrate how bad the old query was, we will use my own snippets as
an example. Currently I have 52 snippets, most of which are global ones.
To retrieve these, you would run the following Ruby code:
user = User.find_by(username: 'yorickpeterse')
SnippetsFinder.new(user, author: user).execute
On GitLab.com the resulting query will take between 10 and 15 seconds to
run, producing the query plan found at
https://explain.depesz.com/s/Y5IX. Apart from the long execution time,
the total number of buffers (the sum of all shared hits) is around 185
GB, though the real number is probably (hopefully) much lower as I doubt
simply summing these numbers produces the true total number of buffers
used.
The new query's plan can be found at https://explain.depesz.com/s/wHdN,
and this query takes between 10 and 100-ish milliseconds to run. The
total number of buffers used is only about 30 MB.
Fixes https://gitlab.com/gitlab-org/gitlab-ce/issues/52639
2018-10-25 11:35:31 -04:00
|
|
|
snippets = described_class.new(user, project: project1, scope: :are_public).execute
|
2017-04-28 18:06:27 -04:00
|
|
|
|
2016-12-09 17:01:08 -05:00
|
|
|
expect(snippets).to include(@snippet3)
|
|
|
|
expect(snippets).not_to include(@snippet1, @snippet2)
|
|
|
|
end
|
|
|
|
|
|
|
|
it "returns internal snippets for non project members" do
|
Rewrite SnippetsFinder to improve performance
This completely rewrites the SnippetsFinder class from the ground up in
order to improve its performance. The old code was beyond salvaging. It
was complex, included various Rails 5 workarounds, comments that
shouldn't be necessary, and most important of all: it produced a really
poorly performing database query.
As a result, I opted for rewriting the finder from scratch, instead of
trying to patch the existing code. Instead of trying to reuse as many
existing methods as possible, I opted for defining new methods
specifically meant for the SnippetsFinder. This requires some extra code
here and there, but allows us to have much more control over the
resulting SQL queries. It is these changes that then allow us to produce
a _much_ more efficient query.
To illustrate how bad the old query was, we will use my own snippets as
an example. Currently I have 52 snippets, most of which are global ones.
To retrieve these, you would run the following Ruby code:
user = User.find_by(username: 'yorickpeterse')
SnippetsFinder.new(user, author: user).execute
On GitLab.com the resulting query will take between 10 and 15 seconds to
run, producing the query plan found at
https://explain.depesz.com/s/Y5IX. Apart from the long execution time,
the total number of buffers (the sum of all shared hits) is around 185
GB, though the real number is probably (hopefully) much lower as I doubt
simply summing these numbers produces the true total number of buffers
used.
The new query's plan can be found at https://explain.depesz.com/s/wHdN,
and this query takes between 10 and 100-ish milliseconds to run. The
total number of buffers used is only about 30 MB.
Fixes https://gitlab.com/gitlab-org/gitlab-ce/issues/52639
2018-10-25 11:35:31 -04:00
|
|
|
snippets = described_class.new(user, project: project1, scope: :are_internal).execute
|
2017-04-28 18:06:27 -04:00
|
|
|
|
2016-12-09 17:01:08 -05:00
|
|
|
expect(snippets).to include(@snippet2)
|
|
|
|
expect(snippets).not_to include(@snippet1, @snippet3)
|
|
|
|
end
|
|
|
|
|
|
|
|
it "does not return private snippets for non project members" do
|
Rewrite SnippetsFinder to improve performance
This completely rewrites the SnippetsFinder class from the ground up in
order to improve its performance. The old code was beyond salvaging. It
was complex, included various Rails 5 workarounds, comments that
shouldn't be necessary, and most important of all: it produced a really
poorly performing database query.
As a result, I opted for rewriting the finder from scratch, instead of
trying to patch the existing code. Instead of trying to reuse as many
existing methods as possible, I opted for defining new methods
specifically meant for the SnippetsFinder. This requires some extra code
here and there, but allows us to have much more control over the
resulting SQL queries. It is these changes that then allow us to produce
a _much_ more efficient query.
To illustrate how bad the old query was, we will use my own snippets as
an example. Currently I have 52 snippets, most of which are global ones.
To retrieve these, you would run the following Ruby code:
user = User.find_by(username: 'yorickpeterse')
SnippetsFinder.new(user, author: user).execute
On GitLab.com the resulting query will take between 10 and 15 seconds to
run, producing the query plan found at
https://explain.depesz.com/s/Y5IX. Apart from the long execution time,
the total number of buffers (the sum of all shared hits) is around 185
GB, though the real number is probably (hopefully) much lower as I doubt
simply summing these numbers produces the true total number of buffers
used.
The new query's plan can be found at https://explain.depesz.com/s/wHdN,
and this query takes between 10 and 100-ish milliseconds to run. The
total number of buffers used is only about 30 MB.
Fixes https://gitlab.com/gitlab-org/gitlab-ce/issues/52639
2018-10-25 11:35:31 -04:00
|
|
|
snippets = described_class.new(user, project: project1, scope: :are_private).execute
|
2017-04-28 18:06:27 -04:00
|
|
|
|
2016-12-09 17:01:08 -05:00
|
|
|
expect(snippets).not_to include(@snippet1, @snippet2, @snippet3)
|
|
|
|
end
|
|
|
|
|
2014-10-08 09:44:25 -04:00
|
|
|
it "returns all snippets for project members" do
|
2017-12-22 03:18:28 -05:00
|
|
|
project1.add_developer(user)
|
2017-04-28 18:06:27 -04:00
|
|
|
|
2017-05-10 05:21:33 -04:00
|
|
|
snippets = described_class.new(user, project: project1).execute
|
2017-04-28 18:06:27 -04:00
|
|
|
|
2015-02-12 13:17:35 -05:00
|
|
|
expect(snippets).to include(@snippet1, @snippet2, @snippet3)
|
2014-10-08 09:44:25 -04:00
|
|
|
end
|
2016-12-09 17:01:08 -05:00
|
|
|
|
|
|
|
it "returns private snippets for project members" do
|
2017-12-22 03:18:28 -05:00
|
|
|
project1.add_developer(user)
|
2017-04-28 18:06:27 -04:00
|
|
|
|
Rewrite SnippetsFinder to improve performance
This completely rewrites the SnippetsFinder class from the ground up in
order to improve its performance. The old code was beyond salvaging. It
was complex, included various Rails 5 workarounds, comments that
shouldn't be necessary, and most important of all: it produced a really
poorly performing database query.
As a result, I opted for rewriting the finder from scratch, instead of
trying to patch the existing code. Instead of trying to reuse as many
existing methods as possible, I opted for defining new methods
specifically meant for the SnippetsFinder. This requires some extra code
here and there, but allows us to have much more control over the
resulting SQL queries. It is these changes that then allow us to produce
a _much_ more efficient query.
To illustrate how bad the old query was, we will use my own snippets as
an example. Currently I have 52 snippets, most of which are global ones.
To retrieve these, you would run the following Ruby code:
user = User.find_by(username: 'yorickpeterse')
SnippetsFinder.new(user, author: user).execute
On GitLab.com the resulting query will take between 10 and 15 seconds to
run, producing the query plan found at
https://explain.depesz.com/s/Y5IX. Apart from the long execution time,
the total number of buffers (the sum of all shared hits) is around 185
GB, though the real number is probably (hopefully) much lower as I doubt
simply summing these numbers produces the true total number of buffers
used.
The new query's plan can be found at https://explain.depesz.com/s/wHdN,
and this query takes between 10 and 100-ish milliseconds to run. The
total number of buffers used is only about 30 MB.
Fixes https://gitlab.com/gitlab-org/gitlab-ce/issues/52639
2018-10-25 11:35:31 -04:00
|
|
|
snippets = described_class.new(user, project: project1, scope: :are_private).execute
|
2017-04-28 18:06:27 -04:00
|
|
|
|
2016-12-09 17:01:08 -05:00
|
|
|
expect(snippets).to include(@snippet1)
|
|
|
|
end
|
Rewrite SnippetsFinder to improve performance
This completely rewrites the SnippetsFinder class from the ground up in
order to improve its performance. The old code was beyond salvaging. It
was complex, included various Rails 5 workarounds, comments that
shouldn't be necessary, and most important of all: it produced a really
poorly performing database query.
As a result, I opted for rewriting the finder from scratch, instead of
trying to patch the existing code. Instead of trying to reuse as many
existing methods as possible, I opted for defining new methods
specifically meant for the SnippetsFinder. This requires some extra code
here and there, but allows us to have much more control over the
resulting SQL queries. It is these changes that then allow us to produce
a _much_ more efficient query.
To illustrate how bad the old query was, we will use my own snippets as
an example. Currently I have 52 snippets, most of which are global ones.
To retrieve these, you would run the following Ruby code:
user = User.find_by(username: 'yorickpeterse')
SnippetsFinder.new(user, author: user).execute
On GitLab.com the resulting query will take between 10 and 15 seconds to
run, producing the query plan found at
https://explain.depesz.com/s/Y5IX. Apart from the long execution time,
the total number of buffers (the sum of all shared hits) is around 185
GB, though the real number is probably (hopefully) much lower as I doubt
simply summing these numbers produces the true total number of buffers
used.
The new query's plan can be found at https://explain.depesz.com/s/wHdN,
and this query takes between 10 and 100-ish milliseconds to run. The
total number of buffers used is only about 30 MB.
Fixes https://gitlab.com/gitlab-org/gitlab-ce/issues/52639
2018-10-25 11:35:31 -04:00
|
|
|
|
|
|
|
it 'returns all snippets for an admin' do
|
|
|
|
admin = create(:user, :admin)
|
|
|
|
snippets = described_class.new(admin, project: project1).execute
|
|
|
|
|
|
|
|
expect(snippets).to include(@snippet1, @snippet2, @snippet3)
|
|
|
|
end
|
2014-10-08 09:44:25 -04:00
|
|
|
end
|
2018-01-18 11:07:06 -05:00
|
|
|
|
2017-12-11 09:21:06 -05:00
|
|
|
describe '#execute' do
|
|
|
|
let(:project) { create(:project, :public) }
|
|
|
|
let!(:project_snippet) { create(:project_snippet, :public, project: project) }
|
|
|
|
let!(:personal_snippet) { create(:personal_snippet, :public) }
|
|
|
|
let(:user) { create(:user) }
|
|
|
|
subject(:finder) { described_class.new(user) }
|
|
|
|
|
|
|
|
it 'returns project- and personal snippets' do
|
|
|
|
expect(finder.execute).to contain_exactly(project_snippet, personal_snippet)
|
|
|
|
end
|
|
|
|
|
|
|
|
context 'when the user cannot read cross project' do
|
|
|
|
before do
|
|
|
|
allow(Ability).to receive(:allowed?).and_call_original
|
|
|
|
allow(Ability).to receive(:allowed?).with(user, :read_cross_project) { false }
|
|
|
|
end
|
|
|
|
|
|
|
|
it 'returns only personal snippets when the user cannot read cross project' do
|
|
|
|
expect(finder.execute).to contain_exactly(personal_snippet)
|
|
|
|
end
|
|
|
|
end
|
2018-01-18 11:07:06 -05:00
|
|
|
end
|
Rewrite SnippetsFinder to improve performance
This completely rewrites the SnippetsFinder class from the ground up in
order to improve its performance. The old code was beyond salvaging. It
was complex, included various Rails 5 workarounds, comments that
shouldn't be necessary, and most important of all: it produced a really
poorly performing database query.
As a result, I opted for rewriting the finder from scratch, instead of
trying to patch the existing code. Instead of trying to reuse as many
existing methods as possible, I opted for defining new methods
specifically meant for the SnippetsFinder. This requires some extra code
here and there, but allows us to have much more control over the
resulting SQL queries. It is these changes that then allow us to produce
a _much_ more efficient query.
To illustrate how bad the old query was, we will use my own snippets as
an example. Currently I have 52 snippets, most of which are global ones.
To retrieve these, you would run the following Ruby code:
user = User.find_by(username: 'yorickpeterse')
SnippetsFinder.new(user, author: user).execute
On GitLab.com the resulting query will take between 10 and 15 seconds to
run, producing the query plan found at
https://explain.depesz.com/s/Y5IX. Apart from the long execution time,
the total number of buffers (the sum of all shared hits) is around 185
GB, though the real number is probably (hopefully) much lower as I doubt
simply summing these numbers produces the true total number of buffers
used.
The new query's plan can be found at https://explain.depesz.com/s/wHdN,
and this query takes between 10 and 100-ish milliseconds to run. The
total number of buffers used is only about 30 MB.
Fixes https://gitlab.com/gitlab-org/gitlab-ce/issues/52639
2018-10-25 11:35:31 -04:00
|
|
|
|
|
|
|
it_behaves_like 'snippet visibility'
|
2014-10-08 09:44:25 -04:00
|
|
|
end
|