1. 03 Dec, 2017 7 commits
  2. 30 Nov, 2017 1 commit
  3. 28 Nov, 2017 1 commit
  4. 27 Nov, 2017 2 commits
  5. 24 Nov, 2017 1 commit
  6. 23 Nov, 2017 1 commit
    • Sean McGivern's avatar
      Use latest_merge_request_diff association · 8f7f03910539
      Sean McGivern authored
      Compared to the merge_request_diff association:
      
      1. It's simpler to query. The query uses a foreign key to the
         merge_request_diffs table, so no ordering is necessary.
      2. It's faster for preloading. The merge_request_diff association has to load
         every diff for the MRs in the set, then discard all but the most recent for
         each. This association means that Rails can just query for N diffs from N
         MRs.
      3. It's more complicated to update. This is a bidirectional foreign key, so we
         need to update two tables when adding a diff record. This also means we need
         to handle this as a special case when importing a GitLab project.
      
      There is some juggling with this association in the merge request model:
      
      * `MergeRequest#latest_merge_request_diff` is _always_ the latest diff.
      * `MergeRequest#merge_request_diff` reuses
        `MergeRequest#latest_merge_request_diff` unless:
          * Arguments are passed. These are typically to force-reload the association.
          * It doesn't exist. That means we might be trying to implicitly create a
            diff. This only seems to happen in specs.
          * The association is already loaded. This is important for the reasons
            explained in the comment, which I'll reiterate here: if we a) load a
            non-latest diff, then b) get its `merge_request`, then c) get that MR's
            `merge_request_diff`, we should get the diff we loaded in c), even though
            that's not the latest diff.
      
      Basically, `MergeRequest#merge_request_diff` is the latest diff in most cases,
      but not quite all.
      8f7f03910539
  7. 21 Nov, 2017 1 commit
    • Yorick Peterse's avatar
      Use arrays in Pipeline#latest_builds_with_artifacts · ae85c5b8553a
      Yorick Peterse authored
      This changes Ci::Pipeline#latest_builds_with_artifacts so it returns an
      Array instead of a relation. Whenever we use this data we do so in two
      steps:
      
      1. Count the number of rows
      2. If this number is greater than 0, iterate over the rows
      
      By returning an Array instead we only execute 1 query of which the total
      time/work is less than running either just a COUNT(*) or both queries
      (in the worst case).
      
      On GitLab.com this change should save us a few milliseconds per request
      to ProjectsController#show.
      ae85c5b8553a
  8. 16 Nov, 2017 2 commits
  9. 09 Nov, 2017 1 commit
  10. 08 Nov, 2017 1 commit
  11. 06 Nov, 2017 2 commits
  12. 27 Oct, 2017 1 commit
    • Zeger-Jan van de Weg's avatar
      Cache commits on the repository model · 77de64bc4589
      Zeger-Jan van de Weg authored
      Now, when requesting a commit from the Repository model, the results are
      not cached. This means we're fetching the same commit by oid multiple times
      during the same request. To prevent us from doing this, we now cache
      results. Caching is done only based on object id (aka SHA).
      
      Given we cache on the Repository model, results are scoped to the
      associated project, eventhough the change of two repositories having the
      same oids for different commits is small.
      77de64bc4589
  13. 21 Oct, 2017 1 commit
  14. 20 Oct, 2017 1 commit
  15. 06 Oct, 2017 1 commit
  16. 05 Oct, 2017 7 commits
  17. 03 Oct, 2017 3 commits
  18. 02 Oct, 2017 1 commit
  19. 01 Oct, 2017 2 commits
  20. 30 Sep, 2017 1 commit
  21. 28 Sep, 2017 2 commits