terrymanu commented on issue #37970:
URL:
https://github.com/apache/shardingsphere/issues/37970#issuecomment-3860086224
Problem understanding
- On 5.5.2 ShardingSphere-JDBC, two sharding rules (t_user, im_user) both
point to physical tables named user across different databases (user0/1,
im0/1). Query select * from im_user ... throws TableNotFoundException during
SQL binding.
Root cause
- Metadata renaming looks up by physical table name only and returns the
first match (ShardingRule.findShardingTableByActualTable,
features/sharding/core/src/main/java/org/apache/shardingsphere/sharding/rule/ShardingRule.java:293-306).
- ShardingTableNameReviser then rewrites every physical table named user
to that first logical table (typically t_user), and
SchemaTableMetaDataAggregator keeps only one entry.
- As a result, im_user metadata never lands in ShardingSphereSchema;
SimpleTableSegmentBinder checks schema.containsTable("im_user") and raises
TableNotFoundException
(infra/binder/core/src/main/java/org/apache/shardingsphere/infra/binder/engine/segment/dml/from/type/
SimpleTableSegmentBinder.java:174-186).
Analysis
- The system assumes a one-to-one mapping from physical table name to
logical table name. Configuration reuses the same physical table name user for
two logical tables, so the second logical table is shadowed during metadata
aggregation.
- If each logical table has unique actual table names, metadata loading
and validation pass; with shared physical names, metadata clashes before
routing.
Conclusion
- This is a configuration-induced metadata name collision, not a missing
storage table. Align with ShardingSphere’s convention: ensure different logical
tables map to distinct actual table names (e.g., im$->{0..1}.im_user vs
user$->{0..1}.user).
--
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]
