hudi-agent commented on code in PR #19536:
URL: https://github.com/apache/hudi/pull/19536#discussion_r3759971385
##########
hudi-spark-datasource/hudi-spark-common/src/main/scala/org/apache/hudi/HoodieBaseRelation.scala:
##########
@@ -174,7 +174,17 @@ abstract class HoodieBaseRelation(val sqlContext:
SQLContext,
} getOrElse {
Try(schemaResolver.getTableSchema) match {
case Success(schema) => schema
- case Failure(e) => throw e
+ case Failure(e) =>
+ // Schema not found on the dataset, so fetching schema from HMS.
+ logWarning(s"Schema not found on the dataset for $tableName, so
fetching schema from HMS.")
+ val databaseName = metaClient.getTableConfig.getDatabaseName
Review Comment:
🤖 Nice improvement chaining the original exception on the not-found path.
One thing still open from last round: when the table *does* exist in the
catalog, we fall back to the HMS schema on any `getTableSchema` failure — not
just the empty/no-data case. If a table with real data fails resolution
transiently (IO) or after a write-path schema evolution, we'd silently read
under the (possibly stale) HMS create-schema instead of surfacing `e`. Could we
gate the fallback on the table genuinely having no resolvable schema (e.g. no
completed commits / no base files)?
<sub><i>⚠️ AI-generated; verify before applying. React 👍/👎 to flag
quality.</i></sub>
--
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]
