AmatyaAvadhanula commented on code in PR #16162:
URL: https://github.com/apache/druid/pull/16162#discussion_r1538558516
##########
server/src/main/java/org/apache/druid/segment/realtime/appenderator/SegmentsAndCommitMetadata.java:
##########
@@ -20,28 +20,50 @@
package org.apache.druid.segment.realtime.appenderator;
import com.google.common.collect.ImmutableList;
+import com.google.common.collect.ImmutableSet;
import org.apache.druid.segment.SegmentUtils;
import org.apache.druid.timeline.DataSegment;
import javax.annotation.Nullable;
import java.util.Collections;
import java.util.List;
import java.util.Objects;
+import java.util.Set;
public class SegmentsAndCommitMetadata
{
private static final SegmentsAndCommitMetadata NIL = new
SegmentsAndCommitMetadata(Collections.emptyList(), null);
private final Object commitMetadata;
private final ImmutableList<DataSegment> segments;
+ private final ImmutableSet<DataSegment> upgradedSegments;
Review Comment:
From the POV of segment handoff, the original and upgraded segments need not
be distinguished from each other.
However, there are sanity checks where we must ensure that the committed
segments are the same as the ones that were requested. Maintaining the upgraded
segments separately helps with this check.
When the check fails and segments need to be killed from deep storage, we
would also have to ensure that we do not run into errors trying to kill the
same deep storage location multiple times. While this could be done by creating
a set of load specs before every kill, I think it may be neater to maintain the
orignal and upgraded sets separately for such purposes.
--
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
