- 18 Jan, 2016 1 commit
-
-
Yorick Peterse authored
When using IssuableFinder with a Group we can greatly reduce the amount of projects operated on (due to not including all public/internal projects) by simply passing it down to the ProjectsFinder class. This reduces the timings of the involved queries from roughly 300 ms to roughly 20 ms. Fixes gitlab-org/gitlab-ce#4071, gitlab-org/gitlab-ce#3707
-
- 07 Jan, 2016 1 commit
-
-
Yorick Peterse authored
When grabbing the projects to filter issues by we don't care about the order they're returned in. By removing the ORDER BY the resulting query can be quite a bit faster.
-
- 04 Jan, 2016 1 commit
-
-
Valery Sizov authored
-
- 03 Dec, 2015 1 commit
-
-
Greg Smethells authored
-
- 20 Nov, 2015 1 commit
-
-
Yorick Peterse authored
These changes were added in GitLab EE commit d39de0ea91b26b8840195e5674b92c353cc16661. The tests were a bit bugged (they used a non existing group, thus not testing a crucial part) which I only noticed when porting CE changes to EE.
-
- 19 Nov, 2015 3 commits
-
-
Yorick Peterse authored
When using IssuableFinder/IssuesFinder to find issues for multiple projects it's more efficient to use a JOIN + a "WHERE project_id IN" condition opposed to running a sub-query. This change means that when finding issues without labels we're now using the following SQL: SELECT issues.* FROM issues JOIN projects ON projects.id = issues.project_id LEFT JOIN label_links ON label_links.target_type = 'Issue' AND label_links.target_id = issues.id WHERE ( projects.id IN (...) OR projects.visibility_level IN (20, 10) ) AND issues.state IN ('opened','reopened') AND label_links.id IS NULL ORDER BY issues.id DESC; instead of: SELECT issues.* FROM issues LEFT JOIN label_links ON label_links.target_type = 'Issue' AND label_links.target_id = issues.id WHERE issues.project_id IN ( SELECT id FROM projects WHERE id IN (...) OR visibility_level IN (20,10) ) AND issues.state IN ('opened','reopened') AND label_links.id IS NULL ORDER BY issues.id DESC; The big benefit here is that in the last case PostgreSQL can't properly use all available indexes. In particular it ends up performing a sequence scan on the "label_links" table (processing around 290 000 rows). The new query is roughly 2x as fast as the old query.
-
Yorick Peterse authored
Since this method's returned data doesn't change between calls on the same IssuableFinder instance we can just memoize this similar to the "project" method.
-
Yorick Peterse authored
-
- 18 Nov, 2015 4 commits
-
-
Valery Sizov authored
-
Yorick Peterse authored
When getting the projects of a user we should get the public _and_ internal projects, not just the public ones.
-
Yorick Peterse authored
This class now uses a UNION (when needed) instead of plucking tens of thousands of project IDs into memory. The tests have also been re-written to ensure all different use cases are tested properly (assuming I didn't forget any cases). The finder has also been broken up into 3 different finder classes: * ContributedProjectsFinder: class for getting the projects a user contributed to. * PersonalProjectsFinder: class for getting the personal projects of a user. * ProjectsFinder: class for getting generic projects visible to a given user. Previously a lot of the logic of these finders was handled directly in the users controller.
-
Yorick Peterse authored
In the previous setup the GroupsFinder class had two distinct tasks: 1. Finding the projects user A could see 2. Finding the projects of user A that user B could see Task two was actually handled outside of the GroupsFinder (in the UsersController) by restricting the returned list of groups to those the viewed user was a member of. Moving all this logic into a single finder proved to be far too complex and confusing, hence there are now two finders: * GroupsFinder: for finding groups a user can see * JoinedGroupsFinder: for finding groups that user A is a member of, restricted to either public groups or groups user B can also see.
-
- 16 Nov, 2015 2 commits
-
-
Dmitriy Zaporozhets authored
Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
-
Dmitriy Zaporozhets authored
Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
-
- 05 Nov, 2015 1 commit
-
-
Valery Sizov authored
-
- 19 Oct, 2015 1 commit
-
-
Douwe Maan authored
-
- 16 Oct, 2015 3 commits
-
-
Douwe Maan authored
-
Zeger-Jan van de Weg authored
Credits to Douwe Maan
-
Zeger-Jan van de Weg authored
-
- 07 Oct, 2015 1 commit
-
-
Stan Hu authored
Closes #2619 Closes https://github.com/gitlabhq/gitlabhq/issues/9631
-
- 06 Oct, 2015 2 commits
-
-
Yorick Peterse authored
This changes the query to use a COUNT nested in an INNER JOIN, instead of a COUNT plus a GROUP BY. There are two reasons for this: 1. Using a COUNT in an INNER JOIN can be quite a bit faster. 2. The use of a GROUP BY means that method calls such as "any?" (and everything else that calls "count") operate on a Hash that counts the amount of notes on a per project basis, instead of just counting the total amount of projects. The query has been moved into Project.trending as its logic is simple enough. As a result of this testing the TrendingProjectsFinder class simply involves testing if the right methods are called, removing the need for setting up database records.
-
Yorick Peterse authored
By using >= we can ensure we actually get all comments of the past month, instead of the comments of the past month minus the first day in the range.
-
- 03 Oct, 2015 1 commit
-
-
Guilherme Garnier authored
-
- 18 Sep, 2015 1 commit
-
-
Dmitriy Zaporozhets authored
Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
-
- 26 Aug, 2015 1 commit
-
-
Dmitriy Zaporozhets authored
Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
-
- 07 Jul, 2015 2 commits
-
-
Robert Speicher authored
Also refactors IssuableFinder to avoid redundant title check.
-
Robert Speicher authored
-
- 19 Jun, 2015 1 commit
-
-
Dmitriy Zaporozhets authored
Replaced: * "Accepted" with "Merged" * "Rejected" with "Closed" Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
-
- 27 May, 2015 1 commit
-
-
Douwe Maan authored
-
- 25 May, 2015 1 commit
-
-
Douwe Maan authored
-
- 30 Apr, 2015 1 commit
-
-
Dominik Sander authored
This groups milestones by title for issue views like it has been done for the milestone dashboard/project overview. Before milestones with the same title would show up multiple times in the filter dropdown and one could only filter per project and milestone. Now the milestone filter is based on the title of the milestone, i.e. all issues marked with the same milestone title are shown.
-
- 27 Mar, 2015 2 commits
-
-
Dmitriy Zaporozhets authored
-
Dmitriy Zaporozhets authored
-
- 19 Feb, 2015 1 commit
-
-
Dmitriy Zaporozhets authored
-
- 06 Feb, 2015 2 commits
-
-
Dmitriy Zaporozhets authored
-
Dmitriy Zaporozhets authored
-
- 03 Feb, 2015 2 commits
-
-
Dmitriy Zaporozhets authored
-
Dmitriy Zaporozhets authored
-
- 01 Jan, 2015 1 commit
-
-
Ciro Santilli authored
-
- 05 Dec, 2014 1 commit
-
-
Dmitriy Zaporozhets authored
Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
-