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

  1. Check the logged sqlType and typeName to identify the offending column.
  2. Update the connector (or Databend JDBC driver) to a version that maps the type explicitly.
  3. Cast the column in your SQL query to a supported type, e.g. CAST(col AS VARCHAR) or CAST(col AS BINARY).
  4. 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

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


AI-assisted analysis of apache/seatunnel@cf67b549a7 (2026-09-10). Data as JSON: /api/errors/bc04e1df87258e24. Report an issue: GitHub.