You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@calcite.apache.org by "Ruben Q L (Jira)" <ji...@apache.org> on 2019/12/12 11:06:00 UTC

[jira] [Comment Edited] (CALCITE-3598) ClassCastException in MaterializationTest testJoinMaterialization8 and testJoinMaterialization9

    [ 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:05 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 tries to cast a Comparator into String (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.


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 (which does not make much sense, but at least does not throw any exception); whereas the nestedLoopJoin version tries to cast a Comparator into String (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.

> 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 unveil 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)