yihua commented on code in PR #18126:
URL: https://github.com/apache/hudi/pull/18126#discussion_r2789614726
##########
hudi-spark-datasource/hudi-spark-common/src/main/scala/org/apache/hudi/SparkHoodieTableFileIndex.scala:
##########
@@ -134,8 +134,11 @@ class SparkHoodieTableFileIndex(spark: SparkSession,
val partitionFields: Array[StructField] =
partitionColumns.get().map(column => StructField(column, StringType))
StructType(partitionFields)
} else {
+ // Use full partition path (e.g. "nested_record.level") as the
partition column name so that
+ // data schema does not exclude a same-named top-level column (e.g.
"level") when partition
+ // path is a nested field. Otherwise partition value would overwrite
the data column on read.
val partitionFields: Array[StructField] =
partitionColumns.get().filter(column => nameFieldMap.contains(column))
- .map(column => nameFieldMap.apply(column))
+ .map(column => StructField(column,
nameFieldMap.apply(column).dataType))
Review Comment:
The fix correctly addresses the `dataSchema` exclusion problem (line
171-172), but I'm wondering if it could cause issues with partition predicate
binding at line 258: `partitionSchema.indexWhere(a.name == _.name)`. When Spark
resolves a filter like `nested_record.level = 'INFO'` against a partition
schema with field name `"nested_record.level"`, does the
`AttributeReference.name` reliably come through as `"nested_record.level"`
rather than just `"level"`? If not, `indexWhere` would return -1 and blow up.
Have you verified that partition pruning works end-to-end with this change with
L258 triggered?
--
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]
