[jira] [Comment Edited] (CALCITE-2727) MV rewriting bails out incorrectly when a view does not contain any table reference

["Jesus Camacho Rodriguez (JIRA)" <ji...@apache.org>]

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

Jesus Camacho Rodriguez edited comment on CALCITE-2727 at 1/2/19 11:28 PM:
---------------------------------------------------------------------------

I have been trying to work on a test to reproduce this issue today and it is not trivial, though the error in the logic is evident. The reason is that current default implementation in Calcite will hit [this code|https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/rel/rules/AbstractMaterializedViewRule.java#L283] and continue iteration through materialized views if an operator that is not recognized is found in a MV. For instance, if a join branch uses a TABLE VALUES construct, it will go into that if clause, and it will not hit the [code|https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/rel/rules/AbstractMaterializedViewRule.java#L305] that [~cltlfcjin] is referring to. However, I assume that you may hit the issue under certain circumstances, maybe with some custom operators. [~cltlfcjin], do you have such an example for the SQL of the query and the MV? Otherwise, [~julianhyde], [~zhenw], since you both raised the concern about the test and after reading this explanation, do you think it is OK to merge given that there are no regressions in current test suite? Do you have any other ideas/suggestions? Thanks 


was (Author: jcamachorodriguez):
I have been trying to work on a test to reproduce this issue today and it is not trivial, though the error in the logic is evident. The reason is that current default implementation in Calcite will hit [this code|https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/rel/rules/AbstractMaterializedViewRule.java#L283] and continue iteration through materialized views if an operator that is not recognized is found in a MV. For instance, if a join branch uses a TABLE VALUES construct, it will go into that if clause, and it will not hit the [code|https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/rel/rules/AbstractMaterializedViewRule.java#L305] that [~cltlfcjin] is referring to. However, I assume that if you may hit the issue under certain circumstances, maybe with some custom operators. [~cltlfcjin], do you have such an example for the SQL of the query and the MV? Otherwise, [~julianhyde], [~zhenw], since you both raised the concern about the test and after reading this explanation, do you think it is OK to merge given that there are no regressions in current test suite? Do you have any other ideas/suggestions? Thanks 

> MV rewriting bails out incorrectly when a view does not contain any table reference
> -----------------------------------------------------------------------------------
>
>                 Key: CALCITE-2727
>                 URL: https://issues.apache.org/jira/browse/CALCITE-2727
>             Project: Calcite
>          Issue Type: Bug
>          Components: core
>            Reporter: Lantao Jin
>            Assignee: Julian Hyde
>            Priority: Major
>
> When we iterate through all applicable materializations trying to rewrite the given query, if there are no table references in a given MV, we bail out from the {{onMatch}} method instead of simply skipping the MV.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)