fhan688 commented on issue #19286: URL: https://github.com/apache/hudi/issues/19286#issuecomment-4967967191
> For 0.x table timeline, the completion time is of an instant is its request time or instant time, the semantics are backward compatible. Agreed, and thanks — this is the right framing. You're correct that for a LAYOUT_VERSION_1 timeline an instant's completion time is its instant (request) time, and the semantics are backward compatible. In fact the V1 view already reflects this: load() maps requestedTime → completionTime, and getCompletionTime returns the begin time for archived/short instants. So instead of the current parallel getInstantTimes implementation in CompletionTimeQueryViewV1, I'll refactor PR1 to reuse the shared range logic driven by "completion time = instant time" for V1, letting V1 fall out as a special case rather than a separate code path. This removes the duplicated range/OPEN-CLOSED/resume handling and shrinks the regression surface. One boundary I'll keep and call out explicitly: V1 intentionally does not load the archived timeline, so for archived instants the completion time falls back to the instant time (which is exactly the equivalence you describe). I'll update the umbrella/PR wording accordingly (dropping the "have no completion time" phrasing in favor of "completion time = instant time"). Will push the refactor shortly. -- 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]
