1. 16 Mar, 2018 1 commit
  2. 22 Feb, 2018 1 commit
  3. 08 Jan, 2018 1 commit
  4. 05 Jan, 2018 2 commits
  5. 02 Jan, 2018 1 commit
  6. 11 Dec, 2017 2 commits
  7. 06 Dec, 2017 1 commit
    • Yorick Peterse's avatar
      Throttle the number of UPDATEs triggered by touch · 4e971949a7d4
      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.
  8. 25 Nov, 2017 1 commit
  9. 20 Nov, 2017 1 commit
  10. 13 Nov, 2017 1 commit
  11. 11 Nov, 2017 1 commit
  12. 07 Nov, 2017 1 commit
  13. 02 Nov, 2017 1 commit
  14. 09 Oct, 2017 3 commits
  15. 23 Sep, 2017 1 commit
  16. 19 Sep, 2017 1 commit
    • Yorick Peterse's avatar
      Fix refreshing of issues/MR count caches · 25de25286342
      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
  17. 11 Sep, 2017 1 commit
  18. 30 Aug, 2017 1 commit
  19. 23 Aug, 2017 1 commit
    • Yorick Peterse's avatar
      Cache the number of open issues and merge requests · c5d0237e8e0d
      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
      Fixes https://gitlab.com/gitlab-org/gitlab-ce/issues/36622
  20. 18 Aug, 2017 1 commit
  21. 17 Aug, 2017 1 commit
  22. 28 Jul, 2017 1 commit
    • Yorick Peterse's avatar
      Merge issuable "reopened" state into "opened" · 5048bfd58cf0
      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.
  23. 07 Jul, 2017 2 commits
  24. 06 Jul, 2017 2 commits
    • Yorick Peterse's avatar
      Added Cop to blacklist the use of `dependent:` · ccb23d8870a8
      Yorick Peterse authored
      This is allowed for existing instances so we don't end up 76 offenses
      right away, but for new code one should _only_ use this if they _have_
      to remove non database data. Even then it's usually better to do this in
      a service class as this gives you more control over how to remove the
      data (e.g. in bulk).
    • Yorick Peterse's avatar
      Add many foreign keys to the projects table · 8b8987deee58
      Yorick Peterse authored
      This removes the need for relying on Rails' "dependent" option for data
      removal, which is _incredibly_ slow (even when using :delete_all) when
      deleting large amounts of data. This also ensures data consistency is
      enforced on DB level and not on application level (something Rails is
      really bad at).
      This commit also includes various migrations to add foreign keys to
      tables that eventually point to "projects" to ensure no rows get
      orphaned upon removing a project.
  25. 05 Jul, 2017 1 commit
  26. 21 Jun, 2017 1 commit
  27. 16 Jun, 2017 2 commits
  28. 02 Jun, 2017 1 commit
  29. 13 May, 2017 1 commit
  30. 12 May, 2017 1 commit
  31. 04 May, 2017 2 commits
  32. 21 Apr, 2017 1 commit