voonhous commented on issue #19823: URL: https://github.com/apache/hudi/issues/19823#issuecomment-5540082605
FWIU you're saying Flink has this problem too, separately from the delete log. If so, agreed, and it looks worse there: `getField` misses the nested name and `doGetOrderingValue` falls back to `OrderingValues.getDefault()` (0) instead of throwing, so event-time ordering quietly becomes last-writer-wins. The read side has the same hole, `FlinkRecordContext.getValue` returns null for a dotted path and `RecordContext.getOrderingValue` fills in the default. Nothing table-version gated about it either, the same code is on release-1.2.1-staging. Should we file it as a separate issue so it can be fixed and backported on its own, and keep this one scoped to the delete-log schema? One thing to watch on ordering: if the delete-log schema is fixed first, Flink stops throwing and starts persisting 0 into the delete log instead, which is the worse failure. So either the Flink fix goes first, or that PR keeps a fail-fast until it lands. -- 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]
