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");
    }
    
    @Override

View on GitHub (pinned to e952770a21)

Solutions

  1. Apply scale from the entity/table definition (e.g. JPA @Column(scale=...)) instead of ParameterMetaData.
  2. Let the backend database coerce or reject the value; remove the client-side getScale check.
  3. 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

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.