![]() 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 |