terrymanu commented on issue #36337:
URL:
https://github.com/apache/shardingsphere/issues/36337#issuecomment-3585277760
## Problem Understanding
- On 5.3, the same set of physical tables goods_0/goods_1 is mapped to
multiple virtual/logic tables, each with its own key generator. Calling
ShardingschemaMedaDataDecidor.getLogicTableMetaDataMap returns only the first
logic table, so later logic tables cannot
generate primary keys and fail.
## Root Cause
- ShardingSphere is designed for a one-to-one mapping between a logic
table and its physical tables. Metadata and key-generation configuration are
built on that assumption. In
features/sharding/core/src/main/java/org/apache/shardingsphere/sharding/rule/attribute/
ShardingDataNodeRuleAttribute.java (findLogicTableByActualTable), the
first logic table that contains the actual table is returned and subsequent
ones are ignored. With multiple logic tables pointing to the same physical
tables, only the first gets metadata/key
generator, which is expected given the unsupported configuration.
## Problem Analysis
- During metadata loading, an “actual table -> logic table” mapping is
built as unique, and key generators are tied to the logic table. Reusing the
same physical tables across multiple logic tables causes later mappings to be
overwritten/ignored, so their key generators
never apply. The official sharding rule configuration assumes a single
logic table per physical table set (ShardingSphere-JDBC sharding rule config:
https://shardingsphere.apache.org/document/current/en/user-manual/shardingsphere-jdbc/configuration/rules/sharding/),
so this setup violates the supported usage.
## Conclusion
- This is a configuration/usage issue rather than a ShardingSphere bug.
Please keep one logic table per physical table set. If you need multiple names,
consider handling aliases at the application layer or via database views,
rather than configuring multiple logic
tables for the same physical tables in ShardingSphere.
--
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]
