Support ALTER TABLE RENAME TO for sharding and broadcast tables #36873
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
* Remove restrictions in ShardingAlterTableSupportedChecker and ShardingRenameTableSupportedChecker * Add validation to prevent conflicts with existing sharding tables * Add renameTables() method to MetaDataManagerPersistService interface * Implement metadata refresh for table rename operations in both cluster and standalone modes * Add comprehensive test coverage for rename table operations
Member
|
Could you fix checkstyle first? |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Problem
Currently,
ALTER TABLE ... RENAME TO ...andRENAME TABLEstatements are blocked for sharding and broadcast tables, even though the underlying physical rename operation would succeed. This limitation exists because the original implementation (PR #10462) only addressed single tables, leaving sharding and broadcast tables unsupported.Users managing sharded databases cannot rename their tables through standard SQL, forcing them to manually drop and recreate tables with new names - a disruptive operation that requires data migration.
Solution
Instead of blocking rename operations entirely, this change allows the physical table rename to proceed while validating that the new table name doesn't conflict with existing sharding rules or schema tables.
The validation logic now focuses on preventing naming conflicts rather than blocking the operation outright:
For single tables, metadata rules are automatically refreshed after rename. For sharding and broadcast tables, the physical rename succeeds and users can update their rules via DistSQL commands - consistent with existing DROP/CREATE TABLE behavior.
Impact
Breaking change in validation behavior: Previously, any rename operation involving sharding tables would fail immediately. Now, validation focuses on the target table name conflicts, allowing legitimate rename operations to proceed.
Supported modes: Works in both Standalone and Cluster modes. In Standalone mode with in-memory repository, changes are volatile; with JDBC repository, changes persist across restarts.
User workflow for sharding/broadcast tables:
ALTER TABLE ... RENAME TO ...orRENAME TABLE- physical tables are renamedCloses #10476
Before committing this PR, I'm sure that I have checked the following options:
./mvnw clean install -B -T1C -Dmaven.javadoc.skip -Dmaven.jacoco.skip -e.