What causes "Found different types for sharding value '%s'." in apache/shardingsphere?

Make every predicate on the sharding column use the same type as the column definition (cast literals/parameters, e.g. WHERE order_id = '101' consistently).

apache/shardingsphere · error · ShardingValueDataTypeException

21

21

Error message

Found different types for sharding value '%s'.

What it means

ShardingValueDataTypeException ('Found different types for sharding value') is thrown by WhereClauseShardingConditionEngine when merging multiple ShardingConditionValues for the same hash column fails with ClassCastException. If a column has predicates whose literal/parameter types are mutually incompatible (e.g. one Integer and one String for the same sharding column), the merge in mergeShardingConditionValues cannot produce one comparable value and the catch block converts the failure into this diagnostic exception naming the column.

Source

Thrown at features/sharding/core/src/main/java/org/apache/shardingsphere/sharding/route/engine/condition/engine/WhereClauseShardingConditionEngine.java:145

                    continue;
                }
                result.computeIfAbsent(column, unused -> new LinkedList<>()).add(shardingConditionValue.get());
            }
        }
        return result;
    }
    
    private ShardingCondition createShardingCondition(final Map<HashColumn, Collection<ShardingConditionValue>> shardingConditionValues) {
        ShardingCondition result = new ShardingCondition();
        for (Entry<HashColumn, Collection<ShardingConditionValue>> entry : shardingConditionValues.entrySet()) {
            try {
                ShardingConditionValue shardingConditionValue = mergeShardingConditionValues(entry.getKey(), entry.getValue());
                if (shardingConditionValue instanceof AlwaysFalseShardingConditionValue) {
                    return new AlwaysFalseShardingCondition();
                }
                result.getValues().add(shardingConditionValue);
            } catch (final ClassCastException ignored) {
                throw new ShardingValueDataTypeException(entry.getKey());
            }
        }
        return result;
    }
    
    @SuppressWarnings({"unchecked", "rawtypes"})
    private ShardingConditionValue mergeShardingConditionValues(final HashColumn column, final Collection<ShardingConditionValue> shardingConditionValues) {
        Collection<Comparable<?>> listValue = null;
        Range<Comparable<?>> rangeValue = null;
        Set<Integer> parameterMarkerIndexes = new HashSet<>();
        for (ShardingConditionValue each : shardingConditionValues) {
            parameterMarkerIndexes.addAll(each.getParameterMarkerIndexes());
            if (each instanceof ListShardingConditionValue) {
                listValue = mergeListShardingValues(column, ((ListShardingConditionValue) each).getValues(), listValue);
                if (listValue.isEmpty()) {
                    return new AlwaysFalseShardingConditionValue();
                }
            } else if (each instanceof RangeShardingConditionValue) {

View on GitHub (pinned to e952770a21)

Solutions

Make every predicate on the sharding column use the same type as the column definition (cast literals/parameters, e.g. WHERE order_id = '101' consistently).
Fix ORM mappings so the same bind parameter type is used for the sharding column everywhere in the statement.
If the types are legitimately different predicates, move the non-sharding-key-condition to another column or drop it.

Example fix

-- before: mixed types on sharding column order_id (INT)
SELECT * FROM t_order WHERE order_id = 101 OR order_id = '102';

-- after: consistent typing
SELECT * FROM t_order WHERE order_id IN (101, 102);

Defensive patterns

Strategy: validation

Validate before calling

// Normalize predicate types on the sharding column before building SQL
int expectedJdbcType = Types.INTEGER; // matches column/rule definition
for (Param p : params) {
    if (p.column.equals("order_id") && !isCompatible(p.value.getClass(), expectedJdbcType)) {
        p.value = normalize(p.value, expectedJdbcType); // e.g. Integer.parseInt(value.toString())
    }
}

Try / catch

try {
    rs = ps.executeQuery();
} catch (final ShardingValueDataTypeException ex) {
    // ex names the offending column; rebind that column's parameters with a single type and retry
}

Prevention

Declare one Java type for each sharding column and enforce it at the repository layer.
Use typed setters (setInt/setLong/setString) instead of setObject with varying types.
Add unit tests asserting bind types equal the sharding column type.

When it happens

Trigger: A WHERE clause with two conditions on the same sharding column of incompatible Java types, e.g. WHERE order_id = 101 AND order_id = 'abc', or prepared-statement parameters bound with mixed types for the same column; also in-list plus range merges whose element types clash.

Common situations: String/numeric type drift between application and schema (VARCHAR sharding column compared to numbers), ORMs binding different parameter types for the same column in one statement, or dialect differences where literals parse to different types.

Related errors

AI-assisted analysis of apache/shardingsphere@e952770a21 (2026-08-14). Data as JSON: /api/errors/cef8f7e9bc3a9f7f. Report an issue: GitHub.