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");
}
@OverrideView on GitHub (pinned to e952770a21)
Solutions
- Validate precision in application code or against DatabaseMetaData.getColumns of the real table, not against ParameterMetaData.
- Catch SQLFeatureNotSupportedException and skip precision validation for ShardingSphere datasources (let the backend enforce it).
- 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
- Validate precision against your entity/table mapping, not ParameterMetaData
- Let the backend enforce DECIMAL precision
- Probe driver name before any per-parameter metadata call
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.