terrymanu commented on PR #38449:
URL: https://github.com/apache/shardingsphere/pull/38449#issuecomment-4624721436
Thanks for clarifying the remaining blocker.
Yes, my understanding is the same: the unresolved part is now the shared
metadata revise path in `ShardingIndexReviser`, not the MySQL merged-result or
pipeline path.
I think this still needs to be addressed before merge, because the PR scope
explicitly includes sharding metadata revision and the current shared path can
still lose the original logical index name for truncated named indexes. If the
reviser cannot access candidate logical index names, then extending the shared
metadata revise contract is acceptable, but it should be done as a generic
metadata-revision capability rather than a target-dialect-specific workaround.
Suggested direction:
- pass enough table/index metadata into the index revise path so
`ShardingIndexReviser` can use the same candidate-aware recovery as the MySQL
and pipeline paths;
- keep the shared API target-agnostic, with no
PostgreSQL/openGauss/Oracle-specific naming concepts in the shared contract;
- add direct regression tests for:
- truncated named index recovery in `ShardingIndexReviser`;
- exact logical index names ending with `_hxxxxxxxx` / `_txxxxxxxx`;
- one shared metadata revise case outside the MySQL merged-result path.
If this turns out to require a larger shared API change, please keep it
minimal and focused on explicit candidate metadata propagation.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
