Prepare async FKs for check constraints
What does this MR do and why?
Related to #390651 (closed)
It renames the classes and modules used for FK async validation to allow to be extended for async check constraint validation. We can reuse this model because for check constraints we need only the table name and constraint name as we do for foreign keys.
The plan is:
- rename namespaces to something more generic
✅ - add a
constraint_type
enum column to the table with default asforeign_key
⌛ - add migration helpers for scheduling check constraints
⌛ - extend FK validator to accept check constraints
⌛
Screenshots or screen recordings
Screenshots are required for UI changes, and strongly recommended for all other merge requests.
How to set up and validate locally
Numbered steps to set up and validate the change are strongly suggested.
MR acceptance checklist
This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.
-
I have evaluated the MR acceptance checklist for this MR.
Edited by Marius Bobin