ym0506 commented on PR #38449: URL: https://github.com/apache/shardingsphere/pull/38449#issuecomment-4764087830
I pushed a follow-up revision at `b41c843df` addressing the create-table metadata refresh blocker. This revision adds explicit schema metadata revision candidates for the `CREATE TABLE` pushdown refresh path. The candidate metadata is derived from the parsed `CreateTableStatement`, so a brand-new sharding table can recover a long logical named index even when all actual tables expose only generated truncated physical index names. The change keeps the shared metadata revision contract target-agnostic and passes generic schema/table/index candidate metadata into `TableMetaDataRefresherLoader`. I added a production-path regression through `CreateTablePushDownMetaDataRefresher` where `tbl_0` and `tbl_1` both use `IndexMetaDataUtils.getActualIndexName(logicIndexName, actualTableName, PostgreSQL)`, and the persisted `ShardingSphereTable` restores the full logical index name. Local verification passed with: - `./mvnw -pl infra/common,features/sharding/core,mode/core -am -DskipITs -Dcheckstyle.skip -Dspotless.check.skip=true -Dsurefire.failIfNoSpecifiedTests=false -Dtest=IndexMetaDataUtilsTest,ShardingIndexReviserTest,CreateTablePushDownMetaDataRefresherTest test` - `./mvnw -pl mode/core -am -Pcheck -DskipTests -DskipITs spotless:check` - `./mvnw -pl mode/core -am -Pcheck -DskipTests -DskipITs checkstyle:check` GitHub Actions for the latest head `b41c843df` have completed successfully: `87/87` checks passed. Ready for re-review. -- 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]
