apache/seatunnel · error · org.apache.seatunnel.common.exception.SeaTunnelRuntimeException

COMMON-17

COMMON-17

Error message

'<identifier>' unsupported convert type '<dataType>' of '<field>' to SeaTunnel data type.

What it means

This error is thrown by DmdbTypeConverter.convert() when mapping a DM (Dameng) database column type to a SeaTunnel data type. The converter resolves each known DM JDBC type in a switch statement; if the column's reported type is not one of the supported cases (BIT, TINYINT, BYTE, ints, DECIMAL, VARCHAR, DATETIME variants, etc.), control reaches the default branch and CommonError.convertToSeaTunnelTypeError is raised. It carries the database identifier (DAMENG), the raw DM type name, and the column name so the user can identify the offending column.

Source

Thrown at seatunnel-connectors-v2/connector-jdbc/src/main/java/org/apache/seatunnel/connectors/seatunnel/jdbc/internal/dialect/dm/DmdbTypeConverter.java:320

                    builder.sourceType(DM_DATETIME);
                } else {
                    builder.sourceType(String.format("%s(%s)", DM_DATETIME, typeDefine.getScale()));
                }
                builder.dataType(LocalTimeType.LOCAL_DATE_TIME_TYPE);
                builder.scale(typeDefine.getScale());
                break;
            case DM_DATETIME_WITH_TIME_ZONE:
                if (typeDefine.getScale() == null) {
                    builder.sourceType(DM_DATETIME_WITH_TIME_ZONE);
                } else {
                    builder.sourceType(
                            String.format("DATETIME(%s) WITH TIME ZONE", typeDefine.getScale()));
                }
                builder.dataType(LocalTimeType.OFFSET_DATE_TIME_TYPE);
                builder.scale(typeDefine.getScale());
                break;
            default:
                throw CommonError.convertToSeaTunnelTypeError(
                        DatabaseIdentifier.DAMENG, typeDefine.getDataType(), typeDefine.getName());
        }
        return builder.build();
    }

    @Override
    public BasicTypeDefine reconvert(Column column) {
        BasicTypeDefine.BasicTypeDefineBuilder builder =
                BasicTypeDefine.builder()
                        .name(column.getName())
                        .nullable(column.isNullable())
                        .comment(column.getComment())
                        .defaultValue(column.getDefaultValue());
        switch (column.getDataType().getSqlType()) {
            case BOOLEAN:
                builder.columnType(DM_BIT);
                builder.dataType(DM_BIT);
                break;

View on GitHub (pinned to cf67b549a7)

Solutions

  1. Identify the offending column from the error message ('<field>') and exclude it from the sync (e.g. use column_list / query to select only supported columns, or cast it in a SQL query: SELECT CAST(col AS VARCHAR) ...).
  2. Cast unsupported columns to a supported DM type in your source SQL so the mapper resolves them (e.g. cast spatial types to VARCHAR, LOBs to VARCHAR/BINARY equivalents the dialect handles).
  3. Upgrade SeaTunnel to the latest version — the DM dialect gains new type mappings over time.
  4. If the type must be synced natively, extend DmdbTypeConverter: add a case for the DM type in the switch and map it to the appropriate SeaTunnel type, then contribute the change upstream.

Example fix

// before: table has unsupported column
source {
  Jdbc {
    url = "jdbc:dm://host:5236"
    table_path = "schema.table"  // contains GEOMETRY col
  }
}
// after: select/cast only supported columns
source {
  Jdbc {
    url = "jdbc:dm://host:5236"
    query = "SELECT id, name, CAST(geom AS VARCHAR) AS geom FROM schema.table"
  }
}
Defensive patterns

Strategy: validation

Validate before calling

// Before running the sync, inspect the DM table schema and check each column type
// against the types DmdbTypeConverter supports (numeric, VARCHAR, DATETIME variants...).
try (ResultSet rs = stmt.executeQuery(
        "SELECT COLUMN_NAME, DATA_TYPE FROM ALL_TAB_COLUMNS WHERE TABLE_NAME = 'MY_TABLE'")) {
    Set<String> supported = Set.of("BIT","TINYINT","SMALLINT","INT","BIGINT","DECIMAL",
            "CHAR","VARCHAR","DATE","TIME","DATETIME","TIMESTAMP");
    while (rs.next()) {
        String t = rs.getString("DATA_TYPE").toUpperCase();
        if (!supported.contains(t))
            throw new IllegalStateException("Unsupported DM column " + rs.getString("COLUMN_NAME") + " type " + t);
    }
}

Type guard

// Java: guard the column type before conversion
static boolean isSupportedDmType(String dmType) {
    return dmType != null && SUPPORTED_DM_TYPES.contains(dmType.trim().toUpperCase());
}

Try / catch

try {
    catalogTable = source.getCatalogTable();
} catch (SeaTunnelRuntimeException e) {
    if (e.getMessage().contains("COMMON-17")) {
        // log offending field name from message, fall back to explicit column list / cast query
        throw new IllegalArgumentException("Exclude or cast the unsupported DM column reported by COMMON-17", e);
    }
    throw e;
}

Prevention

When it happens

Trigger: Reading from a Dameng database via the JDBC source when the table contains a column whose DM type is not handled by DmdbTypeConverter's switch — e.g. spatial/geometry types, BLOB/CLOB large-object types, custom user-defined types, or newer DM type codes introduced in a DM server version newer than the connector supports. Occurs during schema/catalog resolution (catalog table lookup or split enumeration) before any data is read.

Common situations: Syncing a DM table that includes TIMESTAMP WITH TIME ZONE variants beyond the handled DATETIME WITH TIME ZONE forms, or GIS/TEXT/IMAGE columns. Also common after upgrading the DM server, where new built-in type codes appear that the pinned connector version's dialect does not recognize.

Related errors


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