TheR1sing3un commented on code in PR #14366:
URL: https://github.com/apache/hudi/pull/14366#discussion_r2567173137
##########
hudi-common/src/main/java/org/apache/hudi/common/table/timeline/LSMTimeline.java:
##########
@@ -140,9 +140,9 @@ public static Schema
getReadSchema(HoodieArchivedTimeline.LoadMode loadMode) {
* Returns whether the given file is located in the filter.
*/
public static boolean isFileInRange(HoodieArchivedTimeline.TimeRangeFilter
filter, String fileName) {
- String minInstant = getMinInstantTime(fileName);
- String maxInstant = getMaxInstantTime(fileName);
- return filter.isInRange(minInstant) || filter.isInRange(maxInstant);
+ HoodieArchivedTimeline.TimeRangeFilter dataFileRange = new
HoodieArchivedTimeline.ClosedClosedTimeRangeFilter(
+ getMinInstantTime(fileName), getMaxInstantTime(fileName));
+ return filter.intersects(dataFileRange);
Review Comment:
> nice catch~, it looks like there is only one corner case that is the range
in `TimeRangeFilter` is within one archived file, we can just simplify the
check by add condition:
>
> ```java
> filter.isInRange(minInstant) || filter.isInRange(maxInstant) ||
filter.startTs >= minInstant && filter.endTs <= maxInstant;
> ```
>
> The `filter.endTs` could be null though.
Yes, this is the most direct way to fix it.
However, I want to also refactor the logic of this part to enhance
robustness. Using the method of the filter itself for judgment might have
better maintainability. Of course, if you think it can be simply fixed here, I
also agree~
--
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]
