terrymanu commented on issue #33838:
URL:
https://github.com/apache/shardingsphere/issues/33838#issuecomment-3506566991
After detailed analysis, I can confirm that Issue #33838 and Issue #36352
are the same problem, both related to the bug of INLINE sharding algorithm
validation failure.
Root Cause
The problem occurs in the
ShardingRuleChecker.validateInlineShardingAlgorithm method:
1. Flawed validation logic: Using hardcoded test value 1 to validate
complex Groovy expressions
2. Incorrect prefix calculation: Improper handling of non-numeric suffix
data source names (like ds_normal, ds_sensitive)
3. Overly strict validation: Blocking legitimate configurations, including
enumeration values and conditional expressions
Specific location in:
// ShardingRuleChecker.java:176
result = inlineShardingAlgorithm.doSharding(Collections.emptySet(),
new PreciseShardingValue<>(shardingTable.getLogicTable(),
shardingColumn, dataNodeInfo, 1));
ShardingSpherePreconditions.checkState(null == result ||
result.startsWith(dataNodeInfo.getPrefix()),
() -> new AlgorithmInitializationException(inlineShardingAlgorithm,
"inline expression of rule `%s` does not match the actual data
nodes", logicTable));
Solution
The good news is that PR #36999 has already fixed this issue. The fix
approach is to completely remove the problematic validation logic:
1. Deleted the checkInlineShardingAlgorithmsInTableRules() method
2. Deleted the validateInlineShardingAlgorithm() method
3. Removed INLINE algorithm validation calls from the check() method
This fix is reasonable because:
- Runtime sharding validation still occurs during actual execution
- Static validation at startup is not necessary and prone to misjudgment
Impact on Users
The Issue #33838 problem has been resolved in the following versions:
- PR #36999 was merged to master branch on 2025-11-04
- The fix will be included in version 5.5.3
Temporary Workarounds
Before version 5.5.3 is released, users can consider the following
temporary solutions:
1. Use numeric suffix naming for data sources:
ds_0, ds_1 instead of ds_normal, ds_sensitive
2. Use autoTables configuration:
rules:
- !SHARDING
autoTables:
logic_base_visual_release:
actualDataSources: ds_normal, ds_sensitive
shardingStrategy:
standard:
shardingColumn: f_special_mark
shardingAlgorithmName: sensitivityShardingAlgorithm
3. Wait for version 5.5.3 release
Conclusion
This is a confirmed bug that has already been fixed in the master branch.
The user's configuration is correct, and the problem lies in ShardingSphere's
overly strict validation logic. It is recommended that users wait for
version 5.5.3 release or use snapshot versions that include this fix.
--
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]
