RocMarshal commented on code in PR #28796:
URL: https://github.com/apache/flink/pull/28796#discussion_r3652616507
##########
flink-table/flink-table-planner/src/main/java/org/apache/flink/table/planner/plan/rules/physical/stream/StreamPhysicalIntervalJoinRule.java:
##########
@@ -133,6 +142,8 @@ public FlinkRelNode transform(
RelTraitSet providedTraitSet) {
Tuple2<Option<IntervalJoinSpec.WindowBounds>, Option<RexNode>> tuple2 =
extractWindowBounds(join);
+ boolean isEventTime = tuple2.f0.get().isEventTime();
+ EarlyFire earlyFire = extractEarlyFire(join.getHints(), isEventTime);
Review Comment:
anchor-A
##########
flink-table/flink-table-planner/src/main/java/org/apache/flink/table/planner/plan/rules/physical/stream/StreamPhysicalIntervalJoinRule.java:
##########
@@ -141,7 +152,53 @@ public FlinkRelNode transform(
join.getJoinType(),
join.getCondition(),
tuple2.f1.getOrElse(() ->
join.getCluster().getRexBuilder().makeLiteral(true)),
- tuple2.f0.get());
+ tuple2.f0.get(),
+ earlyFire.delay,
+ earlyFire.timeMode);
Review Comment:
At Anchor-A, the early fire parameters are now encapsulated within a
dedicated class. That said, the call sites currently split them apart for
invocation.
Given the semantics of this link and its subsequent stages, are there any
specific downsides to propagating these parameters strictly via the
EarlyFire(or EarlyFireConfig) wrapper?
Since these two parameters are almost always co-located, I’m merely
questioning the trade-off. If using EarlyFire(or EarlyFireConfig) proves
cumbersome, decoupling them is an acceptable compromise.
And I'd like to hear more ideas about it
--
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]
