jiangxt2 commented on code in PR #12105:
URL: https://github.com/apache/gravitino/pull/12105#discussion_r3670500163
##########
spark-connector/spark-common/src/main/java/org/apache/gravitino/spark/connector/SparkTypeConverter.java:
##########
@@ -192,6 +192,11 @@ public DataType toSparkType(Type gravitinoType) {
return DataTypes.createStructType(fields);
} else if (gravitinoType instanceof Types.NullType) {
return DataTypes.NullType;
+ } else if (gravitinoType instanceof Types.ExternalType) {
+ // ExternalType represents types with no Gravitino-native mapping (e.g.
ClickHouse
+ // IPv4/IPv6, Doris LARGEINT/BITMAP, Glue unknown types). Map to
StringType so that
+ // tables containing these columns remain loadable in Spark. Users can
CAST as needed.
+ return DataTypes.StringType;
Review Comment:
@mchades Thanks for the thorough analysis — you are right. I traced the
`JDBCTableCatalog.loadTable()` → `JDBCRDD.resolveTable()` →
`JdbcUtils.getSchema()` chain and confirmed that Spark JDBC independently
resolves types from `ResultSetMetaData` with dialect-specific overrides. For
example, `BLOB → BinaryType` and `ENUM → StringType` are correctly resolved by
Spark JDBC without any Gravitino involvement.
I will update the approach: instead of a global `ExternalType → StringType`
mapping in `toSparkType()`, I will leverage `jdbcTable.schema()` (already
available in `SparkJdbcTable` constructor) to fall back to the JDBC-resolved
type when Gravitino type is `ExternalType`. If no matching field can be found,
fail explicitly. I will also add IT coverage for both `ENUM → StringType` and
`BLOB → BinaryType` paths.
Will push the update once ready. Also curious about @diqiu50 thoughts on
this direction.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
