Skip to content

G
gitlab-foss

李少辉-开发者 / gitlab-foss

通知 15
Star 0
Fork 0
G
gitlab-foss

体验新版 GitCode，发现更多精彩内容 >>

切换分支/标签
  1. 08 1月, 2017 1 次提交
    • Y
      Remove the project_authorizations.id column · de321fbb
      由 Yorick Peterse 提交于 
      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.
      de321fbb
  3. 03 1月, 2017 2 次提交
  5. 25 12月, 2016 1 次提交
  7. 24 12月, 2016 1 次提交
  9. 23 12月, 2016 1 次提交
  11. 21 12月, 2016 3 次提交
  13. 20 12月, 2016 1 次提交
  15. 17 12月, 2016 2 次提交
  17. 16 12月, 2016 2 次提交
  19. 15 12月, 2016 2 次提交
  21. 08 12月, 2016 1 次提交
  23. 06 12月, 2016 1 次提交
  25. 03 12月, 2016 1 次提交
  27. 29 11月, 2016 1 次提交
  29. 23 11月, 2016 5 次提交
  31. 21 11月, 2016 1 次提交
    • Y
      Refactor cache refreshing/expiring · ffb9b3ef
      由 Yorick Peterse 提交于 
      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.
      ffb9b3ef
  33. 19 11月, 2016 2 次提交
  35. 18 11月, 2016 7 次提交
  37. 16 11月, 2016 4 次提交
  39. 15 11月, 2016 1 次提交