apache/shardingsphere · error · SQLFeatureNotSupportedException

getPrecision

Error message

getPrecision

What it means

SQLFeatureNotSupportedException thrown by AbstractUnsupportedOperationParameterMetaData.getPrecision(int). ShardingSphere prepares SQL only in its own parser for routing; it does not push PREPARE to a backend, so the precision of a '?' parameter is unknown and this final method always throws. Only getParameterCount() is implemented by the subclass.

Source

Thrown at jdbc/src/main/java/org/apache/shardingsphere/driver/jdbc/unsupported/AbstractUnsupportedOperationParameterMetaData.java:43

/**
 * Unsupported {@code ParameterMetaData} methods.
 */
public abstract class AbstractUnsupportedOperationParameterMetaData extends WrapperAdapter implements ParameterMetaData {
    
    @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

View on GitHub (pinned to e952770a21)

Solutions

  1. Validate precision in application code or against DatabaseMetaData.getColumns of the real table, not against ParameterMetaData.
  2. Catch SQLFeatureNotSupportedException and skip precision validation for ShardingSphere datasources (let the backend enforce it).
  3. Route the validation query through a plain DataSource pointing at one shard if metadata accuracy is mandatory.

Example fix

// before
if (value.precision() > pmd.getPrecision(idx)) throw new IllegalArgumentException(...);

// after
if (value.precision() > columnPrecisionFromTableMetadata) throw new IllegalArgumentException(...);
Defensive patterns

Strategy: validation

Validate before calling

// Pre-check driver capability instead of probing getPrecision on ShardingSphere
String driver = conn.getMetaData().getDriverName();
if (!driver.toLowerCase().contains("shardingsphere")) { maxPrecision = pmd.getPrecision(1); } else { maxPrecision = Integer.MAX_VALUE; }

Try / catch

try { precision = pmd.getPrecision(1); } catch (final SQLFeatureNotSupportedException e) { precision = -1; /* unknown, skip client check */ }

Prevention

When it happens

Trigger: ps.getParameterMetaData().getPrecision(i) on a ShardingSphere PreparedStatement. Commonly invoked by frameworks validating DECIMAL/NUMERIC bind values, e.g. BigDecimal formatting layers and some legacy EJB/JDO-style mappers.

Common situations: Financial/reporting apps that pre-validate BigDecimal scale/precision against ParameterMetaData before insert; migration from a driver that answered getPrecision (DB2, SQLServer, MySQL with useServerPrepStmts) to jdbc:shardingsphere:.

Related errors


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