2014-01-15 09:32:07 -05:00
|
|
|
require 'spec_helper'
|
|
|
|
|
2014-02-25 12:21:53 -05:00
|
|
|
describe IssuesFinder do
|
2019-03-19 13:25:10 -04:00
|
|
|
include_context 'IssuesFinder context'
|
2014-01-15 09:32:07 -05:00
|
|
|
|
2016-05-12 07:20:09 -04:00
|
|
|
describe '#execute' do
|
2019-03-19 13:25:10 -04:00
|
|
|
include_context 'IssuesFinder#execute context'
|
2016-12-12 03:43:56 -05:00
|
|
|
|
2014-12-05 10:25:22 -05:00
|
|
|
context 'scope: all' do
|
2016-05-12 07:20:09 -04:00
|
|
|
let(:scope) { 'all' }
|
2014-01-15 09:32:07 -05:00
|
|
|
|
2016-05-12 07:20:09 -04:00
|
|
|
it 'returns all issues' do
|
2018-01-24 01:06:24 -05:00
|
|
|
expect(issues).to contain_exactly(issue1, issue2, issue3, issue4)
|
2014-12-05 10:25:22 -05:00
|
|
|
end
|
2014-01-15 09:32:07 -05:00
|
|
|
|
2019-04-07 14:35:16 -04:00
|
|
|
context 'assignee filtering' do
|
|
|
|
let(:issuables) { issues }
|
2016-05-12 07:20:09 -04:00
|
|
|
|
2019-04-07 14:35:16 -04:00
|
|
|
it_behaves_like 'assignee ID filter' do
|
|
|
|
let(:params) { { assignee_id: user.id } }
|
|
|
|
let(:expected_issuables) { [issue1, issue2] }
|
2016-05-12 07:20:09 -04:00
|
|
|
end
|
2019-03-19 13:25:10 -04:00
|
|
|
|
2019-04-07 14:35:16 -04:00
|
|
|
it_behaves_like 'assignee username filter' do
|
|
|
|
before do
|
|
|
|
project2.add_developer(user3)
|
|
|
|
issue3.assignees = [user2, user3]
|
|
|
|
end
|
2019-03-19 13:25:10 -04:00
|
|
|
|
2019-04-07 14:35:16 -04:00
|
|
|
set(:user3) { create(:user) }
|
|
|
|
let(:params) { { assignee_username: [user2.username, user3.username] } }
|
|
|
|
let(:expected_issuables) { [issue3] }
|
2019-03-19 13:25:10 -04:00
|
|
|
end
|
|
|
|
|
2019-04-07 14:35:16 -04:00
|
|
|
it_behaves_like 'no assignee filter' do
|
|
|
|
set(:user3) { create(:user) }
|
|
|
|
let(:expected_issuables) { [issue4] }
|
2018-10-25 22:47:14 -04:00
|
|
|
end
|
2018-10-25 03:02:28 -04:00
|
|
|
|
2019-04-07 14:35:16 -04:00
|
|
|
it_behaves_like 'any assignee filter' do
|
|
|
|
let(:expected_issuables) { [issue1, issue2, issue3] }
|
2018-10-25 22:47:14 -04:00
|
|
|
end
|
2018-10-25 03:02:28 -04:00
|
|
|
end
|
|
|
|
|
2018-01-24 01:06:24 -05:00
|
|
|
context 'filtering by group_id' do
|
|
|
|
let(:params) { { group_id: group.id } }
|
|
|
|
|
|
|
|
context 'when include_subgroup param not set' do
|
|
|
|
it 'returns all group issues' do
|
|
|
|
expect(issues).to contain_exactly(issue1)
|
|
|
|
end
|
|
|
|
end
|
|
|
|
|
|
|
|
context 'when include_subgroup param is true', :nested_groups do
|
|
|
|
before do
|
|
|
|
params[:include_subgroups] = true
|
|
|
|
end
|
|
|
|
|
|
|
|
it 'returns all group and subgroup issues' do
|
|
|
|
expect(issues).to contain_exactly(issue1, issue4)
|
|
|
|
end
|
|
|
|
end
|
|
|
|
end
|
|
|
|
|
2016-05-12 07:20:09 -04:00
|
|
|
context 'filtering by author ID' do
|
|
|
|
let(:params) { { author_id: user2.id } }
|
|
|
|
|
|
|
|
it 'returns issues created by that user' do
|
|
|
|
expect(issues).to contain_exactly(issue3)
|
|
|
|
end
|
2014-12-05 10:25:22 -05:00
|
|
|
end
|
|
|
|
|
2016-05-12 07:20:09 -04:00
|
|
|
context 'filtering by milestone' do
|
|
|
|
let(:params) { { milestone_title: milestone.title } }
|
|
|
|
|
|
|
|
it 'returns issues assigned to that milestone' do
|
|
|
|
expect(issues).to contain_exactly(issue1)
|
|
|
|
end
|
2015-10-06 12:57:13 -04:00
|
|
|
end
|
|
|
|
|
2017-07-07 11:08:49 -04:00
|
|
|
context 'filtering by group milestone' do
|
|
|
|
let!(:group) { create(:group, :public) }
|
|
|
|
let(:group_milestone) { create(:milestone, group: group) }
|
|
|
|
let!(:group_member) { create(:group_member, group: group, user: user) }
|
|
|
|
let(:params) { { milestone_title: group_milestone.title } }
|
|
|
|
|
|
|
|
before do
|
|
|
|
project2.update(namespace: group)
|
|
|
|
issue2.update(milestone: group_milestone)
|
|
|
|
issue3.update(milestone: group_milestone)
|
|
|
|
end
|
|
|
|
|
|
|
|
it 'returns issues assigned to that group milestone' do
|
|
|
|
expect(issues).to contain_exactly(issue2, issue3)
|
|
|
|
end
|
|
|
|
end
|
|
|
|
|
2016-05-12 07:20:09 -04:00
|
|
|
context 'filtering by no milestone' do
|
2018-10-26 08:37:52 -04:00
|
|
|
let(:params) { { milestone_title: 'None' } }
|
2016-05-12 07:20:09 -04:00
|
|
|
|
|
|
|
it 'returns issues with no milestone' do
|
2018-01-24 01:06:24 -05:00
|
|
|
expect(issues).to contain_exactly(issue2, issue3, issue4)
|
2016-05-12 07:20:09 -04:00
|
|
|
end
|
2018-10-26 08:37:52 -04:00
|
|
|
|
|
|
|
it 'returns issues with no milestone (deprecated)' do
|
|
|
|
params[:milestone_title] = Milestone::None.title
|
|
|
|
|
|
|
|
expect(issues).to contain_exactly(issue2, issue3, issue4)
|
|
|
|
end
|
2015-10-06 12:57:13 -04:00
|
|
|
end
|
|
|
|
|
2018-10-03 07:00:03 -04:00
|
|
|
context 'filtering by any milestone' do
|
2018-10-26 08:37:52 -04:00
|
|
|
let(:params) { { milestone_title: 'Any' } }
|
2018-10-03 07:00:03 -04:00
|
|
|
|
|
|
|
it 'returns issues with any assigned milestone' do
|
|
|
|
expect(issues).to contain_exactly(issue1)
|
|
|
|
end
|
2018-10-26 08:37:52 -04:00
|
|
|
|
|
|
|
it 'returns issues with any assigned milestone (deprecated)' do
|
|
|
|
params[:milestone_title] = Milestone::Any.title
|
|
|
|
|
|
|
|
expect(issues).to contain_exactly(issue1)
|
|
|
|
end
|
2018-10-03 07:00:03 -04:00
|
|
|
end
|
|
|
|
|
2016-05-11 12:38:34 -04:00
|
|
|
context 'filtering by upcoming milestone' do
|
|
|
|
let(:params) { { milestone_title: Milestone::Upcoming.name } }
|
|
|
|
|
2018-11-15 01:56:51 -05:00
|
|
|
let!(:group) { create(:group, :public) }
|
|
|
|
let!(:group_member) { create(:group_member, group: group, user: user) }
|
|
|
|
|
2017-08-02 15:55:11 -04:00
|
|
|
let(:project_no_upcoming_milestones) { create(:project, :public) }
|
|
|
|
let(:project_next_1_1) { create(:project, :public) }
|
|
|
|
let(:project_next_8_8) { create(:project, :public) }
|
2018-11-15 01:56:51 -05:00
|
|
|
let(:project_in_group) { create(:project, :public, namespace: group) }
|
2016-05-11 12:38:34 -04:00
|
|
|
|
|
|
|
let(:yesterday) { Date.today - 1.day }
|
|
|
|
let(:tomorrow) { Date.today + 1.day }
|
|
|
|
let(:two_days_from_now) { Date.today + 2.days }
|
|
|
|
let(:ten_days_from_now) { Date.today + 10.days }
|
|
|
|
|
|
|
|
let(:milestones) do
|
|
|
|
[
|
|
|
|
create(:milestone, :closed, project: project_no_upcoming_milestones),
|
|
|
|
create(:milestone, project: project_next_1_1, title: '1.1', due_date: two_days_from_now),
|
2018-11-15 01:56:51 -05:00
|
|
|
create(:milestone, project: project_next_1_1, title: '8.9', due_date: ten_days_from_now),
|
|
|
|
create(:milestone, project: project_next_8_8, title: '1.2', due_date: yesterday),
|
|
|
|
create(:milestone, project: project_next_8_8, title: '8.8', due_date: tomorrow),
|
|
|
|
create(:milestone, group: group, title: '9.9', due_date: tomorrow)
|
2016-05-11 12:38:34 -04:00
|
|
|
]
|
|
|
|
end
|
|
|
|
|
|
|
|
before do
|
|
|
|
milestones.each do |milestone|
|
2018-11-15 01:56:51 -05:00
|
|
|
create(:issue, project: milestone.project || project_in_group, milestone: milestone, author: user, assignees: [user])
|
2016-05-11 12:38:34 -04:00
|
|
|
end
|
|
|
|
end
|
|
|
|
|
2018-11-15 01:56:51 -05:00
|
|
|
it 'returns issues in the upcoming milestone for each project or group' do
|
|
|
|
expect(issues.map { |issue| issue.milestone.title }).to contain_exactly('1.1', '8.8', '9.9')
|
|
|
|
expect(issues.map { |issue| issue.milestone.due_date }).to contain_exactly(tomorrow, two_days_from_now, tomorrow)
|
2016-05-11 12:38:34 -04:00
|
|
|
end
|
|
|
|
end
|
|
|
|
|
2017-03-10 14:01:05 -05:00
|
|
|
context 'filtering by started milestone' do
|
|
|
|
let(:params) { { milestone_title: Milestone::Started.name } }
|
|
|
|
|
2017-08-02 15:55:11 -04:00
|
|
|
let(:project_no_started_milestones) { create(:project, :public) }
|
|
|
|
let(:project_started_1_and_2) { create(:project, :public) }
|
|
|
|
let(:project_started_8) { create(:project, :public) }
|
2017-03-10 14:01:05 -05:00
|
|
|
|
|
|
|
let(:yesterday) { Date.today - 1.day }
|
|
|
|
let(:tomorrow) { Date.today + 1.day }
|
|
|
|
let(:two_days_ago) { Date.today - 2.days }
|
2019-03-11 10:15:05 -04:00
|
|
|
let(:three_days_ago) { Date.today - 3.days }
|
2017-03-10 14:01:05 -05:00
|
|
|
|
|
|
|
let(:milestones) do
|
|
|
|
[
|
|
|
|
create(:milestone, project: project_no_started_milestones, start_date: tomorrow),
|
|
|
|
create(:milestone, project: project_started_1_and_2, title: '1.0', start_date: two_days_ago),
|
|
|
|
create(:milestone, project: project_started_1_and_2, title: '2.0', start_date: yesterday),
|
|
|
|
create(:milestone, project: project_started_1_and_2, title: '3.0', start_date: tomorrow),
|
2019-03-11 10:15:05 -04:00
|
|
|
create(:milestone, :closed, project: project_started_1_and_2, title: '4.0', start_date: three_days_ago),
|
|
|
|
create(:milestone, :closed, project: project_started_8, title: '6.0', start_date: three_days_ago),
|
2017-03-10 14:01:05 -05:00
|
|
|
create(:milestone, project: project_started_8, title: '7.0'),
|
|
|
|
create(:milestone, project: project_started_8, title: '8.0', start_date: yesterday),
|
|
|
|
create(:milestone, project: project_started_8, title: '9.0', start_date: tomorrow)
|
|
|
|
]
|
|
|
|
end
|
|
|
|
|
|
|
|
before do
|
|
|
|
milestones.each do |milestone|
|
2017-05-04 08:11:15 -04:00
|
|
|
create(:issue, project: milestone.project, milestone: milestone, author: user, assignees: [user])
|
2017-03-10 14:01:05 -05:00
|
|
|
end
|
|
|
|
end
|
|
|
|
|
|
|
|
it 'returns issues in the started milestones for each project' do
|
|
|
|
expect(issues.map { |issue| issue.milestone.title }).to contain_exactly('1.0', '2.0', '8.0')
|
|
|
|
expect(issues.map { |issue| issue.milestone.start_date }).to contain_exactly(two_days_ago, yesterday, yesterday)
|
|
|
|
end
|
|
|
|
end
|
|
|
|
|
2016-05-12 07:20:09 -04:00
|
|
|
context 'filtering by label' do
|
|
|
|
let(:params) { { label_name: label.title } }
|
2016-04-13 06:05:10 -04:00
|
|
|
|
2016-05-12 07:20:09 -04:00
|
|
|
it 'returns issues with that label' do
|
|
|
|
expect(issues).to contain_exactly(issue2)
|
|
|
|
end
|
|
|
|
end
|
2016-04-13 06:05:10 -04:00
|
|
|
|
2016-05-12 07:20:09 -04:00
|
|
|
context 'filtering by multiple labels' do
|
|
|
|
let(:params) { { label_name: [label.title, label2.title].join(',') } }
|
|
|
|
let(:label2) { create(:label, project: project2) }
|
2016-04-13 06:05:10 -04:00
|
|
|
|
2017-06-14 14:18:56 -04:00
|
|
|
before do
|
|
|
|
create(:label_link, label: label2, target: issue2)
|
|
|
|
end
|
2016-04-13 06:05:10 -04:00
|
|
|
|
2018-10-29 05:50:18 -04:00
|
|
|
it 'returns the unique issues with all those labels' do
|
|
|
|
expect(issues).to contain_exactly(issue2)
|
|
|
|
end
|
|
|
|
end
|
|
|
|
|
|
|
|
context 'filtering by a label that includes any or none in the title' do
|
|
|
|
let(:params) { { label_name: [label.title, label2.title].join(',') } }
|
|
|
|
let(:label) { create(:label, title: 'any foo', project: project2) }
|
|
|
|
let(:label2) { create(:label, title: 'bar none', project: project2) }
|
|
|
|
|
|
|
|
it 'returns the unique issues with all those labels' do
|
|
|
|
create(:label_link, label: label2, target: issue2)
|
|
|
|
|
2016-05-12 07:20:09 -04:00
|
|
|
expect(issues).to contain_exactly(issue2)
|
|
|
|
end
|
2016-04-13 06:05:10 -04:00
|
|
|
end
|
|
|
|
|
2016-05-12 07:20:09 -04:00
|
|
|
context 'filtering by no label' do
|
2018-10-29 05:50:18 -04:00
|
|
|
let(:params) { { label_name: described_class::FILTER_NONE } }
|
2016-05-12 07:20:09 -04:00
|
|
|
|
|
|
|
it 'returns issues with no labels' do
|
2018-01-24 01:06:24 -05:00
|
|
|
expect(issues).to contain_exactly(issue1, issue3, issue4)
|
2016-05-12 07:20:09 -04:00
|
|
|
end
|
2015-10-06 12:57:13 -04:00
|
|
|
end
|
|
|
|
|
2018-10-29 05:50:18 -04:00
|
|
|
context 'filtering by legacy No+Label' do
|
|
|
|
let(:params) { { label_name: Label::NONE } }
|
|
|
|
|
|
|
|
it 'returns issues with no labels' do
|
|
|
|
expect(issues).to contain_exactly(issue1, issue3, issue4)
|
|
|
|
end
|
|
|
|
end
|
|
|
|
|
|
|
|
context 'filtering by any label' do
|
|
|
|
let(:params) { { label_name: described_class::FILTER_ANY } }
|
|
|
|
|
|
|
|
it 'returns issues that have one or more label' do
|
|
|
|
2.times do
|
|
|
|
create(:label_link, label: create(:label, project: project2), target: issue3)
|
|
|
|
end
|
|
|
|
|
|
|
|
expect(issues).to contain_exactly(issue2, issue3)
|
|
|
|
end
|
|
|
|
end
|
|
|
|
|
2016-06-27 16:22:19 -04:00
|
|
|
context 'filtering by issue term' do
|
|
|
|
let(:params) { { search: 'git' } }
|
|
|
|
|
|
|
|
it 'returns issues with title and description match for search term' do
|
|
|
|
expect(issues).to contain_exactly(issue1, issue2)
|
|
|
|
end
|
|
|
|
end
|
|
|
|
|
2019-01-13 11:24:31 -05:00
|
|
|
context 'filtering by issue term in title' do
|
|
|
|
let(:params) { { search: 'git', in: 'title' } }
|
|
|
|
|
|
|
|
it 'returns issues with title match for search term' do
|
|
|
|
expect(issues).to contain_exactly(issue1)
|
|
|
|
end
|
|
|
|
end
|
|
|
|
|
2017-02-17 13:28:32 -05:00
|
|
|
context 'filtering by issues iids' do
|
|
|
|
let(:params) { { iids: issue3.iid } }
|
2016-06-27 16:22:19 -04:00
|
|
|
|
2017-02-17 13:28:32 -05:00
|
|
|
it 'returns issues with iids match' do
|
2016-06-27 16:22:19 -04:00
|
|
|
expect(issues).to contain_exactly(issue3)
|
|
|
|
end
|
|
|
|
end
|
|
|
|
|
2016-11-30 03:11:43 -05:00
|
|
|
context 'filtering by state' do
|
|
|
|
context 'with opened' do
|
|
|
|
let(:params) { { state: 'opened' } }
|
|
|
|
|
|
|
|
it 'returns only opened issues' do
|
2018-01-24 01:06:24 -05:00
|
|
|
expect(issues).to contain_exactly(issue1, issue2, issue3, issue4)
|
2016-11-30 03:11:43 -05:00
|
|
|
end
|
|
|
|
end
|
|
|
|
|
|
|
|
context 'with closed' do
|
|
|
|
let(:params) { { state: 'closed' } }
|
|
|
|
|
|
|
|
it 'returns only closed issues' do
|
|
|
|
expect(issues).to contain_exactly(closed_issue)
|
|
|
|
end
|
|
|
|
end
|
|
|
|
|
|
|
|
context 'with all' do
|
|
|
|
let(:params) { { state: 'all' } }
|
|
|
|
|
|
|
|
it 'returns all issues' do
|
2018-01-24 01:06:24 -05:00
|
|
|
expect(issues).to contain_exactly(issue1, issue2, issue3, closed_issue, issue4)
|
2016-11-30 03:11:43 -05:00
|
|
|
end
|
|
|
|
end
|
|
|
|
|
|
|
|
context 'with invalid state' do
|
|
|
|
let(:params) { { state: 'invalid_state' } }
|
|
|
|
|
|
|
|
it 'returns all issues' do
|
2018-01-24 01:06:24 -05:00
|
|
|
expect(issues).to contain_exactly(issue1, issue2, issue3, closed_issue, issue4)
|
2016-11-30 03:11:43 -05:00
|
|
|
end
|
|
|
|
end
|
|
|
|
end
|
|
|
|
|
2017-06-13 17:02:35 -04:00
|
|
|
context 'filtering by created_at' do
|
|
|
|
context 'through created_after' do
|
|
|
|
let(:params) { { created_after: issue3.created_at } }
|
|
|
|
|
|
|
|
it 'returns issues created on or after the given date' do
|
|
|
|
expect(issues).to contain_exactly(issue3)
|
|
|
|
end
|
|
|
|
end
|
|
|
|
|
|
|
|
context 'through created_before' do
|
2018-02-28 06:16:29 -05:00
|
|
|
let(:params) { { created_before: issue1.created_at } }
|
2017-06-13 17:02:35 -04:00
|
|
|
|
|
|
|
it 'returns issues created on or before the given date' do
|
|
|
|
expect(issues).to contain_exactly(issue1)
|
|
|
|
end
|
|
|
|
end
|
2018-02-28 06:16:29 -05:00
|
|
|
|
|
|
|
context 'through created_after and created_before' do
|
|
|
|
let(:params) { { created_after: issue2.created_at, created_before: issue3.created_at } }
|
|
|
|
|
|
|
|
it 'returns issues created between the given dates' do
|
|
|
|
expect(issues).to contain_exactly(issue2, issue3)
|
|
|
|
end
|
|
|
|
end
|
|
|
|
end
|
|
|
|
|
|
|
|
context 'filtering by updated_at' do
|
|
|
|
context 'through updated_after' do
|
|
|
|
let(:params) { { updated_after: issue3.updated_at } }
|
|
|
|
|
|
|
|
it 'returns issues updated on or after the given date' do
|
|
|
|
expect(issues).to contain_exactly(issue3)
|
|
|
|
end
|
|
|
|
end
|
|
|
|
|
|
|
|
context 'through updated_before' do
|
|
|
|
let(:params) { { updated_before: issue1.updated_at } }
|
|
|
|
|
|
|
|
it 'returns issues updated on or before the given date' do
|
|
|
|
expect(issues).to contain_exactly(issue1)
|
|
|
|
end
|
|
|
|
end
|
|
|
|
|
|
|
|
context 'through updated_after and updated_before' do
|
|
|
|
let(:params) { { updated_after: issue2.updated_at, updated_before: issue3.updated_at } }
|
|
|
|
|
|
|
|
it 'returns issues updated between the given dates' do
|
|
|
|
expect(issues).to contain_exactly(issue2, issue3)
|
|
|
|
end
|
|
|
|
end
|
2017-06-13 17:02:35 -04:00
|
|
|
end
|
|
|
|
|
2019-01-17 12:49:07 -05:00
|
|
|
context 'filtering by closed_at' do
|
|
|
|
let!(:closed_issue1) { create(:issue, project: project1, state: :closed, closed_at: 1.week.ago) }
|
|
|
|
let!(:closed_issue2) { create(:issue, project: project2, state: :closed, closed_at: 1.week.from_now) }
|
|
|
|
let!(:closed_issue3) { create(:issue, project: project2, state: :closed, closed_at: 2.weeks.from_now) }
|
|
|
|
|
|
|
|
context 'through closed_after' do
|
|
|
|
let(:params) { { state: :closed, closed_after: closed_issue3.closed_at } }
|
|
|
|
|
|
|
|
it 'returns issues closed on or after the given date' do
|
|
|
|
expect(issues).to contain_exactly(closed_issue3)
|
|
|
|
end
|
|
|
|
end
|
|
|
|
|
|
|
|
context 'through closed_before' do
|
|
|
|
let(:params) { { state: :closed, closed_before: closed_issue1.closed_at } }
|
|
|
|
|
|
|
|
it 'returns issues closed on or before the given date' do
|
|
|
|
expect(issues).to contain_exactly(closed_issue1)
|
|
|
|
end
|
|
|
|
end
|
|
|
|
|
|
|
|
context 'through closed_after and closed_before' do
|
|
|
|
let(:params) { { state: :closed, closed_after: closed_issue2.closed_at, closed_before: closed_issue3.closed_at } }
|
|
|
|
|
|
|
|
it 'returns issues closed between the given dates' do
|
|
|
|
expect(issues).to contain_exactly(closed_issue2, closed_issue3)
|
|
|
|
end
|
|
|
|
end
|
|
|
|
end
|
|
|
|
|
2017-08-30 03:48:55 -04:00
|
|
|
context 'filtering by reaction name' do
|
2018-10-26 23:18:31 -04:00
|
|
|
context 'user searches by no reaction' do
|
|
|
|
let(:params) { { my_reaction_emoji: 'None' } }
|
|
|
|
|
|
|
|
it 'returns issues that the user did not react to' do
|
|
|
|
expect(issues).to contain_exactly(issue2, issue4)
|
|
|
|
end
|
|
|
|
end
|
|
|
|
|
|
|
|
context 'user searches by any reaction' do
|
|
|
|
let(:params) { { my_reaction_emoji: 'Any' } }
|
|
|
|
|
|
|
|
it 'returns issues that the user reacted to' do
|
|
|
|
expect(issues).to contain_exactly(issue1, issue3)
|
|
|
|
end
|
|
|
|
end
|
|
|
|
|
2017-08-30 03:48:55 -04:00
|
|
|
context 'user searches by "thumbsup" reaction' do
|
|
|
|
let(:params) { { my_reaction_emoji: 'thumbsup' } }
|
|
|
|
|
|
|
|
it 'returns issues that the user thumbsup to' do
|
|
|
|
expect(issues).to contain_exactly(issue1)
|
|
|
|
end
|
|
|
|
end
|
|
|
|
|
|
|
|
context 'user2 searches by "thumbsup" reaction' do
|
|
|
|
let(:search_user) { user2 }
|
|
|
|
|
|
|
|
let(:params) { { my_reaction_emoji: 'thumbsup' } }
|
|
|
|
|
|
|
|
it 'returns issues that the user2 thumbsup to' do
|
|
|
|
expect(issues).to contain_exactly(issue2)
|
|
|
|
end
|
|
|
|
end
|
|
|
|
|
|
|
|
context 'user searches by "thumbsdown" reaction' do
|
|
|
|
let(:params) { { my_reaction_emoji: 'thumbsdown' } }
|
|
|
|
|
|
|
|
it 'returns issues that the user thumbsdown to' do
|
|
|
|
expect(issues).to contain_exactly(issue3)
|
|
|
|
end
|
|
|
|
end
|
|
|
|
end
|
|
|
|
|
2019-02-25 06:00:24 -05:00
|
|
|
context 'filtering by confidential' do
|
|
|
|
set(:confidential_issue) { create(:issue, project: project1, confidential: true) }
|
|
|
|
|
|
|
|
context 'no filtering' do
|
|
|
|
it 'returns all issues' do
|
|
|
|
expect(issues).to contain_exactly(issue1, issue2, issue3, issue4, confidential_issue)
|
|
|
|
end
|
|
|
|
end
|
|
|
|
|
|
|
|
context 'user filters confidential issues' do
|
|
|
|
let(:params) { { confidential: true } }
|
|
|
|
|
|
|
|
it 'returns only confdential issues' do
|
|
|
|
expect(issues).to contain_exactly(confidential_issue)
|
|
|
|
end
|
|
|
|
end
|
|
|
|
|
|
|
|
context 'user filters only public issues' do
|
|
|
|
let(:params) { { confidential: false } }
|
|
|
|
|
|
|
|
it 'returns only confdential issues' do
|
|
|
|
expect(issues).to contain_exactly(issue1, issue2, issue3, issue4)
|
|
|
|
end
|
|
|
|
end
|
|
|
|
end
|
|
|
|
|
2016-05-12 07:20:09 -04:00
|
|
|
context 'when the user is unauthorized' do
|
|
|
|
let(:search_user) { nil }
|
|
|
|
|
|
|
|
it 'returns no results' do
|
|
|
|
expect(issues).to be_empty
|
|
|
|
end
|
2014-12-05 10:25:22 -05:00
|
|
|
end
|
|
|
|
|
2016-05-12 07:20:09 -04:00
|
|
|
context 'when the user can see some, but not all, issues' do
|
|
|
|
let(:search_user) { user2 }
|
|
|
|
|
|
|
|
it 'returns only issues they can see' do
|
|
|
|
expect(issues).to contain_exactly(issue2, issue3)
|
|
|
|
end
|
2014-12-05 10:25:22 -05:00
|
|
|
end
|
2016-12-12 03:43:56 -05:00
|
|
|
|
|
|
|
it 'finds issues user can access due to group' do
|
|
|
|
group = create(:group)
|
2017-08-02 15:55:11 -04:00
|
|
|
project = create(:project, group: group)
|
2016-12-12 03:43:56 -05:00
|
|
|
issue = create(:issue, project: project)
|
|
|
|
group.add_user(user, :owner)
|
|
|
|
|
|
|
|
expect(issues).to include(issue)
|
|
|
|
end
|
2014-02-10 08:23:19 -05:00
|
|
|
end
|
|
|
|
|
2014-12-05 10:25:22 -05:00
|
|
|
context 'personal scope' do
|
2018-05-13 22:07:53 -04:00
|
|
|
let(:scope) { 'assigned_to_me' }
|
2016-05-12 07:20:09 -04:00
|
|
|
|
|
|
|
it 'returns issue assigned to the user' do
|
|
|
|
expect(issues).to contain_exactly(issue1, issue2)
|
2014-12-05 10:25:22 -05:00
|
|
|
end
|
|
|
|
|
2016-05-12 07:20:09 -04:00
|
|
|
context 'filtering by project' do
|
|
|
|
let(:params) { { project_id: project1.id } }
|
|
|
|
|
|
|
|
it 'returns issues assigned to the user in that project' do
|
|
|
|
expect(issues).to contain_exactly(issue1)
|
|
|
|
end
|
2014-12-05 10:25:22 -05:00
|
|
|
end
|
2014-02-10 08:23:19 -05:00
|
|
|
end
|
2016-12-12 03:43:56 -05:00
|
|
|
|
|
|
|
context 'when project restricts issues' do
|
|
|
|
let(:scope) { nil }
|
|
|
|
|
|
|
|
it "doesn't return team-only issues to non team members" do
|
2017-08-02 15:55:11 -04:00
|
|
|
project = create(:project, :public, :issues_private)
|
2016-12-12 03:43:56 -05:00
|
|
|
issue = create(:issue, project: project)
|
|
|
|
|
|
|
|
expect(issues).not_to include(issue)
|
|
|
|
end
|
|
|
|
|
|
|
|
it "doesn't return issues if feature disabled" do
|
2018-01-24 01:06:24 -05:00
|
|
|
[project1, project2, project3].each do |project|
|
2016-12-12 03:43:56 -05:00
|
|
|
project.project_feature.update!(issues_access_level: ProjectFeature::DISABLED)
|
|
|
|
end
|
|
|
|
|
|
|
|
expect(issues.count).to eq 0
|
|
|
|
end
|
|
|
|
end
|
2019-04-09 11:38:58 -04:00
|
|
|
|
|
|
|
context 'external authorization' do
|
|
|
|
it_behaves_like 'a finder with external authorization service' do
|
|
|
|
let!(:subject) { create(:issue, project: project) }
|
|
|
|
let(:project_params) { { project_id: project.id } }
|
|
|
|
end
|
|
|
|
end
|
2016-12-12 03:43:56 -05:00
|
|
|
end
|
|
|
|
|
2017-08-24 12:17:04 -04:00
|
|
|
describe '#row_count', :request_store do
|
|
|
|
it 'returns the number of rows for the default state' do
|
|
|
|
finder = described_class.new(user)
|
|
|
|
|
2019-02-25 06:00:24 -05:00
|
|
|
expect(finder.row_count).to eq(5)
|
2017-08-24 12:17:04 -04:00
|
|
|
end
|
|
|
|
|
|
|
|
it 'returns the number of rows for a given state' do
|
|
|
|
finder = described_class.new(user, state: 'closed')
|
|
|
|
|
|
|
|
expect(finder.row_count).to be_zero
|
|
|
|
end
|
|
|
|
end
|
|
|
|
|
2017-06-29 07:43:56 -04:00
|
|
|
describe '#with_confidentiality_access_check' do
|
2017-06-20 11:38:14 -04:00
|
|
|
let(:guest) { create(:user) }
|
|
|
|
set(:authorized_user) { create(:user) }
|
2017-08-02 15:55:11 -04:00
|
|
|
set(:project) { create(:project, namespace: authorized_user.namespace) }
|
2017-06-20 11:38:14 -04:00
|
|
|
set(:public_issue) { create(:issue, project: project) }
|
|
|
|
set(:confidential_issue) { create(:issue, project: project, confidential: true) }
|
|
|
|
|
|
|
|
context 'when no project filter is given' do
|
|
|
|
let(:params) { {} }
|
|
|
|
|
|
|
|
context 'for an anonymous user' do
|
2017-06-29 07:43:56 -04:00
|
|
|
subject { described_class.new(nil, params).with_confidentiality_access_check }
|
2017-06-20 11:38:14 -04:00
|
|
|
|
|
|
|
it 'returns only public issues' do
|
|
|
|
expect(subject).to include(public_issue)
|
|
|
|
expect(subject).not_to include(confidential_issue)
|
|
|
|
end
|
|
|
|
end
|
|
|
|
|
|
|
|
context 'for a user without project membership' do
|
2017-06-29 07:43:56 -04:00
|
|
|
subject { described_class.new(user, params).with_confidentiality_access_check }
|
2017-06-20 11:38:14 -04:00
|
|
|
|
|
|
|
it 'returns only public issues' do
|
|
|
|
expect(subject).to include(public_issue)
|
|
|
|
expect(subject).not_to include(confidential_issue)
|
|
|
|
end
|
|
|
|
end
|
|
|
|
|
|
|
|
context 'for a guest user' do
|
2017-06-29 07:43:56 -04:00
|
|
|
subject { described_class.new(guest, params).with_confidentiality_access_check }
|
2017-06-20 11:38:14 -04:00
|
|
|
|
|
|
|
before do
|
|
|
|
project.add_guest(guest)
|
|
|
|
end
|
|
|
|
|
|
|
|
it 'returns only public issues' do
|
|
|
|
expect(subject).to include(public_issue)
|
|
|
|
expect(subject).not_to include(confidential_issue)
|
|
|
|
end
|
|
|
|
end
|
|
|
|
|
|
|
|
context 'for a project member with access to view confidential issues' do
|
2017-06-29 07:43:56 -04:00
|
|
|
subject { described_class.new(authorized_user, params).with_confidentiality_access_check }
|
2016-12-12 03:43:56 -05:00
|
|
|
|
2017-06-20 11:38:14 -04:00
|
|
|
it 'returns all issues' do
|
|
|
|
expect(subject).to include(public_issue, confidential_issue)
|
|
|
|
end
|
|
|
|
end
|
2019-03-19 13:25:10 -04:00
|
|
|
|
|
|
|
context 'for an admin' do
|
|
|
|
let(:admin_user) { create(:user, :admin) }
|
|
|
|
|
|
|
|
subject { described_class.new(admin_user, params).with_confidentiality_access_check }
|
|
|
|
|
|
|
|
it 'returns all issues' do
|
|
|
|
expect(subject).to include(public_issue, confidential_issue)
|
|
|
|
end
|
|
|
|
end
|
2016-12-12 03:43:56 -05:00
|
|
|
end
|
|
|
|
|
2017-06-20 11:38:14 -04:00
|
|
|
context 'when searching within a specific project' do
|
|
|
|
let(:params) { { project_id: project.id } }
|
|
|
|
|
|
|
|
context 'for an anonymous user' do
|
2017-06-29 07:43:56 -04:00
|
|
|
subject { described_class.new(nil, params).with_confidentiality_access_check }
|
2017-06-20 11:38:14 -04:00
|
|
|
|
|
|
|
it 'returns only public issues' do
|
|
|
|
expect(subject).to include(public_issue)
|
|
|
|
expect(subject).not_to include(confidential_issue)
|
|
|
|
end
|
|
|
|
|
|
|
|
it 'does not filter by confidentiality' do
|
|
|
|
expect(Issue).not_to receive(:where).with(a_string_matching('confidential'), anything)
|
|
|
|
|
|
|
|
subject
|
|
|
|
end
|
|
|
|
end
|
|
|
|
|
|
|
|
context 'for a user without project membership' do
|
2017-06-29 07:43:56 -04:00
|
|
|
subject { described_class.new(user, params).with_confidentiality_access_check }
|
2017-06-20 11:38:14 -04:00
|
|
|
|
|
|
|
it 'returns only public issues' do
|
|
|
|
expect(subject).to include(public_issue)
|
|
|
|
expect(subject).not_to include(confidential_issue)
|
|
|
|
end
|
|
|
|
|
|
|
|
it 'filters by confidentiality' do
|
|
|
|
expect(Issue).to receive(:where).with(a_string_matching('confidential'), anything)
|
|
|
|
|
|
|
|
subject
|
|
|
|
end
|
|
|
|
end
|
|
|
|
|
|
|
|
context 'for a guest user' do
|
2017-06-29 07:43:56 -04:00
|
|
|
subject { described_class.new(guest, params).with_confidentiality_access_check }
|
2017-06-20 11:38:14 -04:00
|
|
|
|
|
|
|
before do
|
|
|
|
project.add_guest(guest)
|
|
|
|
end
|
|
|
|
|
|
|
|
it 'returns only public issues' do
|
|
|
|
expect(subject).to include(public_issue)
|
|
|
|
expect(subject).not_to include(confidential_issue)
|
|
|
|
end
|
|
|
|
|
|
|
|
it 'filters by confidentiality' do
|
|
|
|
expect(Issue).to receive(:where).with(a_string_matching('confidential'), anything)
|
|
|
|
|
|
|
|
subject
|
|
|
|
end
|
|
|
|
end
|
|
|
|
|
|
|
|
context 'for a project member with access to view confidential issues' do
|
2017-06-29 07:43:56 -04:00
|
|
|
subject { described_class.new(authorized_user, params).with_confidentiality_access_check }
|
2017-06-20 11:38:14 -04:00
|
|
|
|
|
|
|
it 'returns all issues' do
|
|
|
|
expect(subject).to include(public_issue, confidential_issue)
|
|
|
|
end
|
|
|
|
|
|
|
|
it 'does not filter by confidentiality' do
|
|
|
|
expect(Issue).not_to receive(:where).with(a_string_matching('confidential'), anything)
|
|
|
|
|
|
|
|
subject
|
|
|
|
end
|
|
|
|
end
|
2019-03-19 13:25:10 -04:00
|
|
|
|
|
|
|
context 'for an admin' do
|
|
|
|
let(:admin_user) { create(:user, :admin) }
|
|
|
|
|
|
|
|
subject { described_class.new(admin_user, params).with_confidentiality_access_check }
|
|
|
|
|
|
|
|
it 'returns all issues' do
|
|
|
|
expect(subject).to include(public_issue, confidential_issue)
|
|
|
|
end
|
|
|
|
|
|
|
|
it 'does not filter by confidentiality' do
|
|
|
|
expect(Issue).not_to receive(:where).with(a_string_matching('confidential'), anything)
|
|
|
|
|
|
|
|
subject
|
|
|
|
end
|
|
|
|
end
|
2016-12-12 03:43:56 -05:00
|
|
|
end
|
2014-01-15 09:32:07 -05:00
|
|
|
end
|
2018-11-29 07:52:48 -05:00
|
|
|
|
Extend CTE search optimisation to projects
When we use the `search` param on an `IssuableFinder`, we can run into
issues. We have trigram indexes to support these searches. On
GitLab.com, we often see Postgres's optimiser prioritise the (global)
trigram indexes over the index on `project_id`. For group and project
searches, we know that it will be quicker to filter by `project_id`
first, as it returns fewer rows in most cases.
For group issues search, we ran into this issue previously, and went
through the following iterations:
1. Use a CTE on the project IDs as an optimisation fence. This prevents
the planner from disregarding the index on `project_id`.
Unfortunately it breaks some types of sorting, like priority and
popularity, as they sort on a joined table.
2. Use a subquery for listing issues, and a CTE for counts. The subquery
- in the case of group lists - didn't help as much as the CTE, but
was faster than not including it. We can safely use a CTE for counts
as they don't have sorting.
Now, however, we're seeing the same issue in a project context. The
subquery doesn't help at all there (it would only return one row, after
all). In an attempt to keep total code complexity under control, this
commit removes the subquery optimisation and applies the CTE
optimisation only for sorts we know that are safe.
This means that for more complicated sorts (like priority and
popularity), the search will continue to be very slow. If this is a
high-priority issue, we can consider introducing further optimisations,
but this finder is already very complicated and additional complexity
has a cost.
The group CTE optimisation is controlled by the same feature flag as
before, `attempt_group_search_optimizations`, which is enabled by
default. The new project CTE optimisation is controlled by a new feature
flag, `attempt_project_search_optimizations`, which is disabled by
default.
2019-04-03 05:46:13 -04:00
|
|
|
describe '#use_cte_for_search?' do
|
2018-11-29 07:52:48 -05:00
|
|
|
let(:finder) { described_class.new(nil, params) }
|
|
|
|
|
|
|
|
before do
|
|
|
|
allow(Gitlab::Database).to receive(:postgresql?).and_return(true)
|
2019-02-19 15:51:11 -05:00
|
|
|
stub_feature_flags(attempt_group_search_optimizations: true)
|
2018-11-29 07:52:48 -05:00
|
|
|
end
|
|
|
|
|
|
|
|
context 'when there is no search param' do
|
|
|
|
let(:params) { { attempt_group_search_optimizations: true } }
|
|
|
|
|
|
|
|
it 'returns false' do
|
Extend CTE search optimisation to projects
When we use the `search` param on an `IssuableFinder`, we can run into
issues. We have trigram indexes to support these searches. On
GitLab.com, we often see Postgres's optimiser prioritise the (global)
trigram indexes over the index on `project_id`. For group and project
searches, we know that it will be quicker to filter by `project_id`
first, as it returns fewer rows in most cases.
For group issues search, we ran into this issue previously, and went
through the following iterations:
1. Use a CTE on the project IDs as an optimisation fence. This prevents
the planner from disregarding the index on `project_id`.
Unfortunately it breaks some types of sorting, like priority and
popularity, as they sort on a joined table.
2. Use a subquery for listing issues, and a CTE for counts. The subquery
- in the case of group lists - didn't help as much as the CTE, but
was faster than not including it. We can safely use a CTE for counts
as they don't have sorting.
Now, however, we're seeing the same issue in a project context. The
subquery doesn't help at all there (it would only return one row, after
all). In an attempt to keep total code complexity under control, this
commit removes the subquery optimisation and applies the CTE
optimisation only for sorts we know that are safe.
This means that for more complicated sorts (like priority and
popularity), the search will continue to be very slow. If this is a
high-priority issue, we can consider introducing further optimisations,
but this finder is already very complicated and additional complexity
has a cost.
The group CTE optimisation is controlled by the same feature flag as
before, `attempt_group_search_optimizations`, which is enabled by
default. The new project CTE optimisation is controlled by a new feature
flag, `attempt_project_search_optimizations`, which is disabled by
default.
2019-04-03 05:46:13 -04:00
|
|
|
expect(finder.use_cte_for_search?).to be_falsey
|
2018-11-29 07:52:48 -05:00
|
|
|
end
|
|
|
|
end
|
|
|
|
|
|
|
|
context 'when the database is not Postgres' do
|
|
|
|
let(:params) { { search: 'foo', attempt_group_search_optimizations: true } }
|
|
|
|
|
|
|
|
before do
|
|
|
|
allow(Gitlab::Database).to receive(:postgresql?).and_return(false)
|
|
|
|
end
|
|
|
|
|
|
|
|
it 'returns false' do
|
Extend CTE search optimisation to projects
When we use the `search` param on an `IssuableFinder`, we can run into
issues. We have trigram indexes to support these searches. On
GitLab.com, we often see Postgres's optimiser prioritise the (global)
trigram indexes over the index on `project_id`. For group and project
searches, we know that it will be quicker to filter by `project_id`
first, as it returns fewer rows in most cases.
For group issues search, we ran into this issue previously, and went
through the following iterations:
1. Use a CTE on the project IDs as an optimisation fence. This prevents
the planner from disregarding the index on `project_id`.
Unfortunately it breaks some types of sorting, like priority and
popularity, as they sort on a joined table.
2. Use a subquery for listing issues, and a CTE for counts. The subquery
- in the case of group lists - didn't help as much as the CTE, but
was faster than not including it. We can safely use a CTE for counts
as they don't have sorting.
Now, however, we're seeing the same issue in a project context. The
subquery doesn't help at all there (it would only return one row, after
all). In an attempt to keep total code complexity under control, this
commit removes the subquery optimisation and applies the CTE
optimisation only for sorts we know that are safe.
This means that for more complicated sorts (like priority and
popularity), the search will continue to be very slow. If this is a
high-priority issue, we can consider introducing further optimisations,
but this finder is already very complicated and additional complexity
has a cost.
The group CTE optimisation is controlled by the same feature flag as
before, `attempt_group_search_optimizations`, which is enabled by
default. The new project CTE optimisation is controlled by a new feature
flag, `attempt_project_search_optimizations`, which is disabled by
default.
2019-04-03 05:46:13 -04:00
|
|
|
expect(finder.use_cte_for_search?).to be_falsey
|
2018-11-29 07:52:48 -05:00
|
|
|
end
|
|
|
|
end
|
|
|
|
|
Extend CTE search optimisation to projects
When we use the `search` param on an `IssuableFinder`, we can run into
issues. We have trigram indexes to support these searches. On
GitLab.com, we often see Postgres's optimiser prioritise the (global)
trigram indexes over the index on `project_id`. For group and project
searches, we know that it will be quicker to filter by `project_id`
first, as it returns fewer rows in most cases.
For group issues search, we ran into this issue previously, and went
through the following iterations:
1. Use a CTE on the project IDs as an optimisation fence. This prevents
the planner from disregarding the index on `project_id`.
Unfortunately it breaks some types of sorting, like priority and
popularity, as they sort on a joined table.
2. Use a subquery for listing issues, and a CTE for counts. The subquery
- in the case of group lists - didn't help as much as the CTE, but
was faster than not including it. We can safely use a CTE for counts
as they don't have sorting.
Now, however, we're seeing the same issue in a project context. The
subquery doesn't help at all there (it would only return one row, after
all). In an attempt to keep total code complexity under control, this
commit removes the subquery optimisation and applies the CTE
optimisation only for sorts we know that are safe.
This means that for more complicated sorts (like priority and
popularity), the search will continue to be very slow. If this is a
high-priority issue, we can consider introducing further optimisations,
but this finder is already very complicated and additional complexity
has a cost.
The group CTE optimisation is controlled by the same feature flag as
before, `attempt_group_search_optimizations`, which is enabled by
default. The new project CTE optimisation is controlled by a new feature
flag, `attempt_project_search_optimizations`, which is disabled by
default.
2019-04-03 05:46:13 -04:00
|
|
|
context 'when the force_cte param is falsey' do
|
2018-11-29 07:52:48 -05:00
|
|
|
let(:params) { { search: 'foo' } }
|
|
|
|
|
|
|
|
it 'returns false' do
|
Extend CTE search optimisation to projects
When we use the `search` param on an `IssuableFinder`, we can run into
issues. We have trigram indexes to support these searches. On
GitLab.com, we often see Postgres's optimiser prioritise the (global)
trigram indexes over the index on `project_id`. For group and project
searches, we know that it will be quicker to filter by `project_id`
first, as it returns fewer rows in most cases.
For group issues search, we ran into this issue previously, and went
through the following iterations:
1. Use a CTE on the project IDs as an optimisation fence. This prevents
the planner from disregarding the index on `project_id`.
Unfortunately it breaks some types of sorting, like priority and
popularity, as they sort on a joined table.
2. Use a subquery for listing issues, and a CTE for counts. The subquery
- in the case of group lists - didn't help as much as the CTE, but
was faster than not including it. We can safely use a CTE for counts
as they don't have sorting.
Now, however, we're seeing the same issue in a project context. The
subquery doesn't help at all there (it would only return one row, after
all). In an attempt to keep total code complexity under control, this
commit removes the subquery optimisation and applies the CTE
optimisation only for sorts we know that are safe.
This means that for more complicated sorts (like priority and
popularity), the search will continue to be very slow. If this is a
high-priority issue, we can consider introducing further optimisations,
but this finder is already very complicated and additional complexity
has a cost.
The group CTE optimisation is controlled by the same feature flag as
before, `attempt_group_search_optimizations`, which is enabled by
default. The new project CTE optimisation is controlled by a new feature
flag, `attempt_project_search_optimizations`, which is disabled by
default.
2019-04-03 05:46:13 -04:00
|
|
|
expect(finder.use_cte_for_search?).to be_falsey
|
2018-11-29 07:52:48 -05:00
|
|
|
end
|
|
|
|
end
|
|
|
|
|
2019-02-19 15:51:11 -05:00
|
|
|
context 'when the attempt_group_search_optimizations flag is disabled' do
|
2018-11-29 07:52:48 -05:00
|
|
|
let(:params) { { search: 'foo', attempt_group_search_optimizations: true } }
|
|
|
|
|
|
|
|
before do
|
2019-02-19 15:51:11 -05:00
|
|
|
stub_feature_flags(attempt_group_search_optimizations: false)
|
2018-11-29 07:52:48 -05:00
|
|
|
end
|
|
|
|
|
|
|
|
it 'returns false' do
|
Extend CTE search optimisation to projects
When we use the `search` param on an `IssuableFinder`, we can run into
issues. We have trigram indexes to support these searches. On
GitLab.com, we often see Postgres's optimiser prioritise the (global)
trigram indexes over the index on `project_id`. For group and project
searches, we know that it will be quicker to filter by `project_id`
first, as it returns fewer rows in most cases.
For group issues search, we ran into this issue previously, and went
through the following iterations:
1. Use a CTE on the project IDs as an optimisation fence. This prevents
the planner from disregarding the index on `project_id`.
Unfortunately it breaks some types of sorting, like priority and
popularity, as they sort on a joined table.
2. Use a subquery for listing issues, and a CTE for counts. The subquery
- in the case of group lists - didn't help as much as the CTE, but
was faster than not including it. We can safely use a CTE for counts
as they don't have sorting.
Now, however, we're seeing the same issue in a project context. The
subquery doesn't help at all there (it would only return one row, after
all). In an attempt to keep total code complexity under control, this
commit removes the subquery optimisation and applies the CTE
optimisation only for sorts we know that are safe.
This means that for more complicated sorts (like priority and
popularity), the search will continue to be very slow. If this is a
high-priority issue, we can consider introducing further optimisations,
but this finder is already very complicated and additional complexity
has a cost.
The group CTE optimisation is controlled by the same feature flag as
before, `attempt_group_search_optimizations`, which is enabled by
default. The new project CTE optimisation is controlled by a new feature
flag, `attempt_project_search_optimizations`, which is disabled by
default.
2019-04-03 05:46:13 -04:00
|
|
|
expect(finder.use_cte_for_search?).to be_falsey
|
2018-11-29 07:52:48 -05:00
|
|
|
end
|
|
|
|
end
|
|
|
|
|
Extend CTE search optimisation to projects
When we use the `search` param on an `IssuableFinder`, we can run into
issues. We have trigram indexes to support these searches. On
GitLab.com, we often see Postgres's optimiser prioritise the (global)
trigram indexes over the index on `project_id`. For group and project
searches, we know that it will be quicker to filter by `project_id`
first, as it returns fewer rows in most cases.
For group issues search, we ran into this issue previously, and went
through the following iterations:
1. Use a CTE on the project IDs as an optimisation fence. This prevents
the planner from disregarding the index on `project_id`.
Unfortunately it breaks some types of sorting, like priority and
popularity, as they sort on a joined table.
2. Use a subquery for listing issues, and a CTE for counts. The subquery
- in the case of group lists - didn't help as much as the CTE, but
was faster than not including it. We can safely use a CTE for counts
as they don't have sorting.
Now, however, we're seeing the same issue in a project context. The
subquery doesn't help at all there (it would only return one row, after
all). In an attempt to keep total code complexity under control, this
commit removes the subquery optimisation and applies the CTE
optimisation only for sorts we know that are safe.
This means that for more complicated sorts (like priority and
popularity), the search will continue to be very slow. If this is a
high-priority issue, we can consider introducing further optimisations,
but this finder is already very complicated and additional complexity
has a cost.
The group CTE optimisation is controlled by the same feature flag as
before, `attempt_group_search_optimizations`, which is enabled by
default. The new project CTE optimisation is controlled by a new feature
flag, `attempt_project_search_optimizations`, which is disabled by
default.
2019-04-03 05:46:13 -04:00
|
|
|
context 'when attempt_group_search_optimizations is unset and attempt_project_search_optimizations is set' do
|
|
|
|
let(:params) { { search: 'foo', attempt_project_search_optimizations: true } }
|
2018-11-29 07:52:48 -05:00
|
|
|
|
Extend CTE search optimisation to projects
When we use the `search` param on an `IssuableFinder`, we can run into
issues. We have trigram indexes to support these searches. On
GitLab.com, we often see Postgres's optimiser prioritise the (global)
trigram indexes over the index on `project_id`. For group and project
searches, we know that it will be quicker to filter by `project_id`
first, as it returns fewer rows in most cases.
For group issues search, we ran into this issue previously, and went
through the following iterations:
1. Use a CTE on the project IDs as an optimisation fence. This prevents
the planner from disregarding the index on `project_id`.
Unfortunately it breaks some types of sorting, like priority and
popularity, as they sort on a joined table.
2. Use a subquery for listing issues, and a CTE for counts. The subquery
- in the case of group lists - didn't help as much as the CTE, but
was faster than not including it. We can safely use a CTE for counts
as they don't have sorting.
Now, however, we're seeing the same issue in a project context. The
subquery doesn't help at all there (it would only return one row, after
all). In an attempt to keep total code complexity under control, this
commit removes the subquery optimisation and applies the CTE
optimisation only for sorts we know that are safe.
This means that for more complicated sorts (like priority and
popularity), the search will continue to be very slow. If this is a
high-priority issue, we can consider introducing further optimisations,
but this finder is already very complicated and additional complexity
has a cost.
The group CTE optimisation is controlled by the same feature flag as
before, `attempt_group_search_optimizations`, which is enabled by
default. The new project CTE optimisation is controlled by a new feature
flag, `attempt_project_search_optimizations`, which is disabled by
default.
2019-04-03 05:46:13 -04:00
|
|
|
context 'and the corresponding feature flag is disabled' do
|
|
|
|
before do
|
|
|
|
stub_feature_flags(attempt_project_search_optimizations: false)
|
|
|
|
end
|
2018-11-29 07:52:48 -05:00
|
|
|
|
Extend CTE search optimisation to projects
When we use the `search` param on an `IssuableFinder`, we can run into
issues. We have trigram indexes to support these searches. On
GitLab.com, we often see Postgres's optimiser prioritise the (global)
trigram indexes over the index on `project_id`. For group and project
searches, we know that it will be quicker to filter by `project_id`
first, as it returns fewer rows in most cases.
For group issues search, we ran into this issue previously, and went
through the following iterations:
1. Use a CTE on the project IDs as an optimisation fence. This prevents
the planner from disregarding the index on `project_id`.
Unfortunately it breaks some types of sorting, like priority and
popularity, as they sort on a joined table.
2. Use a subquery for listing issues, and a CTE for counts. The subquery
- in the case of group lists - didn't help as much as the CTE, but
was faster than not including it. We can safely use a CTE for counts
as they don't have sorting.
Now, however, we're seeing the same issue in a project context. The
subquery doesn't help at all there (it would only return one row, after
all). In an attempt to keep total code complexity under control, this
commit removes the subquery optimisation and applies the CTE
optimisation only for sorts we know that are safe.
This means that for more complicated sorts (like priority and
popularity), the search will continue to be very slow. If this is a
high-priority issue, we can consider introducing further optimisations,
but this finder is already very complicated and additional complexity
has a cost.
The group CTE optimisation is controlled by the same feature flag as
before, `attempt_group_search_optimizations`, which is enabled by
default. The new project CTE optimisation is controlled by a new feature
flag, `attempt_project_search_optimizations`, which is disabled by
default.
2019-04-03 05:46:13 -04:00
|
|
|
it 'returns false' do
|
|
|
|
expect(finder.use_cte_for_search?).to be_falsey
|
|
|
|
end
|
2018-11-29 07:52:48 -05:00
|
|
|
end
|
|
|
|
|
Extend CTE search optimisation to projects
When we use the `search` param on an `IssuableFinder`, we can run into
issues. We have trigram indexes to support these searches. On
GitLab.com, we often see Postgres's optimiser prioritise the (global)
trigram indexes over the index on `project_id`. For group and project
searches, we know that it will be quicker to filter by `project_id`
first, as it returns fewer rows in most cases.
For group issues search, we ran into this issue previously, and went
through the following iterations:
1. Use a CTE on the project IDs as an optimisation fence. This prevents
the planner from disregarding the index on `project_id`.
Unfortunately it breaks some types of sorting, like priority and
popularity, as they sort on a joined table.
2. Use a subquery for listing issues, and a CTE for counts. The subquery
- in the case of group lists - didn't help as much as the CTE, but
was faster than not including it. We can safely use a CTE for counts
as they don't have sorting.
Now, however, we're seeing the same issue in a project context. The
subquery doesn't help at all there (it would only return one row, after
all). In an attempt to keep total code complexity under control, this
commit removes the subquery optimisation and applies the CTE
optimisation only for sorts we know that are safe.
This means that for more complicated sorts (like priority and
popularity), the search will continue to be very slow. If this is a
high-priority issue, we can consider introducing further optimisations,
but this finder is already very complicated and additional complexity
has a cost.
The group CTE optimisation is controlled by the same feature flag as
before, `attempt_group_search_optimizations`, which is enabled by
default. The new project CTE optimisation is controlled by a new feature
flag, `attempt_project_search_optimizations`, which is disabled by
default.
2019-04-03 05:46:13 -04:00
|
|
|
context 'and the corresponding feature flag is enabled' do
|
|
|
|
before do
|
|
|
|
stub_feature_flags(attempt_project_search_optimizations: true)
|
|
|
|
end
|
2018-11-29 07:52:48 -05:00
|
|
|
|
Extend CTE search optimisation to projects
When we use the `search` param on an `IssuableFinder`, we can run into
issues. We have trigram indexes to support these searches. On
GitLab.com, we often see Postgres's optimiser prioritise the (global)
trigram indexes over the index on `project_id`. For group and project
searches, we know that it will be quicker to filter by `project_id`
first, as it returns fewer rows in most cases.
For group issues search, we ran into this issue previously, and went
through the following iterations:
1. Use a CTE on the project IDs as an optimisation fence. This prevents
the planner from disregarding the index on `project_id`.
Unfortunately it breaks some types of sorting, like priority and
popularity, as they sort on a joined table.
2. Use a subquery for listing issues, and a CTE for counts. The subquery
- in the case of group lists - didn't help as much as the CTE, but
was faster than not including it. We can safely use a CTE for counts
as they don't have sorting.
Now, however, we're seeing the same issue in a project context. The
subquery doesn't help at all there (it would only return one row, after
all). In an attempt to keep total code complexity under control, this
commit removes the subquery optimisation and applies the CTE
optimisation only for sorts we know that are safe.
This means that for more complicated sorts (like priority and
popularity), the search will continue to be very slow. If this is a
high-priority issue, we can consider introducing further optimisations,
but this finder is already very complicated and additional complexity
has a cost.
The group CTE optimisation is controlled by the same feature flag as
before, `attempt_group_search_optimizations`, which is enabled by
default. The new project CTE optimisation is controlled by a new feature
flag, `attempt_project_search_optimizations`, which is disabled by
default.
2019-04-03 05:46:13 -04:00
|
|
|
it 'returns true' do
|
|
|
|
expect(finder.use_cte_for_search?).to be_truthy
|
|
|
|
end
|
2018-11-29 07:52:48 -05:00
|
|
|
end
|
|
|
|
end
|
|
|
|
|
|
|
|
context 'when all conditions are met' do
|
Extend CTE search optimisation to projects
When we use the `search` param on an `IssuableFinder`, we can run into
issues. We have trigram indexes to support these searches. On
GitLab.com, we often see Postgres's optimiser prioritise the (global)
trigram indexes over the index on `project_id`. For group and project
searches, we know that it will be quicker to filter by `project_id`
first, as it returns fewer rows in most cases.
For group issues search, we ran into this issue previously, and went
through the following iterations:
1. Use a CTE on the project IDs as an optimisation fence. This prevents
the planner from disregarding the index on `project_id`.
Unfortunately it breaks some types of sorting, like priority and
popularity, as they sort on a joined table.
2. Use a subquery for listing issues, and a CTE for counts. The subquery
- in the case of group lists - didn't help as much as the CTE, but
was faster than not including it. We can safely use a CTE for counts
as they don't have sorting.
Now, however, we're seeing the same issue in a project context. The
subquery doesn't help at all there (it would only return one row, after
all). In an attempt to keep total code complexity under control, this
commit removes the subquery optimisation and applies the CTE
optimisation only for sorts we know that are safe.
This means that for more complicated sorts (like priority and
popularity), the search will continue to be very slow. If this is a
high-priority issue, we can consider introducing further optimisations,
but this finder is already very complicated and additional complexity
has a cost.
The group CTE optimisation is controlled by the same feature flag as
before, `attempt_group_search_optimizations`, which is enabled by
default. The new project CTE optimisation is controlled by a new feature
flag, `attempt_project_search_optimizations`, which is disabled by
default.
2019-04-03 05:46:13 -04:00
|
|
|
let(:params) { { search: 'foo', attempt_group_search_optimizations: true } }
|
2018-11-29 07:52:48 -05:00
|
|
|
|
|
|
|
it 'returns true' do
|
Extend CTE search optimisation to projects
When we use the `search` param on an `IssuableFinder`, we can run into
issues. We have trigram indexes to support these searches. On
GitLab.com, we often see Postgres's optimiser prioritise the (global)
trigram indexes over the index on `project_id`. For group and project
searches, we know that it will be quicker to filter by `project_id`
first, as it returns fewer rows in most cases.
For group issues search, we ran into this issue previously, and went
through the following iterations:
1. Use a CTE on the project IDs as an optimisation fence. This prevents
the planner from disregarding the index on `project_id`.
Unfortunately it breaks some types of sorting, like priority and
popularity, as they sort on a joined table.
2. Use a subquery for listing issues, and a CTE for counts. The subquery
- in the case of group lists - didn't help as much as the CTE, but
was faster than not including it. We can safely use a CTE for counts
as they don't have sorting.
Now, however, we're seeing the same issue in a project context. The
subquery doesn't help at all there (it would only return one row, after
all). In an attempt to keep total code complexity under control, this
commit removes the subquery optimisation and applies the CTE
optimisation only for sorts we know that are safe.
This means that for more complicated sorts (like priority and
popularity), the search will continue to be very slow. If this is a
high-priority issue, we can consider introducing further optimisations,
but this finder is already very complicated and additional complexity
has a cost.
The group CTE optimisation is controlled by the same feature flag as
before, `attempt_group_search_optimizations`, which is enabled by
default. The new project CTE optimisation is controlled by a new feature
flag, `attempt_project_search_optimizations`, which is disabled by
default.
2019-04-03 05:46:13 -04:00
|
|
|
expect(finder.use_cte_for_search?).to be_truthy
|
2018-11-29 07:52:48 -05:00
|
|
|
end
|
|
|
|
end
|
|
|
|
end
|
2014-01-15 09:32:07 -05:00
|
|
|
end
|