terrymanu commented on issue #37711:
URL:
https://github.com/apache/shardingsphere/issues/37711#issuecomment-3737767421
Issue understanding: On ShardingSphere-JDBC 5.5.2 (MySQL) you execute CREATE
TEMPORARY TABLE tmp_sys_user AS ... via MyBatis-Plus. After the DDL,
ShardingSphere triggers metadata refresh and throws Load actual table metadata
'tmp_sys_user' failed.
Root cause: The DDL metadata refresher opens a new physical connection to
fetch table metadata and is designed for persistent tables. Session-scoped
temporary tables are only visible on the connection that created them, so the
refresher cannot see tmp_sys_user,
GenericSchemaBuilder returns empty, and the assert in
CreateTableStatementSchemaRefresher fails. This is a current limitation rather
than a bug in persistent-table handling.
Problem analysis: The flow is DDL execution →
CreateTableStatementSchemaRefresher.refresh → GenericSchemaBuilder.build to
reload table definition. Because the refresh uses a separate connection, the
temporary table is invisible, actualTableMetaData is empty, and the check
raises the exception. ShardingSphere’s metadata management tracks logical
databases against real persistent objects; session-level temporary tables are
out of scope, so they are not supported in the metadata refresh logic.
Conclusion: This behavior reflects the present design: ShardingSphere-JDBC
does not support metadata refresh for session-scoped temporary tables. Please
avoid relying on ShardingSphere to manage temporary tables. If you still see
this when everything happens on the
exact same physical connection, please share database type/version, your
rule/data source configuration, and the full ShardingSphere log stack to
confirm there are no other rule interactions.
--
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]