Backfill sharding key on note_metadata table
What does this MR do and why?
Backfill the sharding key on the note_metadata table
- Add background migration to backfill
namespace_idfrom parent tablenotes. The migration code only updates the timestamp, so the sharding key column is backfilled by the existing triggerset_sharding_key_for_note_metadata_on_insert_and_update()that populates this column. - Add model validation to ensure
namespace_idvalue is set on record creation - Validate the presence of
namespace_idon record creation
Note that Changes 2 and 3 apply to new records only, but will be extended to update once we validate the NOT NULL constraint on this column. Any cases that bypass the callback will be covered by the trigger (added in the previous MR).
References
Add `note_metadata` sharding key (!208652 - merged)
Related to #550695
DB
- Total number of rows in table: https://console.postgres.ai/gitlab/gitlab-production-main/sessions/45838/commands/140277
- Number of rows where
namespace_id IS NULL: https://console.postgres.ai/gitlab/gitlab-production-main/sessions/45838/commands/140278
Backfill query
UPDATE "note_metadata" SET updated_at = updated_at WHERE "note_metadata"."note_id" BETWEEN 11 AND 15 AND "note_metadata"."note_id" IN (11, 12) AND "note_metadata"."namespace_id" IS NULL
Plan: https://console.postgres.ai/gitlab/gitlab-production-main/sessions/45838/commands/140289
Note: It is hard to find the right IDs to test this query because there are very few notes with a note_metadata record. Instead, I included a plan that shows the set_sharding_key_for_note_metadata_on_insert_and_update() trigger being executed.
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.