apache/shardingsphere · error · SQLFeatureNotSupportedException
getScale
Error message
getScale
What it means
SQLFeatureNotSupportedException thrown by AbstractUnsupportedOperationParameterMetaData.getScale(int). ShardingSphere's driver-side prepare has no backend type info for '?' placeholders, so scale (digits after the decimal point) cannot be computed; the final override always throws. ShardingSphereParameterMetaData implements only getParameterCount().
Source
Thrown at jdbc/src/main/java/org/apache/shardingsphere/driver/jdbc/unsupported/AbstractUnsupportedOperationParameterMetaData.java:48
@Override
public final int isNullable(final int parameter) throws SQLException {
throw new SQLFeatureNotSupportedException("isNullable");
}
@Override
public final boolean isSigned(final int parameter) throws SQLException {
throw new SQLFeatureNotSupportedException("isSigned");
}
@Override
public final int getPrecision(final int parameter) throws SQLException {
throw new SQLFeatureNotSupportedException("getPrecision");
}
@Override
public final int getScale(final int parameter) throws SQLException {
throw new SQLFeatureNotSupportedException("getScale");
}
@Override
public final int getParameterType(final int parameter) throws SQLException {
throw new SQLFeatureNotSupportedException("getParameterType");
}
@Override
public final String getParameterTypeName(final int parameter) throws SQLException {
throw new SQLFeatureNotSupportedException("getParameterTypeName");
}
@Override
public final String getParameterClassName(final int parameter) throws SQLException {
throw new SQLFeatureNotSupportedException("getParameterClassName");
}
@OverrideView on GitHub (pinned to e952770a21)
Solutions
- Apply scale from the entity/table definition (e.g. JPA @Column(scale=...)) instead of ParameterMetaData.
- Let the backend database coerce or reject the value; remove the client-side getScale check.
- Catch SQLFeatureNotSupportedException around the probe and continue with the value's own scale.
Example fix
// before BigDecimal v = value.setScale(pmd.getScale(1), RoundingMode.HALF_UP); // after BigDecimal v = value.setScale(entityScale, RoundingMode.HALF_UP); // scale from your mapping
Defensive patterns
Strategy: validation
Validate before calling
int scale = (mapping != null) ? mapping.getScale() : -1; // from your own mapping; never pmd.getScale under ShardingSphere
Try / catch
try { scale = pmd.getScale(1); } catch (final SQLFeatureNotSupportedException e) { scale = -1; /* fall back to value's own scale */ } Prevention
- Take scale from JPA @Column(scale=...) or equivalent mapping
- Do not auto-adjust BigDecimal scale from ParameterMetaData
- Run metadata-dependent code on a plain DataSource
When it happens
Trigger: ps.getParameterMetaData().getScale(i) against a jdbc:shardingsphere: URL. Hit by BigDecimal setScale logic and validation code that mirrors column scale in bind parameters.
Common situations: Apps ported from drivers that support server-side prepare (MySQL Connector/J with useServerPrepStmts=true, Oracle, DB2) where getScale worked; generic DAO layers that self-adjust BigDecimal scale before binding.
Related errors
AI-assisted analysis of apache/shardingsphere@e952770a21 (2026-08-14).
Data as JSON: /api/errors/808aa141103bdf00.
Report an issue: GitHub.