Skip to content

Draft: Cleanup namespace monthly usages by adding loose_foreign_key designation

drew stachon requested to merge cleanup-namespace-monthly-usages into master

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:

  1. Add the foreign key: 653705b2
  2. Replace the foreign key with LFK exactly as the scripting set it up for me: 22974fb4
  3. Add a third commit deleting any code involved in actually creating the foreign key: 182c631f
  4. 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.

Edited by drew stachon

Merge request reports