weiqingy commented on code in PR #28796:
URL: https://github.com/apache/flink/pull/28796#discussion_r3653420516
##########
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:
Thanks @RocMarshal for the review and the +1.
Good observation. EarlyFire is a small planner-internal holder for the
result of extractEarlyFire(), effectively Java's stand-in for a tuple, because
that method resolves the effective time mode and performs the domain validation
together. It is unpacked once at its single call site into the two values
propagated downstream.
My reason for continuing to propagate them separately is the eventual
ExecNode boundary, which is also the compiled-plan serde boundary.
earlyFireDelay and earlyFireTimeMode are persisted as two optional scalar
properties on StreamExecIntervalJoin. Keeping them flat follows existing
ExecNode patterns for small optional properties and avoids adding a nullable
nested spec to the plan format for two values. IntervalJoinSpec is nested, but
it represents an always-present group of interval-join properties, whereas
early fire itself is optional.
Regarding whether more configuration will join these values: the next PR
adds a target option, but it remains a rule-level applicability gate. It
determines whether the hint applies to this operator kind and is discarded
after extraction, so the propagated state remains exactly delay plus timeMode.
My preference is therefore to keep the two flat fields for now. If another
parameter eventually needs to reach the operator, promoting them to a small
shared spec would make more sense. If you prefer establishing the wrapper now,
though, I'm happy to change 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]
