Nullify ci_build_id in pages_deployments table when build is destroyed
What does this MR do?
- I can't use foreign key, as we're planning to move
ci_builds
to another database -
existing orphaned pages deployments will be fixed in another MR(to speed up reviews)Currently there are 0 orphaned records in the database(runexplain SELECT "pages_deployments".* FROM "pages_deployments" LEFT JOIN ci_builds ON pages_deployments.ci_build_id = ci_builds.id WHERE pages_deployments.ci_build_id IS NOT NULL AND ci_builds.id IS NULL
in#database-lab
, and seeGather (cost=1001.00..31476.09 rows=1 width=133) (actual time=57.163..70.246 rows=0
on the top node - We nullify, not delete records because this field on pages deployment is used only by !67303 (merged) and it handles
null
s properly
Does this MR meet the acceptance criteria?
Conformity
-
I have included changelog trailers, or none are needed. (Does this MR need a changelog?) -
I have added/updated documentation, or it's not needed. (Is documentation required?) -
I have properly separated EE content from FOSS, or this MR is FOSS only. (Where should EE code go?) -
I have added information for database reviewers in the MR description, or it's not needed. (Does this MR have database related changes?) -
I have self-reviewed this MR per code review guidelines. -
This MR does not harm performance, or I have asked a reviewer to help assess the performance impact. (Merge request performance guidelines) -
I have followed the style guides. -
This change is backwards compatible across updates, or this does not apply.
Availability and Testing
-
I have added/updated tests following the Testing Guide, or it's not needed. (Consider all test levels. See the Test Planning Process.) -
I have tested this MR in all supported browsers, or it's not needed. -
I have informed the Infrastructure department of a default or new setting change per definition of done, or it's not needed.
Related to #336442 (closed)
Edited by Vladimir Shushlin