Set `creator_id` to nil on projects whose creator is now non existent
What does this MR do and why?
Premise
Until 3 months ago, that is, until we merged !102163 (merged), a User
could be deleted, but their ID would remain in the Project#creator_id
column and wasn't being nullified on User
destroy.
Now that we have that dependent: :nullify
relationship here, the next step is to nullify the Project#creator_id
column for projects whose creators (ie, users) have already been deleted from the database. This ensures that the data in this column is clean.
This MR attempts to do that via a batched background migration.
Total count
Total count of Project
records that needs update on gitlab.com database as on 1-Feb-2023: 60262
(Source)
Migrations
UP Migration
$ bundle exec rails db:migrate
main: == 20230130073109 NullifyCreatorIdOfOrphanedProjects: migrating ===============
main: == 20230130073109 NullifyCreatorIdOfOrphanedProjects: migrated (0.0540s) ======
ci: == 20230130073109 NullifyCreatorIdOfOrphanedProjects: migrating ===============
ci: -- The migration is skipped since it modifies the schemas: [:gitlab_main].
ci: -- This database can only apply migrations in one of the following schemas: [:gitlab_ci, :gitlab_shared, :gitlab_internal].
ci: == 20230130073109 NullifyCreatorIdOfOrphanedProjects: migrated (0.0041s) ======
DOWN Migration
$ bundle exec rails db:rollback:main STEP=1
main: == 20230130073109 NullifyCreatorIdOfOrphanedProjects: reverting ===============
main: == 20230130073109 NullifyCreatorIdOfOrphanedProjects: reverted (0.0230s) ======
$ bundle exec rails db:rollback:ci STEP=1
ci: == 20230130073109 NullifyCreatorIdOfOrphanedProjects: reverting ===============
ci: -- The migration is skipped since it modifies the schemas: [:gitlab_main].
ci: -- This database can only apply migrations in one of the following schemas: [:gitlab_ci, :gitlab_shared, :gitlab_internal].
ci: == 20230130073109 NullifyCreatorIdOfOrphanedProjects: reverted (0.0063s) ======
Screenshots or screen recordings
Screenshots are required for UI changes, and strongly recommended for all other merge requests.
How to set up and validate locally
Numbered steps to set up and validate the change are strongly suggested.
MR acceptance checklist
This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.
-
I have evaluated the MR acceptance checklist for this MR.
Related to #378477 (closed)