BigW Consortium Gitlab

  1. 18 Jan, 2016 1 commit
    • Scope issue projects to a Group when possible · d6a8021e
      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
  2. 07 Jan, 2016 1 commit
    • Drop projects order in IssuableFinder · fc443ea7
      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.
  3. 04 Jan, 2016 1 commit
  4. 03 Dec, 2015 1 commit
  5. 20 Nov, 2015 1 commit
    • Port GitLab EE ProjectsFinder changes · fed059a1
      Yorick Peterse authored
      These changes were added in GitLab EE commit
      d39de0ea91b26b8840195e5674b92c353cc16661. The tests were a bit bugged
      (they used a non existing group, thus not testing a crucial part) which
      I only noticed when porting CE changes to EE.
  6. 19 Nov, 2015 3 commits
    • Use a JOIN in IssuableFinder#by_project · 8591cc02
      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.
    • Memoize IssuableFinder#projects · e9cd58f5
      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.
  7. 18 Nov, 2015 4 commits
    • css improvements · 06a4fd10
      Valery Sizov authored
    • Return internal projects in PersonalProjectsFinder · f486b06c
      Yorick Peterse authored
      When getting the projects of a user we should get the public _and_
      internal projects, not just the public ones.
    • Refactor ProjectsFinder to not pluck IDs · fbcf3bd3
      Yorick Peterse authored
      This class now uses a UNION (when needed) instead of plucking tens of
      thousands of project IDs into memory. The tests have also been
      re-written to ensure all different use cases are tested properly
      (assuming I didn't forget any cases).
      
      The finder has also been broken up into 3 different finder classes:
      
      * ContributedProjectsFinder: class for getting the projects a user
        contributed to.
      * PersonalProjectsFinder: class for getting the personal projects of a
        user.
      * ProjectsFinder: class for getting generic projects visible to a given
        user.
      
      Previously a lot of the logic of these finders was handled directly in
      the users controller.
    • Refactoed GroupsFinder into two separate classes · 2110247f
      Yorick Peterse authored
      In the previous setup the GroupsFinder class had two distinct tasks:
      
      1. Finding the projects user A could see
      2. Finding the projects of user A that user B could see
      
      Task two was actually handled outside of the GroupsFinder (in the
      UsersController) by restricting the returned list of groups to those the
      viewed user was a member of. Moving all this logic into a single finder
      proved to be far too complex and confusing, hence there are now two
      finders:
      
      * GroupsFinder: for finding groups a user can see
      * JoinedGroupsFinder: for finding groups that user A is a member of,
        restricted to either public groups or groups user B can also see.
  8. 16 Nov, 2015 2 commits
  9. 05 Nov, 2015 1 commit
  10. 19 Oct, 2015 1 commit
  11. 16 Oct, 2015 3 commits
  12. 07 Oct, 2015 1 commit
  13. 06 Oct, 2015 2 commits
    • Revamp trending projects query · b7abba0c
      Yorick Peterse authored
      This changes the query to use a COUNT nested in an INNER JOIN, instead
      of a COUNT plus a GROUP BY. There are two reasons for this:
      
      1. Using a COUNT in an INNER JOIN can be quite a bit faster.
      2. The use of a GROUP BY means that method calls such as "any?"
         (and everything else that calls "count") operate on a Hash that
         counts the amount of notes on a per project basis, instead of just
         counting the total amount of projects.
      
      The query has been moved into Project.trending as its logic is simple
      enough. As a result of this testing the TrendingProjectsFinder class
      simply involves testing if the right methods are called, removing the
      need for setting up database records.
    • Use >= instead of > in TrendingProjectsFinder · d15eec64
      Yorick Peterse authored
      By using >= we can ensure we actually get all comments of the past
      month, instead of the comments of the past month minus the first day in
      the range.
  14. 03 Oct, 2015 1 commit
  15. 18 Sep, 2015 1 commit
  16. 26 Aug, 2015 1 commit
  17. 07 Jul, 2015 2 commits
  18. 19 Jun, 2015 1 commit
  19. 27 May, 2015 1 commit
  20. 25 May, 2015 1 commit
  21. 30 Apr, 2015 1 commit
    • Group milestones by title in the dashboard and all other issue views · e6ee8d0e
      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.
  22. 27 Mar, 2015 2 commits
  23. 19 Feb, 2015 1 commit
  24. 06 Feb, 2015 2 commits
  25. 03 Feb, 2015 2 commits
  26. 01 Jan, 2015 1 commit
  27. 05 Dec, 2014 1 commit