[
https://issues.apache.org/jira/browse/FLINK-37962?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gustavo de Morais updated FLINK-37962:
--------------------------------------
Description:
RelTimeIndicatorConverter traverses a RelNode tree and converts fields
TimeIndicatorRelDataType type. If a time attribute is accessed for a
calculation, it will be materialized.
For regular joins, we take a conservative and safe approach and materialize any
time attributes from the input streams. The user must then explicitly define a
new time attribute if they need one. We can do the same for a MultiJoin.
There's a TODO in RelTimeIndicatorConverter and there's also multiple checks in
the matches function of StreamPhysicalMultiJoinRule that might have to be
revisited. It's also good to check if multiJoin.getJoinFilter() is working as
expected and returning all join conditions/filters.
was:
RelTimeIndicatorConverter traverses a RelNode tree and converts fields
TimeIndicatorRelDataType type. If a time attribute is accessed for a
calculation, it will be materialized.
For regular joins, we take a conservative and safe approach and materialize any
time attributes from the input streams. The user must then explicitly define a
new time attribute if they need one. We can do the same for a MultiJoin.
There's a TODO in RelTimeIndicatorConverter and there's also a check in the
matches function of StreamPhysicalMultiJoinRule
> Implement visitMultiJoin for RelTimeIndicatorConverter
> ------------------------------------------------------
>
> Key: FLINK-37962
> URL: https://issues.apache.org/jira/browse/FLINK-37962
> Project: Flink
> Issue Type: Sub-task
> Reporter: Gustavo de Morais
> Priority: Major
>
> RelTimeIndicatorConverter traverses a RelNode tree and converts fields
> TimeIndicatorRelDataType type. If a time attribute is accessed for a
> calculation, it will be materialized.
> For regular joins, we take a conservative and safe approach and materialize
> any time attributes from the input streams. The user must then explicitly
> define a new time attribute if they need one. We can do the same for a
> MultiJoin.
>
> There's a TODO in RelTimeIndicatorConverter and there's also multiple checks
> in the matches function of StreamPhysicalMultiJoinRule that might have to be
> revisited. It's also good to check if multiJoin.getJoinFilter() is working as
> expected and returning all join conditions/filters.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
