An error occurred fetching the project authors.
- 19 Apr, 2018 3 commits
- 18 Apr, 2018 1 commit
-
-
Yorick Peterse authored
This reverts the addition of the "goldiloader" Gem and all use of it. While this Gem is very promising it's causing a variety of problems on GitLab.com due to it eager-loading too much data in places where we don't expect/can handle this. At least for the time being this means we have to go back to manually fixing N+1 query problems, but at least those should not cause a negative impact on availability.
-
- 09 Apr, 2018 1 commit
-
-
Yorick Peterse authored
Goldiloader (https://github.com/salsify/goldiloader) can eager load associations automatically. This removes the need for adding "includes" calls in a variety of different places. This also comes with the added benefit of not having to eager load data if it's not used.
-
- 05 Apr, 2018 1 commit
-
-
Felipe Artur authored
-
- 04 Apr, 2018 1 commit
-
-
blackst0ne authored
-
- 30 Mar, 2018 1 commit
-
-
Sean McGivern authored
Also, refactor the mail sending slightly: instead of one worker sending all emails, create a worker per project with issues due, which will send all emails for that project.
-
- 16 Mar, 2018 4 commits
-
-
Andreas Brandl authored
-
Andreas Brandl authored
-
Andreas Brandl authored
-
Andreas Brandl authored
-
- 05 Mar, 2018 1 commit
-
-
haseeb authored
-
- 28 Feb, 2018 1 commit
-
-
haseeb authored
-
- 22 Feb, 2018 1 commit
-
-
Bob Van Landuyt authored
-
- 08 Jan, 2018 1 commit
-
-
Yorick Peterse authored
This removes all usage of soft removals except for the "pending delete" system implemented for projects. This in turn simplifies all the query plans of the models that used soft removals. Since we don't really use soft removals for anything useful there's no point in keeping it around. This _does_ mean that hard removals of issues (which only admins can do if I'm not mistaken) can influence the "iid" values, but that code is broken to begin with. More on this (and how to fix it) can be found in https://gitlab.com/gitlab-org/gitlab-ce/issues/31114. Fixes https://gitlab.com/gitlab-org/gitlab-ce/issues/37447
-
- 05 Jan, 2018 2 commits
-
-
Jarka Kadlecová authored
-
Jarka Kadlecová authored
-
- 02 Jan, 2018 1 commit
-
-
Oswaldo Ferreira authored
-
- 11 Dec, 2017 2 commits
-
-
Yorick Peterse authored
-
Sean McGivern authored
This migration also needs to be a post-deployment migration, as it removes a column.
-
- 06 Dec, 2017 1 commit
-
-
Yorick Peterse authored
This throttles the number of UPDATE queries that can be triggered by calling "touch" on a Note, Issue, or MergeRequest. For Note objects we also take care of updating the associated "noteable" relation in a smarter way than Rails does by default.
-
- 25 Nov, 2017 1 commit
-
-
George Andrinopoulos authored
-
- 20 Nov, 2017 1 commit
-
-
Oswaldo Ferreira authored
-
- 13 Nov, 2017 1 commit
-
-
George Andrinopoulos authored
-
- 11 Nov, 2017 1 commit
-
-
George Andrinopoulos authored
-
- 07 Nov, 2017 1 commit
-
-
Jarka Kadlecova authored
-
- 02 Nov, 2017 1 commit
-
-
Jarka Kadlecova authored
-
- 09 Oct, 2017 3 commits
-
-
Rémy Coutable authored
Signed-off-by: Rémy Coutable <remy@rymai.me>
-
Rémy Coutable authored
Signed-off-by: Rémy Coutable <remy@rymai.me>
-
Rémy Coutable authored
Signed-off-by: Rémy Coutable <remy@rymai.me>
-
- 23 Sep, 2017 1 commit
-
-
Vitaliy @blackst0ne Klachkov authored
-
- 19 Sep, 2017 1 commit
-
-
Yorick Peterse authored
This ensures the open issues/MR count caches are refreshed properly when creating new issues or MRs. This MR also includes a change to the cache keys to ensure all caches are rebuilt on the fly. This particular problem was not caught in the test suite due to a null cache being used, resulting in all calls that would use a cache using the underlying data directly. In production the code would fail because a newly saved record returns an empty hash in #changes meaning checks such as `state_changed? || confidential_changed?` would return false for new rows, thus never updating the counters. Fixes https://gitlab.com/gitlab-org/gitlab-ce/issues/38061
-
- 11 Sep, 2017 1 commit
-
-
Shinichi Maeshima authored
-
- 30 Aug, 2017 1 commit
-
-
Yorick Peterse authored
This ensures the issues/MR cache of the sidebar is only updated when the state or confidential flags changes, instead of changing this for every update.
-
- 23 Aug, 2017 1 commit
-
-
Yorick Peterse authored
Every project page displays a navigation menu that in turn displays the number of open issues and merge requests. This means that for every project page we run two COUNT(*) queries, each taking up roughly 30 milliseconds on GitLab.com. By caching these numbers and refreshing them whenever necessary we can reduce loading times of all these pages by up to roughly 60 milliseconds. The number of open issues does not include confidential issues. This is a trade-off to keep the code simple and to ensure refreshing the data only needs 2 COUNT(*) queries instead of 3. A downside is that if a project only has 5 confidential issues the counter will be set to 0. Because we now have 3 similar counting service classes the code previously used in Projects::ForksCountService has mostly been moved to Projects::CountService, which in turn is reused by the various service classes. Fixes https://gitlab.com/gitlab-org/gitlab-ce/issues/36622
-
- 18 Aug, 2017 1 commit
-
-
Felipe Artur authored
-
- 17 Aug, 2017 1 commit
-
-
Douwe Maan authored
-
- 28 Jul, 2017 1 commit
-
-
Yorick Peterse authored
Having two states that essentially mean the same thing is very much like having a boolean "true" and boolean "mostly-true": it's rather silly. This commit merges the "reopened" state into the "opened" state while taking care of system notes still showing messages along the lines of "Alice reopened this issue". A big benefit from having only two states (opened and closed) is that indexing and querying becomes simpler and more performant. For example, to get all the opened queries we no longer have to query both states: SELECT * FROM issues WHERE project_id = 2 AND state IN ('opened', 'reopened'); Instead we can query a single state directly, which can be much faster: SELECT * FROM issues WHERE project_id = 2 AND state = 'opened'; Further, only having two states makes indexing easier as we will only ever filter (and thus scan an index) using a single value. Partial indexes could help but aren't supported on MySQL, complicating the development process and not being helpful for MySQL.
-
- 07 Jul, 2017 1 commit
-
-
James Lopez authored
-