Draft: Cleanup namespace monthly usages by adding loose_foreign_key designation
What does this MR do and why?
Ci::NamespaceMonthlyUsage
was introduced !52915 (merged) with a simple integer namespace_id
column, that's not designated as a foreign key.
Because there's no designation and no AR relation defined from Namespace
back to Ci::NamespaceMonthlyUsage
at all, there's no cascading deletion and we're building up piles of stray records every time a Namespace
gets deleted #321400.
Huh, so why does the first commit in this MR add a foreign key?
We have a lovely guide to our LFK tooling that's available right in GDK, but that process is set up for a foreign key to be replaced with the LFK setup, not have JFK added to a random integer column.
My approach here is:
- Add the foreign key: 653705b2
- Replace the foreign key with LFK exactly as the scripting set it up for me: 22974fb4
- Add a third commit deleting any code involved in actually creating the foreign key: 182c631f
- Set this MR to squash on merge.
My reasoning here is that I very much do not want to add the LFK configuration by hand. We have automatic tools that we've used before and know work well, and I would like to use those tools. So I've done so, but then added my own changes to make sure that the mock FK never actually lands on production.
I suspect this also might make review easier, as a commit-by-commit review will look exactly like the swap process that the database and ci-decomposition are used to looking at.
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.