github-actions[bot] commented on code in PR #69163:
URL: https://github.com/apache/doris/pull/69163#discussion_r4309758037
##########
fe/fe-core/src/main/java/org/apache/doris/datasource/hudi/HudiUtils.java:
##########
@@ -183,7 +183,8 @@ public static Type fromAvroHudiTypeToDorisType(Schema
avroSchema) {
case DOUBLE:
return Type.DOUBLE;
case STRING:
- return Type.STRING;
+ // Avro UUID is logical metadata over STRING, not an ordinary
text column.
+ return logicalType != null &&
"uuid".equals(logicalType.getName()) ? Type.UUID : Type.STRING;
Review Comment:
[P2] Apply UUID mapping after Hudi schema normalization
For a Hudi table with an Avro STRING field annotated `uuid`,
`HiveMetaStoreClientHelper.getHudiTableSchema` first converts the schema to
`InternalSchema`, and `HMSExternalTable.initHudiSchema` converts it back before
calling this method. The pinned Hudi 1.0.2
[converter](https://github.com/apache/hudi/blob/release-1.0.2/hudi-common/src/main/java/org/apache/hudi/internal/schema/convert/AvroInternalSchemaConverter.java#L516-L521)
reconstructs UUID as annotated `FIXED(16)`, so this new STRING-only check is
bypassed and `handleFixedOrBytesType` still returns `Type.STRING`. Actual
catalogs therefore continue exposing these columns, including nested UUIDs, as
TEXT; the advertised native Hudi UUID mapping never takes effect. Handle the
normalized UUID representation with matching scanner transport, and cover the
schema round trip instead of only passing raw Avro STRING directly to this
helper.
--
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]