BigW Consortium Gitlab

  1. 29 Mar, 2016 2 commits
  2. 21 Mar, 2016 1 commit
  3. 20 Mar, 2016 2 commits
  4. 13 Mar, 2016 1 commit
  5. 12 Mar, 2016 3 commits
  6. 07 Mar, 2016 1 commit
  7. 19 Feb, 2016 2 commits
  8. 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
  9. 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.
  10. 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.
  11. 19 Oct, 2015 1 commit
  12. 16 Oct, 2015 3 commits
  13. 07 Oct, 2015 1 commit
  14. 03 Oct, 2015 1 commit
  15. 07 Jul, 2015 2 commits
  16. 19 Jun, 2015 1 commit
  17. 27 May, 2015 1 commit
  18. 25 May, 2015 1 commit
  19. 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.
  20. 27 Mar, 2015 2 commits
  21. 01 Jan, 2015 1 commit
  22. 05 Dec, 2014 1 commit
  23. 27 Oct, 2014 1 commit
  24. 02 Sep, 2014 1 commit
  25. 30 Jul, 2014 2 commits
  26. 29 Jul, 2014 1 commit
  27. 05 Jun, 2014 1 commit
  28. 24 Mar, 2014 1 commit
    • Fix deprecation warning output · a87f0376
      Robert Speicher authored
      Removes the following from test output:
      
        DEPRECATION WARNING: It looks like you are eager loading table(s) (one
        of: merge_requests, projects) that are referenced in a string SQL
        snippet. For example:
      
            Post.includes(:comments).where("comments.title = 'foo'")
      
        Currently, Active Record recognizes the table in the string, and knows
        to JOIN the comments table to the query, rather than loading comments in
        a separate query. However, doing this without writing a full-blown SQL
        parser is inherently flawed. Since we don't want to write an SQL parser,
        we are removing this functionality. From now on, you must explicitly
        tell Active Record when you are referencing a table from a string:
      
            Post.includes(:comments).where("comments.title =
        'foo'").references(:comments)
      
        If you don't rely on implicit join references you can disable the
        feature entirely by setting
        `config.active_record.disable_implicit_join_references = true`.