Validate constraints on spam_logs.user_id
What does this MR do and why?
This MR is a follow-up to !212667 (merged) to fully enable the NOT NULL and foreign key constraints on spam_logs.user_id.
ci: == 20251124174123 AddNotNullConstraintOnSpamLogsUserId: migrating =============
ci: -- current_schema(nil)
ci: -> 0.1073s
ci: -- transaction_open?(nil)
ci: -> 0.0000s
ci: -- transaction_open?(nil)
ci: -> 0.0001s
ci: -- execute("ALTER TABLE spam_logs\nADD CONSTRAINT check_56d1d910ee\nCHECK ( user_id IS NOT NULL )\nNOT VALID;\n")
ci: -> 0.1278s
ci: == 20251124174123 AddNotNullConstraintOnSpamLogsUserId: migrated (2.6555s) ====
ci: == [advisory_lock_connection] object_id: 125140, pg_backend_pid: 39
ci: == [advisory_lock_connection] object_id: 125140, pg_backend_pid: 39
ci: == 20251124174127 AddForeignKeyToUsersOnSpamLogs: migrating ===================
ci: -- transaction_open?(nil)
ci: -> 0.0000s
ci: -- transaction_open?(nil)
ci: -> 0.0000s
ci: -- execute("ALTER TABLE spam_logs ADD CONSTRAINT fk_1cb83308b1 FOREIGN KEY (user_id) REFERENCES users (id) ON DELETE CASCADE NOT VALID;")
ci: -> 0.1815s
ci: == 20251124174127 AddForeignKeyToUsersOnSpamLogs: migrated (3.0361s) ==========https://ops.gitlab.net/gitlab-com/database-team/gitlab-com-database-testing/-/jobs/21470387
References
MR acceptance checklist
Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.
Edited by mo khan