BigW Consortium Gitlab

  1. 06 Dec, 2017 1 commit
    • Throttle the number of UPDATEs triggered by touch · 856447cc
      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.
  2. 27 Nov, 2017 2 commits
  3. 24 Nov, 2017 1 commit
  4. 23 Nov, 2017 1 commit
    • Use latest_merge_request_diff association · 991bf24e
      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.
  5. 15 Nov, 2017 1 commit
  6. 13 Nov, 2017 2 commits
  7. 11 Nov, 2017 2 commits
  8. 09 Nov, 2017 1 commit
  9. 06 Nov, 2017 1 commit
  10. 03 Nov, 2017 1 commit
  11. 02 Nov, 2017 1 commit
  12. 31 Oct, 2017 1 commit
  13. 12 Oct, 2017 1 commit
  14. 11 Oct, 2017 1 commit
  15. 09 Oct, 2017 3 commits
  16. 06 Oct, 2017 1 commit
    • Create idea of read-only database · d1366971
      Toon Claes authored
      In GitLab EE, a GitLab instance can be read-only (e.g. when it's a Geo
      secondary node). But in GitLab CE it also might be useful to have the
      "read-only" idea around. So port it back to GitLab CE.
      
      Also having the principle of read-only in GitLab CE would hopefully
      lead to less errors introduced, doing write operations when there
      aren't allowed for read-only calls.
      
      Closes gitlab-org/gitlab-ce#37534.
  17. 05 Oct, 2017 3 commits
  18. 04 Oct, 2017 8 commits
  19. 06 Sep, 2017 6 commits
  20. 30 Aug, 2017 2 commits