Convert `members.user_id` to Loose Foreign Key
What does this MR do and why?
members is a main_cell table now, and users is a main_clusterwide table.
Since these tables belong to 2 different databases now, any foreign keys that exists between these 2 tables should be converted to Loose foreign keys, which is what this MR does.
On existing usage of member.user_id in the codebase:
I grepped for occurrences of member.user_id in the codebase and there are a few. However, I have not made changes to them because of the fact that:
- A user deletion is a rare occurrence in a gitlab installation.
- Once a user has been deleted, even if the member record remains till the loose foreign keys are cleaned up (2 minutes on gitlab.com), the user itself will not be able to login or access the APIs because their user record is already deleted.
The anticipated problem area due to this change is the UI or the API where we try to fetch details of the member's user record, but that record is already deleted. Surprisingly, this case is already taken care of in the UI/API:
UI - shows them as Orphaned Member
API - does not expose user details since the record is missing.
Workers:
Calls to workers using member.user_id, always return with
user = User.find_by_id(user_id)
return unless userso, we are safe in that area. So, overall, this change looks safe to make as per my understanding.
Other MRs of similar nature:
- Convert notification_settings.user_id to loose ... (!130080 - merged)
- Convert routes.namespace_id to a loose foreign key (!130096 - merged)
Screenshots or screen recordings
Screenshots are required for UI changes, and strongly recommended for all other merge requests.
| Before | After |
|---|---|
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 #419024 (closed)