nsivabalan commented on code in PR #8422:
URL: https://github.com/apache/hudi/pull/8422#discussion_r1170103899
##########
hudi-client/hudi-client-common/src/main/java/org/apache/hudi/client/HoodieTimelineArchiver.java:
##########
@@ -475,7 +485,24 @@ private Stream<HoodieInstant> getCommitInstantsToArchive()
throws IOException {
HoodieTimeline.compareTimestamps(s.getTimestamp(),
LESSER_THAN, instantToRetain.getTimestamp()))
.orElse(true)
);
- return instantToArchiveStream.limit(commitTimeline.countInstants() -
minInstantsToKeep);
+ List<HoodieInstant> instantsToArchive =
instantToArchiveStream.limit(commitTimeline.countInstants() -
minInstantsToKeep).collect(Collectors.toList());
+ // If cleaner is based on hours, lets ensure hudi does not archive
commits yet to cleaned by the cleaner.
+ if (config.getCleanerPolicy() ==
HoodieCleaningPolicy.KEEP_LATEST_BY_HOURS && !instantsToArchive.isEmpty()) {
Review Comment:
yeah. I agree. but the guard conditions differ slightly from one policy to
another. for eg, incase of num_commits, we can validate just w/ right configs.
but if its based on hours, since archival is based on num of commits, we had to
defer this check to when we actually do the archival. I do have a follow up
patch where we will do some policy agnostic check in archival. but for this, do
you think we need to think about adding a new api in cleaner code.
--
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]
