UPDATE assigning sharding column with different identifier case fails with MismatchedInlineShardingAlgorithmExpressionAndColumnException

Bug Report

Which version of ShardingSphere did you use?

master @ 101c3d56ccd

Which project did you use? ShardingSphere-JDBC or ShardingSphere-Proxy?

Both

Expected behavior

UPDATE ... SET ACCOUNT_ID = 1 with configured sharding column account_id is accepted when the value keeps the row on the same shard, exactly like SET account_id = 1.

Actual behavior

MismatchedInlineShardingAlgorithmExpressionAndColumnException: Inline sharding algorithms expression 't_account_${account_id % 2}' and sharding column 'ACCOUNT_ID' do not match.

Reason analyze (If you can)

ShardingRouteContextCheckUtils.createShardingConditions() (features/sharding/core, line 108-111) calls ShardingRule.findShardingColumn(), which matches case-insensitively and returns the configured column name, but discards that result and builds the ListShardingConditionValue from the raw SQL identifier. InlineShardingAlgorithm.doSharding() then checks algorithmExpression.contains(columnName) case-sensitively. The sibling WhereClauseShardingConditionEngine and InsertClauseShardingConditionEngine already use the returned configured name.

Steps to reproduce the behavior, such as: SQL to execute, sharding rule configuration, when exception occur etc.

1. Table t_account, actual data nodes ds_0.t_account_${0..1}, standard table strategy on account_id with INLINE expression t_account_${account_id % 2}.
2. UPDATE t_account SET ACCOUNT_ID = 1, status = 1 WHERE account_id = 1; -> exception; the lower-case SET account_id = 1 form succeeds.

Example codes for reproduce this issue (such as a github link).

N/A