apache/seatunnel · warning
Unsupported SQL type: {}, type name: {}, using STRING_TYPE a
Error message
Unsupported SQL type: {}, type name: {}, using STRING_TYPE as fallback What it means
This is a warning logged by DatabendSourceReader.convertDatabendTypeToSeaTunnelType when it encounters a JDBC SQL type it does not recognize while inferring the SeaTunnel row type from a ResultSet. The library intentionally degrades gracefully: instead of failing the read, it maps the column to SeaTunnel STRING_TYPE and logs this warning. The resulting rows will carry the raw value as a string, which may lose type fidelity.
Source
Thrown at seatunnel-connectors-v2/connector-databend/src/main/java/org/apache/seatunnel/connectors/seatunnel/databend/source/DatabendSourceReader.java:295
return new DecimalType(precision > 0 ? precision : 38, scale >= 0 ? scale : 18);
case Types.DATE:
return LocalTimeType.LOCAL_DATE_TYPE;
case Types.TIME:
return LocalTimeType.LOCAL_TIME_TYPE;
case Types.TIMESTAMP:
return LocalTimeType.LOCAL_DATE_TIME_TYPE;
case Types.BINARY:
case Types.VARBINARY:
case Types.LONGVARBINARY:
case Types.BLOB:
return PrimitiveByteArrayType.INSTANCE;
default:
log.warn(
"Unsupported SQL type: {}, type name: {}, using STRING_TYPE as fallback",
sqlType,
typeName);
return BasicType.STRING_TYPE;
}
}
@Override
public void close() throws IOException {
try {
if (resultSet != null) {
resultSet.close();
}
if (statement != null) {
statement.close();
}
if (connection != null) {
connection.close();View on GitHub (pinned to cf67b549a7)
Solutions
- Check the logged sqlType and typeName to identify the offending column.
- Update the connector (or Databend JDBC driver) to a version that maps the type explicitly.
- Cast the column in your SQL query to a supported type, e.g. CAST(col AS VARCHAR) or CAST(col AS BINARY).
- If the value is fine as a string, ignore the warning; STRING fallback preserves data as text.
Example fix
// before SELECT geom FROM events // after SELECT CAST(geom AS VARCHAR) AS geom FROM events
Defensive patterns
Strategy: validation
Validate before calling
int t = resultSetMetaData.getColumnType(i);
boolean supported = t == Types.BOOLEAN || t == Types.TINYINT || t == Types.SMALLINT
|| t == Types.INTEGER || t == Types.BIGINT || t == Types.FLOAT || t == Types.DOUBLE
|| t == Types.DECIMAL || t == Types.CHAR || t == Types.VARCHAR || t == Types.LONGVARCHAR
|| t == Types.DATE || t == Types.TIME || t == Types.TIMESTAMP
|| t == Types.BINARY || t == Types.VARBINARY || t == Types.LONGVARBINARY || t == Types.BLOB;
if (!supported) { /* cast column or adjust schema */ } Type guard
// Java: narrow by SQL type before relying on the column type
if (value instanceof String) { /* safe to use STRING-typed fallback value */ } Prevention
- Cast exotic columns (VARIANT, GEOMETRY) to VARCHAR/BINARY in the source SQL.
- Keep the Databend JDBC driver and connector versions current.
- Review the row type inferred at startup against the warning logs before running production jobs.
- Test schemas with new Databend types in a dev environment first.
When it happens
Trigger: A Databend column maps to a java.sql.Types constant not covered by the switch (anything outside BIT/BOOLEAN, numeric, CHAR/VARCHAR/LONGVARCHAR, DATE/TIME/TIMESTAMP, BINARY/VARBINARY/LONGVARBINARY/BLOB). This happens during source start when inferRowTypeFromResultSet reads ResultSetMetaData.
Common situations: New or exotic Databend column types (e.g. GEOMETRY, VARIANT, unusual alias types) surfaced by a newer Databend server or a driver that reports a TINYINT/other type the converter misses; schema evolution after the connector was written.
Related errors
- Unsupported Databend type: {}, fallback to STRING type
- DRIVER_NOT_FOUND
- CONNECT_FAILED
- SQL_OPERATION_FAILED
- UNSUPPORTED_DATA_TYPE
AI-assisted analysis of apache/seatunnel@cf67b549a7 (2026-09-10).
Data as JSON: /api/errors/bc04e1df87258e24.
Report an issue: GitHub.