- 29 7月, 2019 1 次提交
-
-
由 Andreas Brandl 提交于
We dropped MySQL support and a lot of mysql specific code has been removed in https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/29608. This comes in from the other direction and removes any `if postgresql?` branches.
-
- 25 7月, 2019 1 次提交
-
-
由 Heinrich Lee Yu 提交于
These are not required because MySQL is not supported anymore
-
- 07 6月, 2019 1 次提交
-
-
由 Dmitriy Zaporozhets 提交于
Signed-off-by: NDmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
-
- 07 5月, 2019 1 次提交
-
-
由 Francisco Javier López 提交于
Removed the conditions added to Project.with_feature_available_for_user, and moved to the IssuableFinder. Now, we ensure that, in the projects retrieved in the Finder, the user has enough access for the feature.
-
- 09 4月, 2019 2 次提交
-
-
由 Imre Farkas 提交于
Move Contribution Analytics related spec in spec/features/groups/group_page_with_external_authorization_service_spec to EE
-
由 Oswaldo Ferreira 提交于
Backports https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/10161 (code out of ee/ folder).
-
- 05 4月, 2019 2 次提交
-
-
由 Andreas Brandl 提交于
This reverts merge request !26823
-
由 Imre Farkas 提交于
Move Contribution Analytics related spec in spec/features/groups/group_page_with_external_authorization_service_spec to EE
-
- 04 4月, 2019 1 次提交
-
-
由 Sean McGivern 提交于
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.
-
- 22 3月, 2019 1 次提交
-
-
由 Rémy Coutable 提交于
Signed-off-by: NRémy Coutable <remy@rymai.me>
-
- 19 3月, 2019 1 次提交
-
-
由 Sean McGivern 提交于
The Upcoming milestone filter only considers active milestones, but the Started one included closed milestones, too. This was inconsistent.
-
- 01 3月, 2019 1 次提交
-
-
由 Mario de la Ossa 提交于
Since the CTE is faster than a subquery and the only reason we're using a subquery is that the CTE can't handle sorting by certain attributes, let's use the CTE always (when the feature flag is enabled) when counting, since we can ignore ordering if we just want a count of results.
-
- 26 2月, 2019 2 次提交
-
-
由 Kamil Trzciński 提交于
Ability to filter confidential issues Closes #50747 See merge request gitlab-org/gitlab-ce!24960
-
由 Michael Kozono 提交于
This reverts commit d133bf84, reversing changes made to 7981c029.
-
- 22 2月, 2019 1 次提交
-
-
由 Robert Schilling 提交于
Use internally only boolean params.
-
- 21 2月, 2019 2 次提交
-
-
由 Robert Schilling 提交于
-
由 Rémy Coutable 提交于
Signed-off-by: NRémy Coutable <remy@rymai.me>
-
- 14 1月, 2019 1 次提交
-
-
由 Hiroyuki Sato 提交于
-
- 31 12月, 2018 1 次提交
-
-
由 Heinrich Lee Yu 提交于
-
- 30 11月, 2018 1 次提交
-
-
由 Sean McGivern 提交于
We already had a flag to use a CTE, but this broke searching in some cases where we need to sort by a joined table. Disabling the CTE flag makes searches much slower. The new flag, to use a subquery, makes them slightly slower than the CTE, while maintaining correctness. If both it and the CTE flag are enabled, the subquery takes precedence.
-
- 23 11月, 2018 1 次提交
-
-
由 Jacopo 提交于
By using the parameters `?labels=None|Any` the user can filter issues/mrs from the API that has `none/any` label. Affected endpoints are: - /api/issues - /api/projects/:id/issues - /api/groups/:id/issues - /api/merge_requests - /api/projects/:id/merge_requests - /api/groups/:id/merge_requests
-
- 01 11月, 2018 2 次提交
-
-
由 Heinrich Lee Yu 提交于
-
由 Heinrich Lee Yu 提交于
-
- 26 10月, 2018 2 次提交
-
-
由 Heinrich Lee Yu 提交于
-
由 Heinrich Lee Yu 提交于
-
- 03 10月, 2018 1 次提交
-
-
由 Jacopo 提交于
In GET `api/v4/projects/:id/issues` the user can filter issues that have an assigned milestone through the parameter `milestone=Any+Milestone`.
-
- 02 10月, 2018 1 次提交
-
-
由 Eva Kadlecová 提交于
-
- 11 7月, 2018 1 次提交
-
-
由 Mark Chao 提交于
-
- 21 5月, 2018 1 次提交
-
-
由 Mark Chao 提交于
Deprecate corresponding dash versions created-by-me and assigned-to-me
-
- 05 3月, 2018 1 次提交
-
-
由 Jacopo 提交于
-
- 01 2月, 2018 1 次提交
-
-
由 Jarka Kadlecová 提交于
-
- 22 12月, 2017 1 次提交
-
-
由 blackst0ne 提交于
-
- 05 9月, 2017 1 次提交
-
-
由 Yorick Peterse 提交于
This changes the issue and MR index pages so the pagination system re-uses the output of the COUNT(*) query used to calculate the number of rows per state (opened, closed, etc). This removes the need for an additional COUNT(*) on both pages.
-
- 30 8月, 2017 1 次提交
-
-
由 Hiroyuki Sato 提交于
-
- 03 8月, 2017 1 次提交
-
-
由 Robert Speicher 提交于
-
- 07 7月, 2017 1 次提交
-
-
由 Felipe Artur 提交于
-
- 30 6月, 2017 2 次提交
-
-
由 Sean McGivern 提交于
-
由 Sean McGivern 提交于
When we are filtering by a single project, and the current user has access to see confidential issues on that project, we don't need to filter by confidentiality at all - just as if the user were an admin. The filter by confidentiality often picks a non-optimal query plan: for instance, AND-ing the results of all issues in the project (a relatively small set), and all issues in the states requested (a huge set), rather than just starting small and winnowing further.
-
- 19 6月, 2017 1 次提交
-
-
由 Kyle Bishop 提交于
-
- 15 6月, 2017 1 次提交
-
-
由 Robert Speicher 提交于
-