[jira] [Updated] (CALCITE-4308) JointNode in Interpreter might fail with NPE for FULL join
[
https://issues.apache.org/jira/browse/CALCITE-4308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Sitnikov updated CALCITE-4308:
---
Description:
https://github.com/apache/calcite/blob/64a0ca71038da14f0f883f169aa95df00d909e06/core/src/main/java/org/apache/calcite/interpreter/JoinNode.java#L85
{code:java}
if (rel.getJoinType() == JoinRelType.FULL) {
// send un-match rows for full join on right source
List empty = new ArrayList<>();
for (Row row: innerRows) { // <-- NPE here
if (matchRowSet.contains(row)) {
continue;
}
doSend(row, empty, JoinRelType.RIGHT);
}
}
{code}
> JointNode in Interpreter might fail with NPE for FULL join
> --
>
> Key: CALCITE-4308
> URL: https://issues.apache.org/jira/browse/CALCITE-4308
> Project: Calcite
> Issue Type: Sub-task
> Components: core
>Affects Versions: 1.25.0
>Reporter: Vladimir Sitnikov
>Priority: Major
>
> https://github.com/apache/calcite/blob/64a0ca71038da14f0f883f169aa95df00d909e06/core/src/main/java/org/apache/calcite/interpreter/JoinNode.java#L85
> {code:java}
> if (rel.getJoinType() == JoinRelType.FULL) {
> // send un-match rows for full join on right source
> List empty = new ArrayList<>();
> for (Row row: innerRows) { // <-- NPE here
> if (matchRowSet.contains(row)) {
> continue;
> }
> doSend(row, empty, JoinRelType.RIGHT);
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-4308) JointNode in Interpreter might fail with NPE for FULL join
[
https://issues.apache.org/jira/browse/CALCITE-4308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Sitnikov updated CALCITE-4308:
---
Summary: JointNode in Interpreter might fail with NPE for FULL join (was:
JointNode in Iterpreter might fail with NPE for FULL join)
> JointNode in Interpreter might fail with NPE for FULL join
> --
>
> Key: CALCITE-4308
> URL: https://issues.apache.org/jira/browse/CALCITE-4308
> Project: Calcite
> Issue Type: Sub-task
> Components: core
>Affects Versions: 1.25.0
> Environment:
> https://github.com/apache/calcite/blob/64a0ca71038da14f0f883f169aa95df00d909e06/core/src/main/java/org/apache/calcite/interpreter/JoinNode.java#L85
> {code:java}
> if (rel.getJoinType() == JoinRelType.FULL) {
> // send un-match rows for full join on right source
> List empty = new ArrayList<>();
> for (Row row: innerRows) { // <-- NPE here
> if (matchRowSet.contains(row)) {
> continue;
> }
> doSend(row, empty, JoinRelType.RIGHT);
> }
> }
> {code}
>Reporter: Vladimir Sitnikov
>Priority: Major
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-4308) JointNode in Interpreter might fail with NPE for FULL join
[
https://issues.apache.org/jira/browse/CALCITE-4308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Sitnikov updated CALCITE-4308:
---
Environment: (was:
https://github.com/apache/calcite/blob/64a0ca71038da14f0f883f169aa95df00d909e06/core/src/main/java/org/apache/calcite/interpreter/JoinNode.java#L85
{code:java}
if (rel.getJoinType() == JoinRelType.FULL) {
// send un-match rows for full join on right source
List empty = new ArrayList<>();
for (Row row: innerRows) { // <-- NPE here
if (matchRowSet.contains(row)) {
continue;
}
doSend(row, empty, JoinRelType.RIGHT);
}
}
{code})
> JointNode in Interpreter might fail with NPE for FULL join
> --
>
> Key: CALCITE-4308
> URL: https://issues.apache.org/jira/browse/CALCITE-4308
> Project: Calcite
> Issue Type: Sub-task
> Components: core
>Affects Versions: 1.25.0
>Reporter: Vladimir Sitnikov
>Priority: Major
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (CALCITE-4308) JointNode in Iterpreter might fail with NPE for FULL join
Vladimir Sitnikov created CALCITE-4308:
--
Summary: JointNode in Iterpreter might fail with NPE for FULL join
Key: CALCITE-4308
URL: https://issues.apache.org/jira/browse/CALCITE-4308
Project: Calcite
Issue Type: Sub-task
Components: core
Affects Versions: 1.25.0
Environment:
https://github.com/apache/calcite/blob/64a0ca71038da14f0f883f169aa95df00d909e06/core/src/main/java/org/apache/calcite/interpreter/JoinNode.java#L85
{code:java}
if (rel.getJoinType() == JoinRelType.FULL) {
// send un-match rows for full join on right source
List empty = new ArrayList<>();
for (Row row: innerRows) { // <-- NPE here
if (matchRowSet.contains(row)) {
continue;
}
doSend(row, empty, JoinRelType.RIGHT);
}
}
{code}
Reporter: Vladimir Sitnikov
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-4278) Add Druid adapter tests in GitHub CI
[ https://issues.apache.org/jira/browse/CALCITE-4278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17206863#comment-17206863 ] Stamatis Zampetakis commented on CALCITE-4278: -- I send an email to Docker asking if the rates will apply to Apache projects and if there is any special procedure to apply for our usecases. Will keep you posted! > Add Druid adapter tests in GitHub CI > > > Key: CALCITE-4278 > URL: https://issues.apache.org/jira/browse/CALCITE-4278 > Project: Calcite > Issue Type: Improvement > Components: druid-adapter >Reporter: Stamatis Zampetakis >Assignee: Stamatis Zampetakis >Priority: Major > Labels: pull-request-available > Fix For: 1.26.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > Druid adapter tests are not run in continuous integration (GitHub, Jenkins) > fact that leaves the Druid adapter broken most of the time. > To avoid further regressions in the future, I propose to add a new GitHub CI > action for the Druid Adapter. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-4223) Introducing column statistics to RelOptTable
[ https://issues.apache.org/jira/browse/CALCITE-4223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17206840#comment-17206840 ] Julian Hyde commented on CALCITE-4223: -- I did some more work here: https://github.com/julianhyde/calcite/tree/4223-metadata > Introducing column statistics to RelOptTable > > > Key: CALCITE-4223 > URL: https://issues.apache.org/jira/browse/CALCITE-4223 > Project: Calcite > Issue Type: Improvement >Reporter: Chunwei Lei >Assignee: Chunwei Lei >Priority: Major > Labels: pull-request-available > Time Spent: 40m > Remaining Estimate: 0h > > Many systems depend on column statistics to compute more accurate stats, such > as NDV, average column size, and so on. It would be nice if Calcite can > provide such an interface. > Column statistics might include NDV, average/max column length, number of > nulls, number of trues, number of falses and so on. > What do you think? > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CALCITE-4305) Implicit column alias for single-column UNNEST
[
https://issues.apache.org/jira/browse/CALCITE-4305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde updated CALCITE-4305:
-
Description:
Single-column UNNEST with a single alias should assign that alias to both a
table and the unique column. For example, PostgreSQL returns a column called
'unnest' in the first, and 'fruit' in all of the rest:
{code}
select * from UNNEST(array ['apple', 'banana', 'pear']);
select * from UNNEST(array ['apple', 'banana', 'pear']) as fruit;
select * from UNNEST(array ['apple', 'banana', 'pear']) as t(fruit);
select t.* from UNNEST(array ['apple', 'banana', 'pear']) as t(fruit);
select fruit.* from UNNEST(array ['apple', 'banana', 'pear']) as fruit;
{code}
Thus {{FROM UNNEST(...) AS x}} is creating a table alias {{x}} and a column
alias {{x}}.
This only happens for UNNEST. When aliasing other single-column relations the
column name is retained, such as a SELECT-FROM-UNNEST sub-query as follows:
{code}
SELECT fruit.*
FROM (SELECT * FROM UNNEST(array ['apple', 'banana', 'pear']) as x) as fruit;
x
==
apple
banana
pear
{code}
BigQuery has [similar
behavior|https://cloud.google.com/bigquery/docs/reference/standard-sql/functions-and-operators#any_value].
was:
Single-column UNNEST with a single alias should assign that alias to both a
table and the unique column. For example, PostgreSQL returns a column called
'unnest' in the first, and 'fruit' in all of the rest:
{code}
select * from UNNEST(array ['apple', 'banana', 'pear']);
select * from UNNEST(array ['apple', 'banana', 'pear']) as fruit;
select * from UNNEST(array ['apple', 'banana', 'pear']) as t(fruit);
select t.* from UNNEST(array ['apple', 'banana', 'pear']) as t(fruit);
select fruit.* from UNNEST(array ['apple', 'banana', 'pear']) as fruit;
{code}
Thus {{FROM UNNEST(...) AS x}} is creating a table alias {{x}} and a column
alias {{x}}.
This only happens for UNNEST. When aliasing other single-column relations the
column name is retained, such as a SELECT-FROM-UNNEST sub-query as follows:
{code}
SELECT fruit.*
FROM (SELECT * FROM UNNEST(array ['apple', 'banana', 'pear']) as x) as fruit;
x
==
apple
banana
pear
{code}
> Implicit column alias for single-column UNNEST
> --
>
> Key: CALCITE-4305
> URL: https://issues.apache.org/jira/browse/CALCITE-4305
> Project: Calcite
> Issue Type: Bug
>Reporter: Julian Hyde
>Priority: Major
>
> Single-column UNNEST with a single alias should assign that alias to both a
> table and the unique column. For example, PostgreSQL returns a column called
> 'unnest' in the first, and 'fruit' in all of the rest:
> {code}
> select * from UNNEST(array ['apple', 'banana', 'pear']);
> select * from UNNEST(array ['apple', 'banana', 'pear']) as fruit;
> select * from UNNEST(array ['apple', 'banana', 'pear']) as t(fruit);
> select t.* from UNNEST(array ['apple', 'banana', 'pear']) as t(fruit);
> select fruit.* from UNNEST(array ['apple', 'banana', 'pear']) as fruit;
> {code}
> Thus {{FROM UNNEST(...) AS x}} is creating a table alias {{x}} and a column
> alias {{x}}.
> This only happens for UNNEST. When aliasing other single-column relations the
> column name is retained, such as a SELECT-FROM-UNNEST sub-query as follows:
> {code}
> SELECT fruit.*
> FROM (SELECT * FROM UNNEST(array ['apple', 'banana', 'pear']) as x) as fruit;
> x
> ==
> apple
> banana
> pear
> {code}
> BigQuery has [similar
> behavior|https://cloud.google.com/bigquery/docs/reference/standard-sql/functions-and-operators#any_value].
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (CALCITE-4305) Implicit column alias for single-column UNNEST
Julian Hyde created CALCITE-4305:
Summary: Implicit column alias for single-column UNNEST
Key: CALCITE-4305
URL: https://issues.apache.org/jira/browse/CALCITE-4305
Project: Calcite
Issue Type: Bug
Reporter: Julian Hyde
Single-column UNNEST with a single alias should assign that alias to both a
table and the unique column. For example, PostgreSQL returns a column called
'unnest' in the first, and 'fruit' in all of the rest:
{code}
select * from UNNEST(array ['apple', 'banana', 'pear']);
select * from UNNEST(array ['apple', 'banana', 'pear']) as fruit;
select * from UNNEST(array ['apple', 'banana', 'pear']) as t(fruit);
select t.* from UNNEST(array ['apple', 'banana', 'pear']) as t(fruit);
select fruit.* from UNNEST(array ['apple', 'banana', 'pear']) as fruit;
{code}
Thus {{FROM UNNEST(...) AS x}} is creating a table alias {{x}} and a column
alias {{x}}.
This only happens for UNNEST. When aliasing other single-column relations the
column name is retained, such as a SELECT-FROM-UNNEST sub-query as follows:
{code}
SELECT fruit.*
FROM (SELECT * FROM UNNEST(array ['apple', 'banana', 'pear']) as x) as fruit;
x
==
apple
banana
pear
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-3782) Bitwise operator Bit_And, Bit_OR and Bit_XOR support binary and varbinary type
[
https://issues.apache.org/jira/browse/CALCITE-3782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17206812#comment-17206812
]
Julian Hyde commented on CALCITE-3782:
--
[~hailong wang], Since you implemented this feature, I think you should
research the specification and write tests for corner cases. I know that
{{BIT_AND(X'FF', X'')}} currently returns {{X'FF'}}, and that is wrong.
The code treats empty ByteString values are special, and I don't see any good
reason for that.
> Bitwise operator Bit_And, Bit_OR and Bit_XOR support binary and varbinary type
> --
>
> Key: CALCITE-3782
> URL: https://issues.apache.org/jira/browse/CALCITE-3782
> Project: Calcite
> Issue Type: Sub-task
> Components: core
>Affects Versions: 1.22.0
>Reporter: hailong wang
>Assignee: hailong wang
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.26.0
>
> Time Spent: 4h 50m
> Remaining Estimate: 0h
>
> According to the discussion link CALCITE-3732 , We should make bitwise
> operators work on all integer types, BINARY and VARBINARY. So Bit_And, Bit_OR
> and Bit_XOR agg operator should also support BINARY and VARBINARY.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-3782) Bitwise operator Bit_And, Bit_OR and Bit_XOR support binary and varbinary type
[ https://issues.apache.org/jira/browse/CALCITE-3782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17206793#comment-17206793 ] Vladimir Sitnikov commented on CALCITE-3782: I don't know what is the specification for bitand, so I can't tell if there should be an exception or not. > Bitwise operator Bit_And, Bit_OR and Bit_XOR support binary and varbinary type > -- > > Key: CALCITE-3782 > URL: https://issues.apache.org/jira/browse/CALCITE-3782 > Project: Calcite > Issue Type: Sub-task > Components: core >Affects Versions: 1.22.0 >Reporter: hailong wang >Assignee: hailong wang >Priority: Major > Labels: pull-request-available > Fix For: 1.26.0 > > Time Spent: 4h 50m > Remaining Estimate: 0h > > According to the discussion link CALCITE-3732 , We should make bitwise > operators work on all integer types, BINARY and VARBINARY. So Bit_And, Bit_OR > and Bit_XOR agg operator should also support BINARY and VARBINARY. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-3782) Bitwise operator Bit_And, Bit_OR and Bit_XOR support binary and varbinary type
[ https://issues.apache.org/jira/browse/CALCITE-3782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17206789#comment-17206789 ] hailong wang commented on CALCITE-3782: --- Thanks [~julianhyde], [~vladimirsitnikov]. Sorry for reply later, This judgment is indeed confusing. [~vladimirsitnikov] do you mean `bitand(empty, non-empty)` should throw exception for the different lengths of two byteString. If that, I think We can just remove `byteString.size() == 0 `? > Bitwise operator Bit_And, Bit_OR and Bit_XOR support binary and varbinary type > -- > > Key: CALCITE-3782 > URL: https://issues.apache.org/jira/browse/CALCITE-3782 > Project: Calcite > Issue Type: Sub-task > Components: core >Affects Versions: 1.22.0 >Reporter: hailong wang >Assignee: hailong wang >Priority: Major > Labels: pull-request-available > Fix For: 1.26.0 > > Time Spent: 4h 50m > Remaining Estimate: 0h > > According to the discussion link CALCITE-3732 , We should make bitwise > operators work on all integer types, BINARY and VARBINARY. So Bit_And, Bit_OR > and Bit_XOR agg operator should also support BINARY and VARBINARY. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CALCITE-4304) Make org.apache.calcite.jdbc.JavaTypeFactoryImpl#getJavaClass non-nullable
Vladimir Sitnikov created CALCITE-4304:
--
Summary: Make
org.apache.calcite.jdbc.JavaTypeFactoryImpl#getJavaClass non-nullable
Key: CALCITE-4304
URL: https://issues.apache.org/jira/browse/CALCITE-4304
Project: Calcite
Issue Type: Sub-task
Components: core
Affects Versions: 1.25.0
Reporter: Vladimir Sitnikov
Assignee: Vladimir Sitnikov
The current implementation returns {{null}} as the last resort, however, it
looks like none of the use-sites would handle that properly.
I suggest we throw IllegalArgumentException if {{getJavaClass}} can't deal with
given argument.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-4303) Refactor org.apache.calcite.rel.RelInput to provide null-safe getters
[
https://issues.apache.org/jira/browse/CALCITE-4303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17206662#comment-17206662
]
Vladimir Sitnikov commented on CALCITE-4303:
For instance, here's how RelInput is used in RexProgram (note that is has to
use requireNonNull since getExpressionList returns nullable value):
{code:java}
final List exprs =
requireNonNull(input.getExpressionList("exprs"), "exprs");
final List projectRexNodes = requireNonNull(
input.getExpressionList("projects"),
"projects");
{code}
> Refactor org.apache.calcite.rel.RelInput to provide null-safe getters
> -
>
> Key: CALCITE-4303
> URL: https://issues.apache.org/jira/browse/CALCITE-4303
> Project: Calcite
> Issue Type: Sub-task
> Components: core
>Affects Versions: 1.25.0
>Reporter: Vladimir Sitnikov
>Priority: Major
>
> There are several methods which might return null, however, they are used a
> lot as "never null" ones:
> {code:java}
> > @Nullable E getEnum(String tag, Class enumClass);
> @Nullable List getExpressionList(String tag);
> @Nullable List getStringList(String tag);
> @Nullable List getIntegerList(String tag);
> @Nullable List> getIntegerListList(String tag);
> {code}
> It would be nice if the methods returned non-nullable values.
> The suggested API is
> {code:java}
> > E getEnum(String tag, Class enumClass);
> List getExpressionList(String tag);
> List getStringList(String tag);
> List getIntegerList(String tag);
> List> getIntegerListList(String tag);
> > @Nullable E getEnumOrNull(String tag, Class
> enumClass);
> @Nullable List getExpressionListOrNull(String tag);
> @Nullable List getStringListOrNull(String tag);
> @Nullable List getIntegerListOrNull(String tag);
> @Nullable List> getIntegerListListOrNull(String tag);
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (CALCITE-4303) Refactor org.apache.calcite.rel.RelInput to provide null-safe getters
Vladimir Sitnikov created CALCITE-4303:
--
Summary: Refactor org.apache.calcite.rel.RelInput to provide
null-safe getters
Key: CALCITE-4303
URL: https://issues.apache.org/jira/browse/CALCITE-4303
Project: Calcite
Issue Type: Sub-task
Components: core
Affects Versions: 1.25.0
Reporter: Vladimir Sitnikov
There are several methods which might return null, however, they are used a lot
as "never null" ones:
{code:java}
> @Nullable E getEnum(String tag, Class enumClass);
@Nullable List getExpressionList(String tag);
@Nullable List getStringList(String tag);
@Nullable List getIntegerList(String tag);
@Nullable List> getIntegerListList(String tag);
{code}
It would be nice if the methods returned non-nullable values.
The suggested API is
{code:java}
> E getEnum(String tag, Class enumClass);
List getExpressionList(String tag);
List getStringList(String tag);
List getIntegerList(String tag);
List> getIntegerListList(String tag);
> @Nullable E getEnumOrNull(String tag, Class enumClass);
@Nullable List getExpressionListOrNull(String tag);
@Nullable List getStringListOrNull(String tag);
@Nullable List getIntegerListOrNull(String tag);
@Nullable List> getIntegerListListOrNull(String tag);
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-4251) Overload RelMetadataQuery#getColumnOrigin method
[
https://issues.apache.org/jira/browse/CALCITE-4251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-4251:
Labels: pull-request-available (was: )
> Overload RelMetadataQuery#getColumnOrigin method
>
>
> Key: CALCITE-4251
> URL: https://issues.apache.org/jira/browse/CALCITE-4251
> Project: Calcite
> Issue Type: Wish
>Reporter: xzh_dz
>Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> A case:
>
> {code:java}
> final String sql1 = ""
> + "select empno, sum(sal) as all_sal\n"
> + "from emp\n"
> + "group by empno";
> {code}
> When i try to get the `all_sal` origin column field,it will return null and
> it is derived. we always get the origin column although it is derived. We
> should overload this method.
>
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-4251) Overload RelMetadataQuery#getColumnOrigin method
[
https://issues.apache.org/jira/browse/CALCITE-4251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
xzh_dz updated CALCITE-4251:
Description:
A case:
{code:java}
final String sql1 = ""
+ "select empno, sum(sal) as all_sal\n"
+ "from emp\n"
+ "group by empno";
{code}
When i try to get the `all_sal` origin column field,it will return null and it
is derived. we always get the origin column although it is derived. We should
overload this method.
was:
A case:
{code:java}
//
select col1, col2 , sum(count_col4) as sum_col4
from (
select col1, col2, col3, count(col4) as count_col4
from tbl
group by col1, col2, col3
)
group by col1, col2
{code}
When i try to get the `sum_col4` origin column field,it will return null and it
is derived. we always get the origin column although it is derived. We should
overload this method.
> Overload RelMetadataQuery#getColumnOrigin method
>
>
> Key: CALCITE-4251
> URL: https://issues.apache.org/jira/browse/CALCITE-4251
> Project: Calcite
> Issue Type: Wish
>Reporter: xzh_dz
>Priority: Major
>
> A case:
>
> {code:java}
> final String sql1 = ""
> + "select empno, sum(sal) as all_sal\n"
> + "from emp\n"
> + "group by empno";
> {code}
> When i try to get the `all_sal` origin column field,it will return null and
> it is derived. we always get the origin column although it is derived. We
> should overload this method.
>
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-4296) Materialization recognition fail, cannot match Calc on top of materialized view
[
https://issues.apache.org/jira/browse/CALCITE-4296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-4296:
Labels: pull-request-available (was: )
> Materialization recognition fail, cannot match Calc on top of materialized
> view
> ---
>
> Key: CALCITE-4296
> URL: https://issues.apache.org/jira/browse/CALCITE-4296
> Project: Calcite
> Issue Type: Wish
>Reporter: xzh_dz
>Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> MaterializedViewSubstitutionVisitorTest
> {code:java}
> // code placeholder
> @Test void test() {
> String mv = ""
> + "select sum(\"salary\"), \"deptno\"\n"
> + "from \"emps\"\n"
> + "group by \"deptno\"";
> String query = ""
> + "select \"deptno\"\n"
> + "from \"emps\"\n"
> + "group by \"deptno\"";
> sql(mv, query).ok();
> }
> {code}
> exception:
> {code:java}
> // code placeholder
> java.lang.AssertionError: Materialized view failed to be matched by optimized
> results:java.lang.AssertionError: Materialized view failed to be matched by
> optimized results: at
> org.apache.calcite.test.AbstractMaterializedViewTest.checkMaterialize(AbstractMaterializedViewTest.java:112)
> at
> org.apache.calcite.test.AbstractMaterializedViewTest.access$000(AbstractMaterializedViewTest.java:64)
> at
> org.apache.calcite.test.AbstractMaterializedViewTest$Sql.ok(AbstractMaterializedViewTest.java:226)
> at java.lang.invoke.MethodHandle.invokeWithArguments(MethodHandle.java:627)
> at
> org.apache.calcite.util.ImmutableBeans.lambda$makeDef$3(ImmutableBeans.java:291)
> at
> org.apache.calcite.util.ImmutableBeans$BeanImpl.invoke(ImmutableBeans.java:481)
> at com.sun.proxy.$Proxy12.ok(Unknown Source)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
