## Summary Define and implement a sharding key for the `upload_states` table to enable the migration strategy for Geo verification state tables. ⚠️ **Note**: This table requires special handling as noted in the epic discussion. ## Background As part of the [Geo verification state tables migration strategy for Protocell organization moves](https://gitlab.com/groups/gitlab-org/-/epics/20487), we need to mark Geo verification state tables as `gitlab_main_org` instead of `gitlab_main_cell_local`/`gitlab_ci_cell_local`. This requires defining sharding keys on tables that don't have them yet. ## Current Status | Step | Status | |------|--------| | Sharding Key Defined | ⬜ Not defined | | Backfill | ⬜ Pending | | Finalize | ⬜ Pending | | NOT NULL Constraint | ⬜ Pending | ## Special Considerations Uploads can be associated with various model types (projects, groups, users, etc.) through a polymorphic association. This complicates the sharding key definition. Investigation is needed to determine: - How to handle the polymorphic `model_type` and `model_id` columns - Whether a different sharding strategy is needed for this table ## Tasks - [x] Investigate the polymorphic relationship in the uploads table - [x] Determine the appropriate sharding key strategy - [ ] Add sharding key column to the table - [ ] Create backfill migration - [ ] Run backfill on GitLab.com - [ ] Finalize the backfill - [ ] Add NOT NULL constraint - [ ] Update table schema classification to `gitlab_main_org` - [ ] Verify the table is included in organization migration replication ## References - Parent Epic: https://gitlab.com/groups/gitlab-org/-/epics/20487 - Table Schema: https://gitlab.com/gitlab-org/gitlab/-/blob/master/db/docs/upload_states.yml