rishi-rana commented on PR #39882: URL: https://github.com/apache/shardingsphere/pull/39882#issuecomment-5753129942
Thanks for both findings. Addressed in 5c5ea8bc04097599338aff374bb0b26ad0ce76bc. `DeferredMetaDataRefreshContext` collects the tables touched by DDL as `(database, schema, table)` and calls `ContextManager#reloadTable` for each once the transaction ends. That reads the committed state of every affected table, and `persistTable` reconciles both directions: present in the database means the table is persisted, absent means it is dropped from meta data. **1. Implicit-commit dialects** Reloading committed state makes the outcome independent of how the backend treats DDL, so the implementation does not branch on dialect and no dialect capability is introduced. A rollback reloads the affected tables: - MySQL `BEGIN; CREATE TABLE t; ROLLBACK;` reloads `t`, finds it present because the server committed it implicitly, and persists it. - PostgreSQL `BEGIN; CREATE TABLE t; ROLLBACK;` reloads `t`, finds it absent, and leaves meta data unchanged. Regression coverage is `MySQLDDLMetaDataRefreshTestCase`, an E2E case asserting that a column added inside a transaction and then rolled back is present in meta data on MySQL. It is an E2E rather than a unit test because the behaviour under test is the MySQL server's implicit commit, which needs a real MySQL backend to demonstrate. `ProxyBackendTransactionManagerTest` covers the mechanism, asserting that a rollback reloads and does so after the underlying rollback. **2. Replaying statement-local refreshers** Statements are not replayed, so a refresher cannot run against a table name that a later statement in the same transaction removed. `ALTER TABLE t RENAME TO u` contributes both names, because `AlterTableStatement#getTables` includes the rename target, so the reload drops `t` and persists `u`. `CREATE TABLE t; DROP TABLE t;` reloads `t`, finds it absent, and drops it. `ContextManager#reloadTable` logs rather than propagates `SQLException`, so a reload problem does not surface as a commit error after the physical commit has succeeded. Savepoint tracking is not required, because reloading final state is already correct after a partial rollback. **Verification** - `./mvnw -pl proxy/backend/core,database/connector/dialect/postgresql test` - 592 tests, 0 failures. - Transaction E2E on `mysql:5.7` - passed, including the new MySQL case. - Transaction E2E on `postgres:12-alpine` - passed. - `spotless:check` and `checkstyle:check -Pcheck` across the three changed modules - 0 violations; `apache-rat:check -Pcheck` - passed. -- 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]
