Re: [I] ShardingSphere fails to apply multiple custom sharding algorithms correctly, always uses the first defined algorithm in configuration [shardingsphere]

["terrymanu (via GitHub)" <gi...@apache.org>]

terrymanu commented on issue #36147:
URL: https://github.com/apache/shardingsphere/issues/36147#issuecomment-3677712258

   ##  Problem Understanding:
   
     - On ShardingSphere-JDBC 5.5.1 you configured two CLASS_BASED custom StandardShardingAlgorithms (year and month). Each logical table should use its own algorithm, but at runtime both tables appear to use the first algorithm.
   
   ##  Root Cause
   
     - Framework code does not favor the first entry: algorithms are bound by shardingAlgorithmName via a map, not by order. CLASS_BASED creates a separate instance per config, so the likely causes are config not actually loaded/overridden, or custom algorithm logic/static state making both behave the same.
   
   ##  Problem Analysis
   
     - ShardingRule loads shardingAlgorithms into a map by name (features/sharding/core/src/main/java/org/apache/shardingsphere/sharding/rule/ShardingRule.java:120-126); routing looks up by name, not by order.
     - CLASS_BASED builds independent instances with their own props (features/sharding/core/src/main/java/org/apache/shardingsphere/sharding/algorithm/sharding/classbased/ClassBasedShardingAlgorithm.java:68-89 and Factory); there’s no logic to overwrite the second with
       the first.
     - If both tables act the same, common causes are: the effective YAML is not the intended one (e.g., not loaded or overridden); a typo/structure issue causes both tables to reference the same shardingAlgorithmName; or custom algorithm code uses static/shared state or returns the same result so it looks like one algorithm.
   
   ##  Problem Conclusion
   
     - With current info it’s not yet a confirmed ShardingSphere bug. Please share: (1) the full effective config file (datasource + rules) used at runtime; (2) full code of both custom algorithms, especially init and routing logic, and whether static state exists; (3) the SQL that reproduces the issue with expected vs actual routed targets; (4) startup or debug logs showing algorithm registration/routing (enable sharding-sphere-sql logs). This will allow deeper pinpointing.


-- 
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: notifications-unsubscribe@shardingsphere.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org