We denote classes of tables with the `class` key in it's database dictionary. [Example](https://gitlab.com/gitlab-org/gitlab/-/blob/master/db/docs/cloud_connector_access.yml?ref_type=heads): ```yml --- table_name: cloud_connector_access classes: - CloudConnector::Access ``` Here, `CloudConnector::Access` is the table backing the `cloud_connector_access` table. However, currently, some tables in the app are missing a Rails model to back this table. Here is a list of such table names and their feature categories: ```ruby [ ["approval_group_rules_protected_branches", ["source_code_management"]], ["approval_group_rules_users", ["source_code_management"]], ["approval_merge_request_rules_approved_approvers", ["code_review_workflow"]], ["dast_scanner_profiles_tags", ["dynamic_application_security_testing"]], ["dast_site_profiles_pipelines", ["dynamic_application_security_testing"]], ["dingtalk_tracker_data", ["integrations"]], ["external_approval_rules_protected_branches", ["compliance_management"]], ["external_status_checks_protected_branches", ["compliance_management"]], ["issues_prometheus_alert_events", ["incident_management"]], ["issues_self_managed_prometheus_alert_events", ["incident_management"]], ["operations_feature_flag_scopes", ["feature_flags"]], ] ``` These tables need to have a Rails model backing them because: - once we have that, we can set a desired_sharding_key on these models. Setting of desired sharding keys requires a Rails model to be present for a table because we need to validate that the `belongs_to` association used to backfill this column actually exists and is valid. Implementation plan: - We will be creating issues and assigning them to the respective teams owning these tables to perform this task. They should: - Create a Rails model for this table. - Set up the `belongs_to` associations on this model based on the current state of columns on this table. - Link the `class` to the table using the table's `db/docs/table_name.yml` file, with the `classes` key. [Example](https://gitlab.com/gitlab-org/gitlab/-/blob/d72c837fd0e7085db1368114ab7385af53e43233/db/docs/cloud_connector_access.yml#L3). Once class has been added in the `yml`, gitlab~19419036 can run automations to set desired sharding keys for these tables. PS: If the table is no longer used or is not needed, you needn't add a model, rather you can work on dropping the table altogether. ### Example MR: See https://gitlab.com/gitlab-org/gitlab/-/merge_requests/145265/diffs