Add specs for changes surrounding "next" desired sharding key
What does this MR do and why?
We are introducing a concept of "next" desired sharding key. It is like today's desired_sharding_key concept, but these are for tables that:
- have a non-nullable parent association
- but the parent association does not have a fully backfilled
sharding_key
yet. It only adesired_sharding_key
set now, but it will be eventually backfilled, and when that is completed, these tables can inturn backfill from that parent association. See this for an understanding of how this will work.
We use awaiting_backfill_on_parent: true
to distinguish between these type of desired sharding keys and normal desired sharding keys.
You can see the diff in the POC MR to see how these will be generated: !145135 (diffs)
MR acceptance checklist
Please evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.
Screenshots or screen recordings
Screenshots are required for UI changes, and strongly recommended for all other merge requests.
Before | After |
---|---|
How to set up and validate locally
Numbered steps to set up and validate the change are strongly suggested.
Related to #442385 (closed)
Edited by Manoj M J