de321fbbb5
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.
|
||
|---|---|---|
| .. | ||
| .gitkeep | ||
| 20160824121037_change_personal_access_tokens_default_back_to_empty_array.rb | ||
| 20161011222551_remove_inactive_jira_service_properties.rb | ||
| 20161109150329_fix_project_records_with_invalid_visibility.rb | ||
| 20161221140236_remove_unneeded_services.rb | ||
| 20161221153951_rename_reserved_project_names.rb | ||
| 20170106172224_remove_project_authorizations_id_column.rb | ||