- 29 Mar, 2016 2 commits
-
-
Phil Hughes authored
The frontend will then always use the name as the ID - like previous
-
Phil Hughes authored
Added back upcoming to milestone filter Fixed bug that would cause the currently selected value to disappear on filters Fixed bug that throw an error when filtering by upcoming when there is only a milestone in the past
-
- 21 Mar, 2016 1 commit
-
-
Douwe Maan authored
-
- 20 Mar, 2016 2 commits
-
-
Douwe Maan authored
-
Douwe Maan authored
-
- 13 Mar, 2016 1 commit
-
-
tiagonbotelho authored
-
- 12 Mar, 2016 3 commits
-
-
tiagonbotelho authored
-
tiagonbotelho authored
-
tiagonbotelho authored
-
- 07 Mar, 2016 1 commit
-
-
Rubén Dávila authored
-
- 19 Feb, 2016 2 commits
- 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.
-
- 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
-
- 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
-
- 03 Oct, 2015 1 commit
-
-
Guilherme Garnier authored
-
- 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
-
- 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>
-
- 27 Oct, 2014 1 commit
-
-
Marin Jankovski authored
-
- 02 Sep, 2014 1 commit
-
-
Dmitriy Zaporozhets authored
Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
-
- 30 Jul, 2014 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>
-
- 29 Jul, 2014 1 commit
-
-
Dmitriy Zaporozhets authored
Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
-
- 05 Jun, 2014 1 commit
-
-
Dmitriy Zaporozhets authored
Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
-
- 24 Mar, 2014 1 commit
-
-
Robert Speicher authored
Removes the following from test output: DEPRECATION WARNING: It looks like you are eager loading table(s) (one of: merge_requests, projects) that are referenced in a string SQL snippet. For example: Post.includes(:comments).where("comments.title = 'foo'") Currently, Active Record recognizes the table in the string, and knows to JOIN the comments table to the query, rather than loading comments in a separate query. However, doing this without writing a full-blown SQL parser is inherently flawed. Since we don't want to write an SQL parser, we are removing this functionality. From now on, you must explicitly tell Active Record when you are referencing a table from a string: Post.includes(:comments).where("comments.title = 'foo'").references(:comments) If you don't rely on implicit join references you can disable the feature entirely by setting `config.active_record.disable_implicit_join_references = true`.
-