Backfill sharding key on note_metadata table

What does this MR do and why?

Backfill the sharding key on the note_metadata table

  1. Add background migration to backfill namespace_id from parent table notes. The migration code only updates the timestamp, so the sharding key column is backfilled by the existing trigger set_sharding_key_for_note_metadata_on_insert_and_update() that populates this column.
  2. Add model validation to ensure namespace_id value is set on record creation
  3. Validate the presence of namespace_id on 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

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.

Edited by Eugenia Grieff

Merge request reports

Loading