Hi Vasia, You did the right thing on the Flink side. This has happened with multiple rules previously; they were originally implemented using the Logical convention and till we do not use them externally, we do not hit this kind of issues. As we make Calcite more extensible, the rules are updated.
Could you file a bug as in [1] and contribute the fix? Otherwise, you can assign it to me, as you prefer. Thanks, Jesús [1] https://issues.apache.org/jira/browse/CALCITE-856 On 3/7/16, 4:10 PM, "Vasiliki Kalavri" <[email protected]> wrote: >Hello everyone, > >the JoinUnionTransposeRule is fired if one of the operands is a Union, but >inside the onMatch() method, the code checks if one of the operands is an >instance of LogicalUnion [1]*.* > >In the Apache Flink SQL implementation, we have created a logical operator >FlinkUnion for the translation of union. This operator extends Union and >thus when the JoinUnionTransposeRule matches, it throws a >ClassCastException. To avoid this, we have copied the >JoinUnionTransposeRule over to Flink and changed the check in onMatch() >method to look for an instance of Union instead. > >Obviously, this is not a good choice, since the rule code should not have >to be maintained on the Flink side. We are wondering whether this check is >a bug or whether we have misunderstood the way we are supposed to use this >rule. > >Thank you, >-Vasia. > >[1]: >https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/rel/rules/JoinUnionTransposeRule.java#L61
