You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@calcite.apache.org by "Francesco Gini (Jira)" <ji...@apache.org> on 2021/12/08 22:34:00 UTC

[jira] [Commented] (CALCITE-4905) JdbcCalc does not extend Calc

    [ https://issues.apache.org/jira/browse/CALCITE-4905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17456022#comment-17456022 ] 

Francesco Gini commented on CALCITE-4905:
-----------------------------------------

Fair enough, if it is by design then we can close the ticket. To be fair I have only seen {{RelToSqlConverter}} failing when I was experimenting with Calcite a few months ago. I think at that time I was trying to transalte a Rel tree into a tree that only had JDBC nodes. When doing so I was configuring the planner with only jdbc rules,  it might well be that I was doing something that I was not supposed to. After that I have started using the {{standard}} program and haven't actually seen the problem again. The main reason I opened the ticket is because I have seen {{EnumerableCalc}} that implements {{Calc}} and that {{RelToSqlConverter}} visits {{{}Calc{}}}.

 

I don't have a test for it and I am not sure how I could add one that makes the {{JdbcCalc}} node to appear in the plan. I searched in the code base but can't find {{JdbCalc}} references in tests. The best I could come up with is the patch attached [^test_with_failing_JdbcCalc_conversion.patch] which add a test that is a modification of {{RelToSqlConverterTest.testSargConversion}} where I manually add the {{{}JdbcCalcRule{}}}. Running the test does reproduce the problem but:
 # I am focing the problem to appear by explicitly setting the optimiser to use the {{JdbcCalc}}
 # the same test on my pr fails with a different reason. The plan produced ooks something like 

{code:java}
JdbcCalc(expr#0..7=[{inputs}], expr#8=[Sarg[[6..8), [10..12)]], expr#9=[SEARCH($t0, $t8)], proj#0..7=[{exprs}], $condition=[$t9], expr#0..7=[{inputs}], expr#8=[Sarg[[6..8), [10..12)]], expr#9=[SEARCH($t0, $t8)], proj#0..7=[{exprs}], $condition=[$t9])
  HepRelVertex(subset=[rel#8:RelSubset#0.JDBC.mysql.[0]]) {code}
which I believe it means I am not really setting up the test properly.

 

I still need to learn quite a lot about Calcite. could be that an explanation of the fact that I don't see {{JdbcCalc}} appearing in plans is that {{Programs.standard returns}}
{code:java}
return sequence(subQuery(metadataProvider),
    new DecorrelateProgram(),
    new TrimFieldsProgram(),
    program1,

    // Second planner pass to do physical "tweaks". This the first time
    // that EnumerableCalcRel is introduced.
    calc(metadataProvider)); {code}
and calc appear just at a later point on the plan (in {{{}calc{}}}), after the {{Jdbc}} rules have already been applied?

> JdbcCalc does not extend Calc
> -----------------------------
>
>                 Key: CALCITE-4905
>                 URL: https://issues.apache.org/jira/browse/CALCITE-4905
>             Project: Calcite
>          Issue Type: Bug
>          Components: jdbc-adapter
>    Affects Versions: 1.28.0
>            Reporter: Francesco Gini
>            Assignee: Francesco Gini
>            Priority: Major
>              Labels: pull-request-available
>             Fix For: 1.29.0
>
>         Attachments: test_with_failing_JdbcCalc_conversion.patch
>
>
> {{JdbcCalc}} class does not implement Calc. Failing to do that means that
> {{RelToSqlConverter}} cannot translate a plan with {{JdbcCalc}} into sql because {{RelToSqlConverter}} expects
> {code:java}
>  public Result visit(Calc e){code}



--
This message was sent by Atlassian Jira
(v8.20.1#820001)