1. 23 Jan, 2017 1 commit
  2. 15 Jan, 2017 2 commits
  3. 11 Jan, 2017 1 commit
  4. 08 Jan, 2017 1 commit
    • Yorick Peterse's avatar
      Remove the project_authorizations.id column · 969751d02ea0
      Yorick Peterse authored
      This column used to be a 32 bits integer, allowing for only a maximum of
      2 147 483 647 rows. Given enough users one can hit this limit pretty
      quickly, as was the case for GitLab.com.
      
      Changing this type to bigint (= 64 bits) would give us more space, but
      we'd eventually hit the same limit given enough users and projects. A
      much more sustainable solution is to simply drop the "id" column.
      
      There were only 2 lines of code depending on this column being present,
      and neither truly required it to be present. Instead the code now uses
      the "project_id" column combined with the "user_id" column. This means
      that instead of something like this:
      
          DELETE FROM project_authorizations
          WHERE user_id = X
          AND id = Y;
      
      We now run the following when removing rows:
      
          DELETE FROM project_authorizations
          WHERE user_id = X
          AND project_id = Y;
      
      Since both user_id and project_id are indexed this should not slow down
      the DELETE query.
      
      This commit also removes the "dependent: destroy" clause from the
      "project_authorizations" relation in the User and Project models.
      Keeping this prevents Rails from being able to remove data as it relies
      on an "id" column being present. Since the "project_authorizations"
      table has proper foreign keys set up (with cascading removals) we don't
      need to depend on any Rails logic.
      969751d02ea0
  5. 03 Jan, 2017 2 commits
  6. 24 Dec, 2016 2 commits
  7. 23 Dec, 2016 1 commit
  8. 21 Dec, 2016 1 commit
    • Markus Koller's avatar
      Add more storage statistics · 4571941f6307
      Markus Koller authored
      This adds counters for build artifacts and LFS objects, and moves
      the preexisting repository_size and commit_count from the projects
      table into a new project_statistics table.
      
      The counters are displayed in the administration area for projects
      and groups, and also available through the API for admins (on */all)
      and normal users (on */owned)
      
      The statistics are updated through ProjectCacheWorker, which can now
      do more granular updates with the new :statistics argument.
      4571941f6307
  9. 20 Dec, 2016 2 commits
  10. 19 Dec, 2016 1 commit
  11. 16 Dec, 2016 3 commits
  12. 15 Dec, 2016 2 commits
  13. 14 Dec, 2016 1 commit
  14. 08 Dec, 2016 1 commit
  15. 06 Dec, 2016 1 commit
  16. 02 Dec, 2016 1 commit
  17. 29 Nov, 2016 1 commit
  18. 23 Nov, 2016 5 commits
  19. 21 Nov, 2016 1 commit
    • Yorick Peterse's avatar
      Refactor cache refreshing/expiring · f10e7ac7c903
      Yorick Peterse authored
      This refactors repository caching so it's possible to selectively
      refresh certain caches, instead of just expiring and refreshing
      everything.
      
      To allow this the various methods that were cached (e.g. "tag_count" and
      "readme") use a similar pattern that makes expiring and refreshing
      their data much easier.
      
      In this new setup caches are refreshed as follows:
      
      1. After a commit (but before running ProjectCacheWorker) we expire some
         basic caches such as the commit count and repository size.
      
      2. ProjectCacheWorker will recalculate the commit count, repository
         size, then refresh a specific set of caches based on the list of
         files changed in a push payload.
      
      This requires a bunch of changes to the various methods that may be
      cached. For one, data should not be cached if a branch used or the
      entire repository does not exist. To prevent all these methods from
      handling this manually this is taken care of in
      Repository#cache_method_output. Some methods still manually check for
      the existence of a repository but this result is also cached.
      
      With selective flushing implemented ProjectCacheWorker no longer uses an
      exclusive lease for all of its work. Instead this worker only uses a
      lease to limit the number of times the repository size is updated as
      this is a fairly expensive operation.
      f10e7ac7c903
  20. 18 Nov, 2016 5 commits
  21. 17 Nov, 2016 4 commits
  22. 16 Nov, 2016 1 commit