thswlsqls opened a new issue, #39149:
URL: https://github.com/apache/shardingsphere/issues/39149
## Bug Report
### Which version of ShardingSphere did you use?
master @ cb50781bc2a
### Which project did you use? ShardingSphere-JDBC or ShardingSphere-Proxy?
N/A (kernel-level, broadcast rule attribute)
### Expected behavior
`BroadcastDataNodeRuleAttribute.getDataNodesByTableName(String)` returns the
broadcast table data nodes regardless of the table name case, since the
table-to-data-node map is keyed by lower-cased table names.
### Actual behavior
Calling `getDataNodesByTableName` with a table name whose case differs from
the registered logic table (e.g. `FOO_TBL` for `foo_tbl`) returns an empty
list, because the lookup uses the raw argument as the map key.
### Reason analyze (If you can)
`BroadcastDataNodeRuleAttribute.getDataNodesByTableName()` (line 54) looks
up by the raw `tableName`, but the constructor keys `tableDataNodes` with
`Collectors.toMap(String::toLowerCase, ...)`. The three sibling methods
(`findFirstActualTable`, `findLogicTableByActualTable`,
`findActualTableByCatalog`) all normalize with `.toLowerCase()` before lookup;
this one omits it.
### Steps to reproduce the behavior, such as: SQL to execute, sharding rule
configuration, when exception occur etc.
Construct `new BroadcastDataNodeRuleAttribute(Arrays.asList("foo_ds",
"bar_ds"), Arrays.asList("foo_tbl", "bar_tbl"))`, then call
`getDataNodesByTableName("FOO_TBL")`. It returns an empty list instead of the
two data nodes for `foo_tbl`.
### Example codes for reproduce this issue (such as a github link).
N/A
--
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]
