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)