An error occurred fetching the project authors.
  1. 19 Apr, 2018 3 commits
  2. 18 Apr, 2018 1 commit
    • Yorick Peterse's avatar
      Revert the addition of goldiloader · 6f292eaa
      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.
      6f292eaa
  3. 09 Apr, 2018 1 commit
  4. 05 Apr, 2018 1 commit
  5. 04 Apr, 2018 1 commit
  6. 30 Mar, 2018 1 commit
    • Sean McGivern's avatar
      Send emails for issues due tomorrow · 2db218f8
      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.
      2db218f8
  7. 16 Mar, 2018 4 commits
  8. 05 Mar, 2018 1 commit
  9. 28 Feb, 2018 1 commit
  10. 22 Feb, 2018 1 commit
  11. 08 Jan, 2018 1 commit
  12. 05 Jan, 2018 2 commits
  13. 02 Jan, 2018 1 commit
  14. 11 Dec, 2017 2 commits
  15. 06 Dec, 2017 1 commit
    • Yorick Peterse's avatar
      Throttle the number of UPDATEs triggered by touch · 856447cc
      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.
      856447cc
  16. 25 Nov, 2017 1 commit
  17. 20 Nov, 2017 1 commit
  18. 13 Nov, 2017 1 commit
  19. 11 Nov, 2017 1 commit
  20. 07 Nov, 2017 1 commit
  21. 02 Nov, 2017 1 commit
  22. 09 Oct, 2017 3 commits
  23. 23 Sep, 2017 1 commit
  24. 19 Sep, 2017 1 commit
    • Yorick Peterse's avatar
      Fix refreshing of issues/MR count caches · 57b96eb6
      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
      57b96eb6
  25. 11 Sep, 2017 1 commit
  26. 30 Aug, 2017 1 commit
  27. 23 Aug, 2017 1 commit
    • Yorick Peterse's avatar
      Cache the number of open issues and merge requests · 6ec53f5d
      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
      6ec53f5d
  28. 18 Aug, 2017 1 commit
  29. 17 Aug, 2017 1 commit
  30. 28 Jul, 2017 1 commit
    • Yorick Peterse's avatar
      Merge issuable "reopened" state into "opened" · 6ef87a20
      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.
      6ef87a20
  31. 07 Jul, 2017 1 commit