apache/seatunnel · warning
JDBC type {} ({}) not currently supported
Error message
JDBC type {} ({}) not currently supported What it means
GenericTypeConverter.convert() maps a JDBC column type definition to a SeaTunnel data type. When the java.sql.Types code is one of JAVA_OBJECT, DISTINCT, STRUCT, REF, ROWID, or any unrecognized code, no mapping is added and the converter logs this warning, falling back to an (incomplete) built row type. Data of that column will be missing or null downstream.
Source
Thrown at seatunnel-connectors-v2/connector-jdbc/src/main/java/org/apache/seatunnel/connectors/seatunnel/jdbc/internal/dialect/GenericTypeConverter.java:179
break;
case Types.TIME:
builder.dataType(LocalTimeType.LOCAL_TIME_TYPE);
builder.scale(typeDefine.getScale());
break;
case Types.TIMESTAMP:
builder.dataType(LocalTimeType.LOCAL_DATE_TIME_TYPE);
builder.scale(typeDefine.getScale());
break;
case Types.OTHER:
case Types.ARRAY:
case Types.JAVA_OBJECT:
case Types.DISTINCT:
case Types.STRUCT:
case Types.REF:
case Types.ROWID:
default:
log.warn(
"JDBC type {} ({}) not currently supported",
sqlType,
typeDefine.getNativeType());
}
return builder.build();
}
/**
* Convert {@link Column} to an external system's type definition.
*
* @param column
* @return
*/
@Override
public BasicTypeDefine reconvert(Column column) {
throw new UnsupportedOperationException(
String.format(
"%s (%s) type doesn't have a mapping to the SQL database column type",View on GitHub (pinned to cf67b549a7)
Solutions
- Check the log line for the offending sqlType and native type; exclude or cast that column in the SQL query (e.g. CAST(col AS TEXT))
- Define an explicit user-defined type mapping (table_path/column type mapping) supported by the connector
- Upgrade SeaTunnel or the dialect — newer versions often add mappings for spatial/struct types
- Transform unsupported columns on the DB side into supported primitives via a view
Example fix
// before SELECT id, shape FROM geo_table // after SELECT id, ST_AsText(shape) AS shape FROM geo_table
Defensive patterns
Strategy: validation
Validate before calling
// inspect source schema for unsupported JDBC types before the job
ResultSet cols = meta.getColumns(catalog, schema, table, null);
while (cols.next()) {
int t = cols.getInt("DATA_TYPE");
if (t == Types.STRUCT || t == Types.JAVA_OBJECT || t == Types.DISTINCT
|| t == Types.REF || t == Types.ROWID) {
throw new IllegalStateException("Unsupported column type: " + cols.getString("COLUMN_NAME"));
}
} Type guard
boolean isSupportedJdbcType(int sqlType) {
switch (sqlType) {
case Types.JAVA_OBJECT: case Types.DISTINCT: case Types.STRUCT:
case Types.REF: case Types.ROWID:
return false;
default:
return true;
}
} Prevention
- Pre-scan table DDL for OBJECT/STRUCT/spatial columns
- CAST unsupported columns in the source query or via a DB view
- Configure explicit type mappings for exotic columns
- Watch logs for this warning during catalog retrieval
When it happens
Trigger: Source table contains columns typed as JDBC STRUCT / JAVA_OBJECT / DISTINCT / REF / ROWID (e.g. Oracle OBJECT types, PostgreSQL composite/geometry in some mappings, struct columns) during catalog/table type conversion.
Common situations: Reading tables with spatial types (geometry), user-defined object types, or array/struct columns not covered by the dialect's type converter; schema obtained from DatabaseMetaData where dialect lacks a mapping.
Related errors
AI-assisted analysis of apache/seatunnel@cf67b549a7 (2026-09-10).
Data as JSON: /api/errors/91ed4109542b11d3.
Report an issue: GitHub.