[
https://issues.apache.org/jira/browse/CALCITE-3598?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16994533#comment-16994533
]
Ruben Q L edited comment on CALCITE-3598 at 12/12/19 11:16 AM:
---------------------------------------------------------------
I have looked at the generated code by testJoinMaterialization8, both the
original one (with hashJoin) and the new one (after CALCITE-3535, with
nestedLoopJoin); and I think that the original one is already wrong, and maybe
it was just working by chance?
I can see that the hashJoin version performs a Comparator.toString() operation
(codeHashJoin.txt line 31), which does not make much sense, but at least does
not throw any exception; whereas the nestedLoopJoin version eventually tries to
cast a Comparator into String in EnumerableDefaults#nestedLoopJoin (which
causes the ClassCastException). I think that the issue is not related to
hashJoin or nestedLoopJoin, or the changes introduced by CALCITE-3535 or
CALCITE-3576, but rather why this Comparator-to-String operation was generated
in the first place, which I believe seems to be an error. Maybe there is an old
underlying problem somewhere, which was "hidden" so far.
The key piece of code, that we can find in booth codeHashJoin.txt and
codeNestedLoopJoin.txt, is this select:
{code}
org.apache.calcite.schema.Schemas.queryable(root,
root.getRootSchema().getSubSchema("hr"), java.lang.String.class,
"m0").asEnumerable().select(
new org.apache.calcite.linq4j.function.Function1() {
public java.util.Comparator apply(String row) {
return row.CASE_INSENSITIVE_ORDER;
}
public Object apply(Object row) {
return apply(
(String) row);
}
}
) ...
{code}
which basically selects rows of type String and transforms them into the
comparator String.CASE_INSENSITIVE_ORDER (¿?).
was (Author: rubenql):
I have looked at the generated code by testJoinMaterialization8, both the
original one (with hashJoin) and the new one (after CALCITE-3535, with
nestedLoopJoin); and I think that the original one is already wrong, and maybe
it was just working by chance?
I can see that the hashJoin version performs a Comparator.toString() operation
(codeHashJoin.txt line 31), which does not make much sense, but at least does
not throw any exception; whereas the nestedLoopJoin version eventually tries to
cast a Comparator into String in EnumerableDefaults#nestedLoopJoin (which
causes the ClassCastException). I think that the issue is not related to
hashJoin or nestedLoopJoin, or the changes introduced by CALCITE-3535 or
CALCITE-3576, but rather why this Comparator-to-String operation was generated
in the first place, which I believe seems to be an error. Maybe there is an old
underlying problem somewhere, which was "hidden" so far.
The key piece of code, that we can find in booth codeHashJoin.txt and
codeNestedLoopJoin.txt, is this select:
{code}
org.apache.calcite.schema.Schemas.queryable(root,
root.getRootSchema().getSubSchema("hr"), java.lang.String.class,
"m0").asEnumerable().select(
new org.apache.calcite.linq4j.function.Function1() {
public java.util.Comparator apply(String row) {
return row.CASE_INSENSITIVE_ORDER;
}
public Object apply(Object row) {
return apply(
(String) row);
}
}
) ...
{code}
which basically selects rows of type String and transforms them into the
comparator String.CASE_INSENSITIVE_ORDER.
> ClassCastException in MaterializationTest testJoinMaterialization8 and
> testJoinMaterialization9
> -----------------------------------------------------------------------------------------------
>
> Key: CALCITE-3598
> URL: https://issues.apache.org/jira/browse/CALCITE-3598
> Project: Calcite
> Issue Type: Bug
> Affects Versions: 1.21.0
> Reporter: Ruben Q L
> Priority: Minor
> Attachments: codeHashJoin.txt, codeNestedLoopJoin.txt
>
>
> Problem unveiled by CALCITE-3535, and also separately by CALCITE-3576.
> When CALCITE-3535 was committed, it made
> {{MaterializationTest#testJoinMaterialization8}} and
> {{MaterializationTest#testJoinMaterialization9}} change their execution plan
> from hashJoin to nestedLoopJoin. This caused an exception
> {code}
> java.lang.ClassCastException: java.lang.String$CaseInsensitiveComparator
> cannot be cast to java.lang.String
> {code}
> which seems unrelated to CALCITE-3535 (or CALCITE-3576), so the tests were
> temporarily disabled.
> The goal of this ticket is to investigate the root cause of this issue and
> re-activate both tests.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
