Read about our upcoming Code of Conduct on this issue

  1. 07 May, 2019 1 commit
  2. 10 Apr, 2019 1 commit
  3. 27 Mar, 2019 1 commit
  4. 31 Oct, 2018 1 commit
  5. 12 Oct, 2018 1 commit
  6. 12 Sep, 2018 1 commit
  7. 11 Sep, 2018 2 commits
  8. 23 Jul, 2018 1 commit
  9. 16 Jul, 2018 1 commit
  10. 04 Apr, 2018 1 commit
  11. 06 Nov, 2017 1 commit
  12. 07 Sep, 2017 1 commit
  13. 24 Aug, 2017 1 commit
  14. 06 Jul, 2017 1 commit
  15. 19 Jun, 2017 1 commit
    • Yorick Peterse's avatar
      Refactor GroupProjectsFinder#init_collection · 8ab693fa5bec
      Yorick Peterse authored
      This optimises how GroupProjectsFinder builds it collection, producing
      simpler and faster queries in the process. It also cleans up the code a
      bit to make it easier to understand.
      8ab693fa5bec
  16. 16 Jun, 2017 1 commit
    • Yorick Peterse's avatar
      Refactor ProjectsFinder#init_collection · 175cffb1bca8
      Yorick Peterse authored
      This changes ProjectsFinder#init_collection so it no longer relies on a
      UNION. For example, to get starred projects of a user we used to run:
      
          SELECT projects.*
          FROM projects
          WHERE projects.pending_delete = 'f'
          AND (
              projects.id IN (
                  SELECT projects.id
                  FROM projects
                  INNER JOIN users_star_projects
                      ON users_star_projects.project_id = projects.id
                  INNER JOIN project_authorizations
                      ON projects.id = project_authorizations.project_id
                  WHERE projects.pending_delete = 'f'
                  AND project_authorizations.user_id = 1
                  AND users_star_projects.user_id = 1
      
                  UNION
      
                  SELECT projects.id
                  FROM projects
                  INNER JOIN users_star_projects
                      ON users_star_projects.project_id = projects.id
                  WHERE projects.visibility_level IN (20, 10)
                  AND users_star_projects.user_id = 1
              )
          )
          ORDER BY projects.id DESC;
      
      With these changes the above query is turned into the following instead:
      
          SELECT projects.*
          FROM projects
          INNER JOIN users_star_projects
              ON users_star_projects.project_id = projects.id
          WHERE projects.pending_delete = 'f'
          AND (
              EXISTS (
                  SELECT 1
                  FROM project_authorizations
                  WHERE project_authorizations.user_id = 1
                  AND (project_id = projects.id)
              )
              OR projects.visibility_level IN (20,10)
          )
          AND users_star_projects.user_id = 1
          ORDER BY projects.id DESC;
      
      This query in turn produces a better execution plan and takes less time,
      though the difference is only a few milliseconds (this however depends
      on the amount of data involved and additional conditions that may be
      added).
      175cffb1bca8
  17. 30 May, 2017 4 commits
    • Toon Claes's avatar
      Add :owned param to ProjectFinder · dc3bdec712b3
      Toon Claes authored
      And use it in the API.
      dc3bdec712b3
    • Toon Claes's avatar
      Make it possible to combine :trending with other params · 3e9854f01f19
      Toon Claes authored
      Now it is possible to combine the :non_public parameter. This might be useful
      when a user wants to know the trending projects they are member of.
      3e9854f01f19
    • Toon Claes's avatar
      UNION of SELECT/WHERE is faster than WHERE on UNION · 53e347d55877
      Toon Claes authored
      Instead of applying WHERE on a UNION, apply the WHERE on each of the seperate
      SELECT statements, and do UNION on that.
      
      Local tests with about 2_000_000 projects:
       - 1_500_000 private projects
       -    40_000 internal projects
       -   400_000 public projects
      
      For the API endpoint `/api/v4/projects?visibility=private` the slowest query was:
      
      ```sql
      SELECT "projects".*
      FROM "projects"
      WHERE ...
      ```
      
      The original query took 1073.8ms.
      The query refactored to UNION of SELECT/WHERE took 2.3ms.
      
      The original query was:
      
      ```sql
      SELECT "projects".*
      FROM "projects"
      WHERE "projects"."pending_delete" = $1
        AND (projects.id IN
               (SELECT "projects"."id"
                FROM "projects"
                INNER JOIN "project_authorizations" ON "projects"."id" = "project_authorizations"."project_id"
                WHERE "projects"."pending_delete" = 'f'
                  AND "project_authorizations"."user_id" = 23
                UNION SELECT "projects"."id"
                FROM "projects"
                WHERE "projects"."visibility_level" IN (20,
                                                        10)))
        AND "projects"."visibility_level" = $2
        AND "projects"."archived" = $3
      ORDER BY "projects"."created_at" DESC
      LIMIT 20
      OFFSET 0 [["pending_delete", "f"],
             ["visibility_level", 0],
             ["archived", "f"]]
      ```
      
      The refactored query:
      ```sql
      SELECT "projects".*
      FROM "projects"
      WHERE "projects"."pending_delete" = $1
        AND (projects.id IN
               (SELECT "projects"."id"
                FROM "projects"
                INNER JOIN "project_authorizations" ON "projects"."id" = "project_authorizations"."project_id"
                WHERE "projects"."pending_delete" = 'f'
                  AND "project_authorizations"."user_id" = 23
                  AND "projects"."visibility_level" = 0
                  AND "projects"."archived" = 'f'
                UNION SELECT "projects"."id"
                FROM "projects"
                WHERE "projects"."visibility_level" IN (20,
                                                        10)
                  AND "projects"."visibility_level" = 0
                  AND "projects"."archived" = 'f'))
      ORDER BY "projects"."created_at" DESC
      LIMIT 20
      OFFSET 0 [["pending_delete", "f"]]
      ```
      53e347d55877
    • Toon Claes's avatar
      Change ProjectFinder so starred can be combined with other filters · 236da079726f
      Toon Claes authored
      The `starred` parameter couldn't be used in combination with `trending` or
      `non_public`. But this is changed now.
      236da079726f
  18. 06 Apr, 2017 1 commit
    • Jacopo's avatar
      ProjectsFinder should handle more options · 05d2c6345fa2
      Jacopo authored
      Extended ProjectFinder in order to handle the following options:
       - current_user - which user use
       - project_ids_relation: int[] - project ids to use
       - params:
         -  trending: boolean
         -  non_public: boolean
         -  starred: boolean
         -  sort: string
         -  visibility_level: int
         -  tags: string[]
         -  personal: boolean
         -  search: string
         -  non_archived: boolean
      
      GroupProjectsFinder now inherits from ProjectsFinder.
      Changed the code in order to use the new available options.
      05d2c6345fa2
  19. 08 Feb, 2017 1 commit
  20. 15 Aug, 2016 2 commits
  21. 20 Mar, 2016 1 commit
  22. 14 Mar, 2016 1 commit
  23. 13 Mar, 2016 2 commits
  24. 12 Mar, 2016 1 commit
    • Yorick Peterse's avatar
      Removed User#project_relations · b09021aa75a0
      Yorick Peterse authored
      GitLab EE adds an extra relation that selects a "project_id" column
      instead of an "id" column, making it very hard for this method to be
      re-used in EE. Since using User#authorized_groups in
      ProjectsFinder#all_groups apparently has no performance impact we can
      just use it and keep everything compatible with EE.
      b09021aa75a0
  25. 11 Mar, 2016 2 commits
  26. 20 Nov, 2015 1 commit
    • Yorick Peterse's avatar
      Port GitLab EE ProjectsFinder changes · 7eca8f92c5da
      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.
      7eca8f92c5da
  27. 18 Nov, 2015 1 commit
    • Yorick Peterse's avatar
      Refactor ProjectsFinder to not pluck IDs · 1d2439555e72
      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.
      1d2439555e72
  28. 15 Sep, 2014 1 commit
  29. 14 Sep, 2014 1 commit
  30. 05 Jun, 2014 1 commit
  31. 25 Feb, 2014 1 commit