rishi-rana commented on PR #39882: URL: https://github.com/apache/shardingsphere/pull/39882#issuecomment-6257863592
Thanks, both fixed in 9eab3acb039. 1. Rename destination schema — fixed, and I also checked for the same issue elsewhere since the root cause is "destination identifier bound like a fresh unqualified reference, not inheriting its source's schema." `RenameTableStatement` (`RENAME TABLE a TO x`) has the identical `(table, renameTable)` pair shape in `RenameTableDefinitionSegment` and is in the same deferrable set, so it had the same bug — fixed in the same boundary. Both `AlterTableStatement.getRenameTable()` and each `RenameTableStatement.getRenameTables()` pair now resolve the destination's schema from its source table, not its own bound info. Added a regression test for each. 2. Partial LOCAL commit — fixed by moving the `reconcile()` call into the `finally` block in `ProxyBackendTransactionManager.commit()`, so it always runs after a commit attempt, success or failure. This is safe because reconciliation is state-driven — it queries each table's actual current state via `ContextManager.reconcileTable()` rather than assuming the commit succeeded — and that method already swallows its own exceptions, so it can't mask the original commit failure. Verified against a reverted version: the existing `assertCommitNotRefreshesDeferredMetaDataWhenUnderlyingCommitFailed` test was asserting the buggy behavior directly, so I inverted it rather than adding a parallel test. One thing I checked but didn't change, flagging in case it's worth a separate look: `AlterTableStatement.getTables()` also pulls in tables merely referenced by a new foreign-key constraint (e.g. `ALTER TABLE t1 ADD CONSTRAINT fk FOREIGN KEY(x) REFERENCES t2(id)` includes `t2`), so this PR's deferred-refresh loop will also harmlessly re-reconcile `t2` even though only `t1` actually changed. Not a correctness issue — reconciliation just re-syncs `t2` to its own unchanged state — but it's extra work on every such ALTER, so I wanted to surface it rather than silently leave it unaddressed or fix it unprompted. 3. Still awaiting your sign-off on the transactional DDL support contract. -- 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]
