[jira] [Updated] (CALCITE-3332) Query failed with AssertionError: cannot cast null as class java.math.BigDecimal
[
https://issues.apache.org/jira/browse/CALCITE-3332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-3332:
Labels: pull-request-available (was: )
> Query failed with AssertionError: cannot cast null as class
> java.math.BigDecimal
>
>
> Key: CALCITE-3332
> URL: https://issues.apache.org/jira/browse/CALCITE-3332
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.21.0
>Reporter: Feng Zhu
>Assignee: Feng Zhu
>Priority: Major
> Labels: pull-request-available
>
> The problem can be reproduced by the following test case in
> ReflectiveSchemaTest
> {code:java}
> @Test public void testDivideNull() {
>final CalciteAssert.AssertThat with =
>CalciteAssert.that().withSchema("s", CATCHALL);
>with.query("select \"wrapperLong\" / null as c\n"
> + " from \"s\".\"everyTypes\"")
>.runs();
> }{code}
> The stacktrace is
> {code:java}
> java.lang.AssertionError: cannot cast null as class java.math.BigDecimal
> at org.apache.calcite.sql.SqlLiteral.getValueAs(SqlLiteral.java:351)
> at
> org.apache.calcite.sql.SqlCallBinding.getOperandLiteralValue(SqlCallBinding.java:217)
> at
> org.apache.calcite.sql.SqlBinaryOperator.getMonotonicity(SqlBinaryOperator.java:190)
> at org.apache.calcite.sql.SqlCall.getMonotonicity(SqlCall.java:182)
> at
> org.apache.calcite.sql.SqlCallBinding.getOperandMonotonicity(SqlCallBinding.java:188)
> at
> org.apache.calcite.sql.SqlAsOperator.getMonotonicity(SqlAsOperator.java:139)
> at org.apache.calcite.sql.SqlCall.getMonotonicity(SqlCall.java:182)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertSelectList(SqlToRelConverter.java:3961)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertSelectImpl(SqlToRelConverter.java:670)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertSelect(SqlToRelConverter.java:627)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertQueryRecursive(SqlToRelConverter.java:3180)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertQuery(SqlToRelConverter.java:563)
> ...
> {code}
> When SqlBinaryOperator figuring out its {{Monotonicity}}, if the second
> operand is a Literal, it will cast the literal into BigDecimal. But the
> {{Null}} Literal is not properly handled.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (CALCITE-3336) Intermittent failure of PigRelBuilderStyleTest.testImplWithGroupByCountDistinct
[
https://issues.apache.org/jira/browse/CALCITE-3336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16926140#comment-16926140
]
Julian Feinauer commented on CALCITE-3336:
--
Thank you [~zabetak] for creating the issue, I added my configuration.
> Intermittent failure of
> PigRelBuilderStyleTest.testImplWithGroupByCountDistinct
> ---
>
> Key: CALCITE-3336
> URL: https://issues.apache.org/jira/browse/CALCITE-3336
> Project: Calcite
> Issue Type: Bug
> Components: pig-adapter
>Affects Versions: 1.21.0
> Environment: +Jenkins environment+
> jdk-11-ea+28
> apache-maven-3.5.2
> Ubuntu 16.04 LTS
> +Local Environment (jfeinauer)+
> java version "1.8.0_181"
> Java(TM) SE Runtime Environment (build 1.8.0_181-b13)
> Java HotSpot(TM) 64-Bit Server VM (build 25.181-b13, mixed mode)
> Apache Maven 3.6.1 (d66c9c0b3152b2e69ee9bac180bb8fcc8e6af555;
> 2019-04-04T12:00:29-07:00)
> macOS Mojave 10.14.4 (18E226)
>Reporter: Stamatis Zampetakis
>Priority: Major
>
> The following tests fails intermittently with the following stack trace:
> {noformat}
> [ERROR] Tests run: 8, Failures: 0, Errors: 1, Skipped: 4, Time elapsed: 5.518
> s <<< FAILURE! - in org.apache.calcite.test.PigRelBuilderStyleTest
> [ERROR]
> testImplWithGroupByCountDistinct(org.apache.calcite.test.PigRelBuilderStyleTest)
> Time elapsed: 3.82 s <<< ERROR!
> org.apache.pig.impl.logicalLayer.FrontendException: Unable to open iterator
> for alias t
> at
> org.apache.calcite.test.PigRelBuilderStyleTest.assertScriptAndResults(PigRelBuilderStyleTest.java:270)
> at
> org.apache.calcite.test.PigRelBuilderStyleTest.testImplWithGroupByCountDistinct(PigRelBuilderStyleTest.java:167)
> Caused by: org.apache.pig.PigException: Unable to store alias t
> at
> org.apache.calcite.test.PigRelBuilderStyleTest.assertScriptAndResults(PigRelBuilderStyleTest.java:270)
> at
> org.apache.calcite.test.PigRelBuilderStyleTest.testImplWithGroupByCountDistinct(PigRelBuilderStyleTest.java:167)
> Caused by: org.apache.pig.impl.logicalLayer.FrontendException: Error
> processing rule LoadTypeCastInserter
> at
> org.apache.calcite.test.PigRelBuilderStyleTest.assertScriptAndResults(PigRelBuilderStyleTest.java:270)
> at
> org.apache.calcite.test.PigRelBuilderStyleTest.testImplWithGroupByCountDistinct(PigRelBuilderStyleTest.java:167)
> Caused by: java.lang.NullPointerException
> at
> org.apache.calcite.test.PigRelBuilderStyleTest.assertScriptAndResults(PigRelBuilderStyleTest.java:270)
> at
> org.apache.calcite.test.PigRelBuilderStyleTest.testImplWithGroupByCountDistinct(PigRelBuilderStyleTest.java:167)
> {noformat}
> The problem appeared a few times in Jenkins (e.g., in build
> [1330|https://builds.apache.org/job/Calcite-Master/1330/jdk=JDK%2011%20(latest),label_exp=ubuntu&&!cloud-slave&&!H27&&!ubuntu-4/])
> and was observed also by [~julian.feinauer].
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Updated] (CALCITE-3336) Intermittent failure of PigRelBuilderStyleTest.testImplWithGroupByCountDistinct
[
https://issues.apache.org/jira/browse/CALCITE-3336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Feinauer updated CALCITE-3336:
-
Environment:
+Jenkins environment+
jdk-11-ea+28
apache-maven-3.5.2
Ubuntu 16.04 LTS
+Local Environment (jfeinauer)+
java version "1.8.0_181"
Java(TM) SE Runtime Environment (build 1.8.0_181-b13)
Java HotSpot(TM) 64-Bit Server VM (build 25.181-b13, mixed mode)
Apache Maven 3.6.1 (d66c9c0b3152b2e69ee9bac180bb8fcc8e6af555;
2019-04-04T12:00:29-07:00)
macOS Mojave 10.14.4 (18E226)
was:
+Jenkins environment+
jdk-11-ea+28
apache-maven-3.5.2
Ubuntu 16.04 LTS
> Intermittent failure of
> PigRelBuilderStyleTest.testImplWithGroupByCountDistinct
> ---
>
> Key: CALCITE-3336
> URL: https://issues.apache.org/jira/browse/CALCITE-3336
> Project: Calcite
> Issue Type: Bug
> Components: pig-adapter
>Affects Versions: 1.21.0
> Environment: +Jenkins environment+
> jdk-11-ea+28
> apache-maven-3.5.2
> Ubuntu 16.04 LTS
> +Local Environment (jfeinauer)+
> java version "1.8.0_181"
> Java(TM) SE Runtime Environment (build 1.8.0_181-b13)
> Java HotSpot(TM) 64-Bit Server VM (build 25.181-b13, mixed mode)
> Apache Maven 3.6.1 (d66c9c0b3152b2e69ee9bac180bb8fcc8e6af555;
> 2019-04-04T12:00:29-07:00)
> macOS Mojave 10.14.4 (18E226)
>Reporter: Stamatis Zampetakis
>Priority: Major
>
> The following tests fails intermittently with the following stack trace:
> {noformat}
> [ERROR] Tests run: 8, Failures: 0, Errors: 1, Skipped: 4, Time elapsed: 5.518
> s <<< FAILURE! - in org.apache.calcite.test.PigRelBuilderStyleTest
> [ERROR]
> testImplWithGroupByCountDistinct(org.apache.calcite.test.PigRelBuilderStyleTest)
> Time elapsed: 3.82 s <<< ERROR!
> org.apache.pig.impl.logicalLayer.FrontendException: Unable to open iterator
> for alias t
> at
> org.apache.calcite.test.PigRelBuilderStyleTest.assertScriptAndResults(PigRelBuilderStyleTest.java:270)
> at
> org.apache.calcite.test.PigRelBuilderStyleTest.testImplWithGroupByCountDistinct(PigRelBuilderStyleTest.java:167)
> Caused by: org.apache.pig.PigException: Unable to store alias t
> at
> org.apache.calcite.test.PigRelBuilderStyleTest.assertScriptAndResults(PigRelBuilderStyleTest.java:270)
> at
> org.apache.calcite.test.PigRelBuilderStyleTest.testImplWithGroupByCountDistinct(PigRelBuilderStyleTest.java:167)
> Caused by: org.apache.pig.impl.logicalLayer.FrontendException: Error
> processing rule LoadTypeCastInserter
> at
> org.apache.calcite.test.PigRelBuilderStyleTest.assertScriptAndResults(PigRelBuilderStyleTest.java:270)
> at
> org.apache.calcite.test.PigRelBuilderStyleTest.testImplWithGroupByCountDistinct(PigRelBuilderStyleTest.java:167)
> Caused by: java.lang.NullPointerException
> at
> org.apache.calcite.test.PigRelBuilderStyleTest.assertScriptAndResults(PigRelBuilderStyleTest.java:270)
> at
> org.apache.calcite.test.PigRelBuilderStyleTest.testImplWithGroupByCountDistinct(PigRelBuilderStyleTest.java:167)
> {noformat}
> The problem appeared a few times in Jenkins (e.g., in build
> [1330|https://builds.apache.org/job/Calcite-Master/1330/jdk=JDK%2011%20(latest),label_exp=ubuntu&&!cloud-slave&&!H27&&!ubuntu-4/])
> and was observed also by [~julian.feinauer].
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (CALCITE-3336) Intermittent failure of PigRelBuilderStyleTest.testImplWithGroupByCountDistinct
[
https://issues.apache.org/jira/browse/CALCITE-3336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16926133#comment-16926133
]
Stamatis Zampetakis commented on CALCITE-3336:
--
Hey [~julian.feinauer], feel free to fill the details of your dev environment
to the case.
> Intermittent failure of
> PigRelBuilderStyleTest.testImplWithGroupByCountDistinct
> ---
>
> Key: CALCITE-3336
> URL: https://issues.apache.org/jira/browse/CALCITE-3336
> Project: Calcite
> Issue Type: Bug
> Components: pig-adapter
>Affects Versions: 1.21.0
> Environment: +Jenkins environment+
> jdk-11-ea+28
> apache-maven-3.5.2
> Ubuntu 16.04 LTS
>Reporter: Stamatis Zampetakis
>Priority: Major
>
> The following tests fails intermittently with the following stack trace:
> {noformat}
> [ERROR] Tests run: 8, Failures: 0, Errors: 1, Skipped: 4, Time elapsed: 5.518
> s <<< FAILURE! - in org.apache.calcite.test.PigRelBuilderStyleTest
> [ERROR]
> testImplWithGroupByCountDistinct(org.apache.calcite.test.PigRelBuilderStyleTest)
> Time elapsed: 3.82 s <<< ERROR!
> org.apache.pig.impl.logicalLayer.FrontendException: Unable to open iterator
> for alias t
> at
> org.apache.calcite.test.PigRelBuilderStyleTest.assertScriptAndResults(PigRelBuilderStyleTest.java:270)
> at
> org.apache.calcite.test.PigRelBuilderStyleTest.testImplWithGroupByCountDistinct(PigRelBuilderStyleTest.java:167)
> Caused by: org.apache.pig.PigException: Unable to store alias t
> at
> org.apache.calcite.test.PigRelBuilderStyleTest.assertScriptAndResults(PigRelBuilderStyleTest.java:270)
> at
> org.apache.calcite.test.PigRelBuilderStyleTest.testImplWithGroupByCountDistinct(PigRelBuilderStyleTest.java:167)
> Caused by: org.apache.pig.impl.logicalLayer.FrontendException: Error
> processing rule LoadTypeCastInserter
> at
> org.apache.calcite.test.PigRelBuilderStyleTest.assertScriptAndResults(PigRelBuilderStyleTest.java:270)
> at
> org.apache.calcite.test.PigRelBuilderStyleTest.testImplWithGroupByCountDistinct(PigRelBuilderStyleTest.java:167)
> Caused by: java.lang.NullPointerException
> at
> org.apache.calcite.test.PigRelBuilderStyleTest.assertScriptAndResults(PigRelBuilderStyleTest.java:270)
> at
> org.apache.calcite.test.PigRelBuilderStyleTest.testImplWithGroupByCountDistinct(PigRelBuilderStyleTest.java:167)
> {noformat}
> The problem appeared a few times in Jenkins (e.g., in build
> [1330|https://builds.apache.org/job/Calcite-Master/1330/jdk=JDK%2011%20(latest),label_exp=ubuntu&&!cloud-slave&&!H27&&!ubuntu-4/])
> and was observed also by [~julian.feinauer].
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Created] (CALCITE-3336) Intermittent failure of PigRelBuilderStyleTest.testImplWithGroupByCountDistinct
Stamatis Zampetakis created CALCITE-3336:
Summary: Intermittent failure of
PigRelBuilderStyleTest.testImplWithGroupByCountDistinct
Key: CALCITE-3336
URL: https://issues.apache.org/jira/browse/CALCITE-3336
Project: Calcite
Issue Type: Bug
Components: pig-adapter
Affects Versions: 1.21.0
Environment: +Jenkins environment+
jdk-11-ea+28
apache-maven-3.5.2
Ubuntu 16.04 LTS
Reporter: Stamatis Zampetakis
The following tests fails intermittently with the following stack trace:
{noformat}
[ERROR] Tests run: 8, Failures: 0, Errors: 1, Skipped: 4, Time elapsed: 5.518 s
<<< FAILURE! - in org.apache.calcite.test.PigRelBuilderStyleTest
[ERROR]
testImplWithGroupByCountDistinct(org.apache.calcite.test.PigRelBuilderStyleTest)
Time elapsed: 3.82 s <<< ERROR!
org.apache.pig.impl.logicalLayer.FrontendException: Unable to open iterator for
alias t
at
org.apache.calcite.test.PigRelBuilderStyleTest.assertScriptAndResults(PigRelBuilderStyleTest.java:270)
at
org.apache.calcite.test.PigRelBuilderStyleTest.testImplWithGroupByCountDistinct(PigRelBuilderStyleTest.java:167)
Caused by: org.apache.pig.PigException: Unable to store alias t
at
org.apache.calcite.test.PigRelBuilderStyleTest.assertScriptAndResults(PigRelBuilderStyleTest.java:270)
at
org.apache.calcite.test.PigRelBuilderStyleTest.testImplWithGroupByCountDistinct(PigRelBuilderStyleTest.java:167)
Caused by: org.apache.pig.impl.logicalLayer.FrontendException: Error processing
rule LoadTypeCastInserter
at
org.apache.calcite.test.PigRelBuilderStyleTest.assertScriptAndResults(PigRelBuilderStyleTest.java:270)
at
org.apache.calcite.test.PigRelBuilderStyleTest.testImplWithGroupByCountDistinct(PigRelBuilderStyleTest.java:167)
Caused by: java.lang.NullPointerException
at
org.apache.calcite.test.PigRelBuilderStyleTest.assertScriptAndResults(PigRelBuilderStyleTest.java:270)
at
org.apache.calcite.test.PigRelBuilderStyleTest.testImplWithGroupByCountDistinct(PigRelBuilderStyleTest.java:167)
{noformat}
The problem appeared a few times in Jenkins (e.g., in build
[1330|https://builds.apache.org/job/Calcite-Master/1330/jdk=JDK%2011%20(latest),label_exp=ubuntu&&!cloud-slave&&!H27&&!ubuntu-4/])
and was observed also by [~julian.feinauer].
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Comment Edited] (CALCITE-3335) Connecting on ElasticSearch server on HTTPS
[
https://issues.apache.org/jira/browse/CALCITE-3335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16925865#comment-16925865
]
Shikha Somani edited comment on CALCITE-3335 at 9/9/19 8:21 PM:
Fix for it:
[https://github.com/apache/calcite/pull/1447]
Description: In model pass *hosts* i.e. a list of ElasticSearch host. Each host
should be a well-formed URL.
This is backward compatible i.e. coordinates config work as before.
{noformat}
{
"version": "1.0",
"defaultSchema": "elasticsearch",
"schemas": [
{
"type": "custom",
"name": "elasticsearch",
"factory":
"org.apache.calcite.adapter.elasticsearch.ElasticsearchSchemaFactory",
"operand": {
"hosts": "['https://vpc-xxx:443', 'http://localhost:9200']",
"userConfig": "{'admin': 'admin'}",
"index":"member"
}
}
]
}
{noformat}
was (Author: shikhasomani20):
Fix for it:
[https://github.com/apache/calcite/pull/1447]
Description: In model pass an additional config in operand with name "scheme"
and supply value in this.
{noformat}
{
"version": "1.0",
"defaultSchema": "elasticsearch",
"schemas": [
{
"type": "custom",
"name": "elasticsearch",
"factory":
"org.apache.calcite.adapter.elasticsearch.ElasticsearchSchemaFactory",
"operand": {
"hosts": "['https://vpc-xxx:443', 'http://localhost:9200']",
"userConfig": "{'admin': 'admin'}",
"index":"member"
}
}
]
}
{noformat}
> Connecting on ElasticSearch server on HTTPS
> ---
>
> Key: CALCITE-3335
> URL: https://issues.apache.org/jira/browse/CALCITE-3335
> Project: Calcite
> Issue Type: Improvement
> Components: elasticsearch-adapter
>Reporter: Shikha Somani
>Assignee: Andrei Sereda
>Priority: Major
> Labels: aws, elasticsearch
>
> Currently Calcite assumes that elasticsearch server will be exposed on HTTP
> only. So, it initializes HTTP host with default scheme i.e. HTTP.
> [Code|https://github.com/apache/calcite/blob/master/elasticsearch/src/main/java/org/apache/calcite/adapter/elasticsearch/ElasticsearchSchemaFactory.java#L86]
> If a ElasticSearch server is on HTTPS, connection to it fails with below
> exception:
> Caused by: java.net.UnknownHostException
>
> This is evident when trying to connect on AWS ElasticSearchService which is
> exposed only on HTTPS.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Comment Edited] (CALCITE-3335) Connecting on ElasticSearch server on HTTPS
[
https://issues.apache.org/jira/browse/CALCITE-3335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16925865#comment-16925865
]
Shikha Somani edited comment on CALCITE-3335 at 9/9/19 8:19 PM:
Fix for it:
[https://github.com/apache/calcite/pull/1447]
Description: In model pass an additional config in operand with name "scheme"
and supply value in this.
{noformat}
{
"version": "1.0",
"defaultSchema": "elasticsearch",
"schemas": [
{
"type": "custom",
"name": "elasticsearch",
"factory":
"org.apache.calcite.adapter.elasticsearch.ElasticsearchSchemaFactory",
"operand": {
"hosts": "['https://vpc-xxx:443', 'http://localhost:9200']",
"userConfig": "{'admin': 'admin'}",
"index":"member"
}
}
]
}
{noformat}
was (Author: shikhasomani20):
Fix for it:
https://github.com/apache/calcite/pull/1447
Description: In model pass an additional config in operand with name "scheme"
and supply value in this.
{noformat}
{
"version": "1.0",
"defaultSchema": "elasticsearch",
"schemas": [
{
"type": "custom",
"name": "elasticsearch",
"factory":
"org.apache.calcite.adapter.elasticsearch.ElasticsearchSchemaFactory",
"operand": {
"coordinates": "{'vpc.xxx': 443}",
"userConfig": "{'admin': 'admin'}",
"index":"member"
}
}
]
}
{noformat}
> Connecting on ElasticSearch server on HTTPS
> ---
>
> Key: CALCITE-3335
> URL: https://issues.apache.org/jira/browse/CALCITE-3335
> Project: Calcite
> Issue Type: Improvement
> Components: elasticsearch-adapter
>Reporter: Shikha Somani
>Assignee: Andrei Sereda
>Priority: Major
> Labels: aws, elasticsearch
>
> Currently Calcite assumes that elasticsearch server will be exposed on HTTP
> only. So, it initializes HTTP host with default scheme i.e. HTTP.
> [Code|https://github.com/apache/calcite/blob/master/elasticsearch/src/main/java/org/apache/calcite/adapter/elasticsearch/ElasticsearchSchemaFactory.java#L86]
> If a ElasticSearch server is on HTTPS, connection to it fails with below
> exception:
> Caused by: java.net.UnknownHostException
>
> This is evident when trying to connect on AWS ElasticSearchService which is
> exposed only on HTTPS.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (CALCITE-3329) Implement osquery for OS adapter
[ https://issues.apache.org/jira/browse/CALCITE-3329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16926070#comment-16926070 ] Julian Hyde commented on CALCITE-3329: -- We just had an issue with the Ps table failing on some operating systems. Can you disable the tests (using Assume.assumeTrue or similar) on the operating systems where the feature is not supposed to work. We want to be able to make the simple statement "Calcite's tests pass on all operating systems". > Implement osquery for OS adapter > > > Key: CALCITE-3329 > URL: https://issues.apache.org/jira/browse/CALCITE-3329 > Project: Calcite > Issue Type: New Feature >Reporter: Forward Xu >Assignee: Forward Xu >Priority: Major > Labels: pull-request-available > Attachments: 2016021823310.png, 20160218233139164.png, > image-2019-09-09-08-27-56-974.png, image-2019-09-09-08-33-41-411.png > > Time Spent: 40m > Remaining Estimate: 0h > > Implement osquery command for OS adapter, Achieve similar features of > FaceBook's osquery. E.g: > select * from os_version; > select * from system_info; > select * from mounts; > select * from interface_addresses > select * from memory_info; > select * from interface_addresses; > select * from cpu_info; > select * from java_info; -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (CALCITE-3332) Query failed with AssertionError: cannot cast null as class java.math.BigDecimal
[
https://issues.apache.org/jira/browse/CALCITE-3332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16926063#comment-16926063
]
Julian Hyde commented on CALCITE-3332:
--
The javadoc for {{getOperandLiteralValue}} does not spell out what should
happen if the operand is the null literal. Let's resolve that.
> Query failed with AssertionError: cannot cast null as class
> java.math.BigDecimal
>
>
> Key: CALCITE-3332
> URL: https://issues.apache.org/jira/browse/CALCITE-3332
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.21.0
>Reporter: Feng Zhu
>Assignee: Feng Zhu
>Priority: Major
>
> The problem can be reproduced by the following test case in
> ReflectiveSchemaTest
> {code:java}
> @Test public void testDivideNull() {
>final CalciteAssert.AssertThat with =
>CalciteAssert.that().withSchema("s", CATCHALL);
>with.query("select \"wrapperLong\" / null as c\n"
> + " from \"s\".\"everyTypes\"")
>.runs();
> }{code}
> The stacktrace is
> {code:java}
> java.lang.AssertionError: cannot cast null as class java.math.BigDecimal
> at org.apache.calcite.sql.SqlLiteral.getValueAs(SqlLiteral.java:351)
> at
> org.apache.calcite.sql.SqlCallBinding.getOperandLiteralValue(SqlCallBinding.java:217)
> at
> org.apache.calcite.sql.SqlBinaryOperator.getMonotonicity(SqlBinaryOperator.java:190)
> at org.apache.calcite.sql.SqlCall.getMonotonicity(SqlCall.java:182)
> at
> org.apache.calcite.sql.SqlCallBinding.getOperandMonotonicity(SqlCallBinding.java:188)
> at
> org.apache.calcite.sql.SqlAsOperator.getMonotonicity(SqlAsOperator.java:139)
> at org.apache.calcite.sql.SqlCall.getMonotonicity(SqlCall.java:182)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertSelectList(SqlToRelConverter.java:3961)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertSelectImpl(SqlToRelConverter.java:670)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertSelect(SqlToRelConverter.java:627)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertQueryRecursive(SqlToRelConverter.java:3180)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertQuery(SqlToRelConverter.java:563)
> ...
> {code}
> When SqlBinaryOperator figuring out its {{Monotonicity}}, if the second
> operand is a Literal, it will cast the literal into BigDecimal. But the
> {{Null}} Literal is not properly handled.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (CALCITE-3333) Add time-based ResultSet frame size limiting
[
https://issues.apache.org/jira/browse/CALCITE-?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16926061#comment-16926061
]
Julian Hyde commented on CALCITE-:
--
I like the idea of this, but it's just at an API level. Can you surface it (or
just part of the functionality) through the connect string parameters so that
people can use it out of the box?
When you talk about limiting based on "time" is that the time spent on the
server, or the round-trip time? Unless the server is very slow (e.g. reading a
continuous query sourced from kafka) the RPC latency is much larger than the
time spent on the server.
I'd love if there was a way to say "10,000 rows, or 1 million bytes, as long as
you can do it in 100 ms server and 1 s RPC round trip" as a connect string
parameter.
> Add time-based ResultSet frame size limiting
>
>
> Key: CALCITE-
> URL: https://issues.apache.org/jira/browse/CALCITE-
> Project: Calcite
> Issue Type: New Feature
> Components: avatica
>Reporter: Gabriel Reid
>Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The size of a single JDBC ResultSet frame returned in a single
> {{prepareAndExecute}} or {{fetch}} invocation is currently 100, meaning that
> each retrieval of a portion of a ResultSet will send 100 rows over the wire.
> This frame size may be too big in some situations, and too small in other
> situations.
> If the underlying data source being queried can provide thousands of (small)
> records per second, then only reading them at 100 per RPC call will be
> unnecessarily slow.
> On the other hand, if the underlying data source is only providing records at
> a rate of 1 per second, then it will take 100 seconds for each RPC call to
> return, which can lead to timeouts (particularly if Avatica server is sitting
> behind a proxy that has a strict request timeout).
> The main factors to take into account when finding an ideal size of frame to
> return for each RPC call are:
> * make the frames small enough that they don't overload either Avatica server
> or the client with overly large amounts of data at one time
> * make the frames large enough so that the percentage of total query time
> that is spent only on RPC overhead is minimized
> The general idea of this ticket is to add a pluggable "frame size limiting"
> functionality so that frame size limiting can be done based on the number of
> rows, number of bytes, amount of time spent building a frame, or any other
> property or combination of properties.
> Note that CALCITE-2322 contains some work to allow configuring the size of a
> single frame on a Connection or Statement (via the {{setFetchSize}} method),
> although it's not yet merged in. That ticket would also be useful, and does
> not conflict with the general intent of this ticket.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (CALCITE-3334) Refinement for Substitution-Based MV Matching
[ https://issues.apache.org/jira/browse/CALCITE-3334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16926052#comment-16926052 ] Julian Hyde commented on CALCITE-3334: -- [~jcamachorodriguez], [~swtalbot] FYI. > Refinement for Substitution-Based MV Matching > - > > Key: CALCITE-3334 > URL: https://issues.apache.org/jira/browse/CALCITE-3334 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: jin xing >Priority: Major > > The approach of substitution-based MV matching is an effective way for its > simplicity and extensibility. > This JIRA proposes to refine existing implementation by several points: > # Canonicalize before MV matching -- by such canonicalization we can > significantly simplify the algebra tree and lower the difficulty for > materialization matching. > # Separate matching rules into two categories and enumerate common matching > patterns which need to be covered by rules. > Please check the design doc: [Design > Doc|https://docs.google.com/document/d/1JpwGNFE3hw3yXb7W3-95-jXKClZC5UFPKbuhgYDuEu4/edit#] -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Comment Edited] (CALCITE-3335) Connecting on ElasticSearch server on HTTPS
[
https://issues.apache.org/jira/browse/CALCITE-3335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16925865#comment-16925865
]
Shikha Somani edited comment on CALCITE-3335 at 9/9/19 4:20 PM:
Fix for it:
https://github.com/apache/calcite/pull/1447
Description: In model pass an additional config in operand with name "scheme"
and supply value in this.
{noformat}
{
"version": "1.0",
"defaultSchema": "elasticsearch",
"schemas": [
{
"type": "custom",
"name": "elasticsearch",
"factory":
"org.apache.calcite.adapter.elasticsearch.ElasticsearchSchemaFactory",
"operand": {
"coordinates": "{'vpc.xxx': 443}",
"userConfig": "{'admin': 'admin'}",
"index":"member"
}
}
]
}
{noformat}
was (Author: shikhasomani20):
Fix for it:
https://github.com/apache/calcite/pull/1447
Description: In model pass an additional config in operand with name "scheme"
and supply value in this.
{
"version": "1.0",
"defaultSchema": "elasticsearch",
"schemas": [
{
"type": "custom",
"name": "elasticsearch",
"factory":
"org.apache.calcite.adapter.elasticsearch.ElasticsearchSchemaFactory",
"operand": {
"coordinates": "{'vpc.xxx': 443}",
"userConfig": "{'admin': 'admin'}",
"index":"member"
}
}
]
}
> Connecting on ElasticSearch server on HTTPS
> ---
>
> Key: CALCITE-3335
> URL: https://issues.apache.org/jira/browse/CALCITE-3335
> Project: Calcite
> Issue Type: Improvement
> Components: elasticsearch-adapter
>Reporter: Shikha Somani
>Assignee: Andrei Sereda
>Priority: Major
> Labels: aws, elasticsearch
>
> Currently Calcite assumes that elasticsearch server will be exposed on HTTP
> only. So, it initializes HTTP host with default scheme i.e. HTTP.
> [Code|https://github.com/apache/calcite/blob/master/elasticsearch/src/main/java/org/apache/calcite/adapter/elasticsearch/ElasticsearchSchemaFactory.java#L86]
> If a ElasticSearch server is on HTTPS, connection to it fails with below
> exception:
> Caused by: java.net.UnknownHostException
>
> This is evident when trying to connect on AWS ElasticSearchService which is
> exposed only on HTTPS.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Comment Edited] (CALCITE-3335) Connecting on ElasticSearch server on HTTPS
[
https://issues.apache.org/jira/browse/CALCITE-3335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16925865#comment-16925865
]
Shikha Somani edited comment on CALCITE-3335 at 9/9/19 4:18 PM:
Fix for it:
https://github.com/apache/calcite/pull/1447
Description: In model pass an additional config in operand with name "scheme"
and supply value in this.
{
"version": "1.0",
"defaultSchema": "elasticsearch",
"schemas": [
{
"type": "custom",
"name": "elasticsearch",
"factory":
"org.apache.calcite.adapter.elasticsearch.ElasticsearchSchemaFactory",
"operand": {
"coordinates": "{'vpc.xxx': 443}",
"userConfig": "{'admin': 'admin'}",
"index":"member"
}
}
]
}
was (Author: shikhasomani20):
Fix for it:
https://github.com/apache/calcite/pull/1447
Description: In model pass an additional config in operand with name "scheme"
and supply value in this.
>{
"version": "1.0",
"defaultSchema": "elasticsearch",
"schemas": [
{
"type": "custom",
"name": "elasticsearch",
"factory":
"org.apache.calcite.adapter.elasticsearch.ElasticsearchSchemaFactory",
"operand": {
"coordinates": "{'vpc.xxx': 443}",
"userConfig": "{'admin': 'admin'}",
"index":"member"
}
}
]
}
> Connecting on ElasticSearch server on HTTPS
> ---
>
> Key: CALCITE-3335
> URL: https://issues.apache.org/jira/browse/CALCITE-3335
> Project: Calcite
> Issue Type: Improvement
> Components: elasticsearch-adapter
>Reporter: Shikha Somani
>Assignee: Andrei Sereda
>Priority: Major
> Labels: aws, elasticsearch
>
> Currently Calcite assumes that elasticsearch server will be exposed on HTTP
> only. So, it initializes HTTP host with default scheme i.e. HTTP.
> [Code|https://github.com/apache/calcite/blob/master/elasticsearch/src/main/java/org/apache/calcite/adapter/elasticsearch/ElasticsearchSchemaFactory.java#L86]
> If a ElasticSearch server is on HTTPS, connection to it fails with below
> exception:
> Caused by: java.net.UnknownHostException
>
> This is evident when trying to connect on AWS ElasticSearchService which is
> exposed only on HTTPS.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Comment Edited] (CALCITE-3335) Connecting on ElasticSearch server on HTTPS
[
https://issues.apache.org/jira/browse/CALCITE-3335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16925865#comment-16925865
]
Shikha Somani edited comment on CALCITE-3335 at 9/9/19 4:18 PM:
Fix for it:
https://github.com/apache/calcite/pull/1447
Description: In model pass an additional config in operand with name "scheme"
and supply value in this.
>{
"version": "1.0",
"defaultSchema": "elasticsearch",
"schemas": [
{
"type": "custom",
"name": "elasticsearch",
"factory":
"org.apache.calcite.adapter.elasticsearch.ElasticsearchSchemaFactory",
"operand": {
"coordinates": "{'vpc.xxx': 443}",
"userConfig": "{'admin': 'admin'}",
"index":"member"
}
}
]
}
was (Author: shikhasomani20):
Fix for it:
https://github.com/apache/calcite/pull/1447
Description: In model pass an additional config in operand with name "scheme"
and supply value in this.
{
"version": "1.0",
"defaultSchema": "elasticsearch",
"schemas": [
{
"type": "custom",
"name": "elasticsearch",
"factory":
"org.apache.calcite.adapter.elasticsearch.ElasticsearchSchemaFactory",
"operand": {
"coordinates": "{'vpc.xxx': 443}",
"userConfig": "{'admin': 'admin'}",
"index":"member"
}
}
]
}
> Connecting on ElasticSearch server on HTTPS
> ---
>
> Key: CALCITE-3335
> URL: https://issues.apache.org/jira/browse/CALCITE-3335
> Project: Calcite
> Issue Type: Improvement
> Components: elasticsearch-adapter
>Reporter: Shikha Somani
>Assignee: Andrei Sereda
>Priority: Major
> Labels: aws, elasticsearch
>
> Currently Calcite assumes that elasticsearch server will be exposed on HTTP
> only. So, it initializes HTTP host with default scheme i.e. HTTP.
> [Code|https://github.com/apache/calcite/blob/master/elasticsearch/src/main/java/org/apache/calcite/adapter/elasticsearch/ElasticsearchSchemaFactory.java#L86]
> If a ElasticSearch server is on HTTPS, connection to it fails with below
> exception:
> Caused by: java.net.UnknownHostException
>
> This is evident when trying to connect on AWS ElasticSearchService which is
> exposed only on HTTPS.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (CALCITE-3335) Connecting on ElasticSearch server on HTTPS
[
https://issues.apache.org/jira/browse/CALCITE-3335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16925865#comment-16925865
]
Shikha Somani commented on CALCITE-3335:
Fix for it:
https://github.com/apache/calcite/pull/1447
Description: In model pass an additional config in operand with name "scheme"
and supply value in this.
{
"version": "1.0",
"defaultSchema": "elasticsearch",
"schemas": [
{
"type": "custom",
"name": "elasticsearch",
"factory":
"org.apache.calcite.adapter.elasticsearch.ElasticsearchSchemaFactory",
"operand": {
"coordinates": "{'vpc.xxx': 443}",
"userConfig": "{'admin': 'admin'}",
"index":"member"
}
}
]
}
> Connecting on ElasticSearch server on HTTPS
> ---
>
> Key: CALCITE-3335
> URL: https://issues.apache.org/jira/browse/CALCITE-3335
> Project: Calcite
> Issue Type: Improvement
> Components: elasticsearch-adapter
>Reporter: Shikha Somani
>Assignee: Andrei Sereda
>Priority: Major
> Labels: aws, elasticsearch
>
> Currently Calcite assumes that elasticsearch server will be exposed on HTTP
> only. So, it initializes HTTP host with default scheme i.e. HTTP.
> [Code|https://github.com/apache/calcite/blob/master/elasticsearch/src/main/java/org/apache/calcite/adapter/elasticsearch/ElasticsearchSchemaFactory.java#L86]
> If a ElasticSearch server is on HTTPS, connection to it fails with below
> exception:
> Caused by: java.net.UnknownHostException
>
> This is evident when trying to connect on AWS ElasticSearchService which is
> exposed only on HTTPS.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Assigned] (CALCITE-3335) Connecting on ElasticSearch server on HTTPS
[ https://issues.apache.org/jira/browse/CALCITE-3335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Sereda reassigned CALCITE-3335: -- Assignee: Andrei Sereda > Connecting on ElasticSearch server on HTTPS > --- > > Key: CALCITE-3335 > URL: https://issues.apache.org/jira/browse/CALCITE-3335 > Project: Calcite > Issue Type: Improvement > Components: elasticsearch-adapter >Reporter: Shikha Somani >Assignee: Andrei Sereda >Priority: Major > Labels: aws, elasticsearch > > Currently Calcite assumes that elasticsearch server will be exposed on HTTP > only. So, it initializes HTTP host with default scheme i.e. HTTP. > [Code|https://github.com/apache/calcite/blob/master/elasticsearch/src/main/java/org/apache/calcite/adapter/elasticsearch/ElasticsearchSchemaFactory.java#L86] > If a ElasticSearch server is on HTTPS, connection to it fails with below > exception: > Caused by: java.net.UnknownHostException > > This is evident when trying to connect on AWS ElasticSearchService which is > exposed only on HTTPS. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Created] (CALCITE-3335) Connecting on ElasticSearch server on HTTPS
Shikha Somani created CALCITE-3335: -- Summary: Connecting on ElasticSearch server on HTTPS Key: CALCITE-3335 URL: https://issues.apache.org/jira/browse/CALCITE-3335 Project: Calcite Issue Type: Improvement Components: elasticsearch-adapter Reporter: Shikha Somani Currently Calcite assumes that elasticsearch server will be exposed on HTTP only. So, it initializes HTTP host with default scheme i.e. HTTP. [Code|https://github.com/apache/calcite/blob/master/elasticsearch/src/main/java/org/apache/calcite/adapter/elasticsearch/ElasticsearchSchemaFactory.java#L86] If a ElasticSearch server is on HTTPS, connection to it fails with below exception: Caused by: java.net.UnknownHostException This is evident when trying to connect on AWS ElasticSearchService which is exposed only on HTTPS. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Comment Edited] (CALCITE-3334) Refinement for Substitution-Based MV Matching
[ https://issues.apache.org/jira/browse/CALCITE-3334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16925666#comment-16925666 ] jin xing edited comment on CALCITE-3334 at 9/9/19 1:30 PM: --- I have a commit to illustrate the idea shown in the design doc: [https://github.com/jinxing64/calcite/commit/dd8d7f15faa852641e19f42c51afade5bf7728f2] In the commit, I replaced existing substitution-based rules by new defined rules and passed all tests. Also I added more test cases which can not be supported by original matching rules If this idea proposed is interested, I can split the this work into several issues and submit implementations was (Author: jinxing6...@126.com): I have a commit to illustrate the idea shown in the design doc: [https://github.com/jinxing64/calcite/commit/dd8d7f15faa852641e19f42c51afade5bf7728f2] In the commit, I replaced existing substitution-based rules by new defined rules and passed all tests. Also I added several more test cases. If this idea proposed is interested, I can split the this work into several issues and submit implementations > Refinement for Substitution-Based MV Matching > - > > Key: CALCITE-3334 > URL: https://issues.apache.org/jira/browse/CALCITE-3334 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: jin xing >Priority: Major > > The approach of substitution-based MV matching is an effective way for its > simplicity and extensibility. > This JIRA proposes to refine existing implementation by several points: > # Canonicalize before MV matching -- by such canonicalization we can > significantly simplify the algebra tree and lower the difficulty for > materialization matching. > # Separate matching rules into two categories and enumerate common matching > patterns which need to be covered by rules. > Please check the design doc: [Design > Doc|https://docs.google.com/document/d/1JpwGNFE3hw3yXb7W3-95-jXKClZC5UFPKbuhgYDuEu4/edit#] -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Comment Edited] (CALCITE-3334) Refinement for Substitution-Based MV Matching
[ https://issues.apache.org/jira/browse/CALCITE-3334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16925666#comment-16925666 ] jin xing edited comment on CALCITE-3334 at 9/9/19 1:30 PM: --- I have a commit to illustrate the idea shown in the design doc: [https://github.com/jinxing64/calcite/commit/dd8d7f15faa852641e19f42c51afade5bf7728f2] In the commit, I replaced existing substitution-based rules by new defined rules and passed all tests. Also I added more test cases which can not be supported by original matching rules. If this idea proposed is interested, I can split the this work into several issues and submit implementations was (Author: jinxing6...@126.com): I have a commit to illustrate the idea shown in the design doc: [https://github.com/jinxing64/calcite/commit/dd8d7f15faa852641e19f42c51afade5bf7728f2] In the commit, I replaced existing substitution-based rules by new defined rules and passed all tests. Also I added more test cases which can not be supported by original matching rules If this idea proposed is interested, I can split the this work into several issues and submit implementations > Refinement for Substitution-Based MV Matching > - > > Key: CALCITE-3334 > URL: https://issues.apache.org/jira/browse/CALCITE-3334 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: jin xing >Priority: Major > > The approach of substitution-based MV matching is an effective way for its > simplicity and extensibility. > This JIRA proposes to refine existing implementation by several points: > # Canonicalize before MV matching -- by such canonicalization we can > significantly simplify the algebra tree and lower the difficulty for > materialization matching. > # Separate matching rules into two categories and enumerate common matching > patterns which need to be covered by rules. > Please check the design doc: [Design > Doc|https://docs.google.com/document/d/1JpwGNFE3hw3yXb7W3-95-jXKClZC5UFPKbuhgYDuEu4/edit#] -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (CALCITE-3334) Refinement for Substitution-Based MV Matching
[ https://issues.apache.org/jira/browse/CALCITE-3334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16925686#comment-16925686 ] jin xing commented on CALCITE-3334: --- Really hope committers or any people who have interests to leave some comment on the google doc > Refinement for Substitution-Based MV Matching > - > > Key: CALCITE-3334 > URL: https://issues.apache.org/jira/browse/CALCITE-3334 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: jin xing >Priority: Major > > The approach of substitution-based MV matching is an effective way for its > simplicity and extensibility. > This JIRA proposes to refine existing implementation by several points: > # Canonicalize before MV matching -- by such canonicalization we can > significantly simplify the algebra tree and lower the difficulty for > materialization matching. > # Separate matching rules into two categories and enumerate common matching > patterns which need to be covered by rules. > Please check the design doc: [Design > Doc|https://docs.google.com/document/d/1JpwGNFE3hw3yXb7W3-95-jXKClZC5UFPKbuhgYDuEu4/edit#] -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Updated] (CALCITE-3334) Refinement for Substitution-Based MV Matching
[ https://issues.apache.org/jira/browse/CALCITE-3334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] jin xing updated CALCITE-3334: -- Description: The approach of substitution-based MV matching is an effective way for its simplicity and extensibility. This JIRA proposes to refine existing implementation by several points: # Canonicalize before MV matching -- by such canonicalization we can significantly simplify the algebra tree and lower the difficulty for materialization matching. # Separate matching rules into two categories and enumerate common matching patterns which need to be covered by rules. Please check the design doc: [Design Doc|https://docs.google.com/document/d/1JpwGNFE3hw3yXb7W3-95-jXKClZC5UFPKbuhgYDuEu4/edit#] was: The approach of substitution is an effective way for its simplicity and extensibility. This JIRA proposes to refine existing implementation by several points: # Canonicalize before MV matching -- by such canonicalization we can significantly simplify the algebra tree and lower the difficulty for materialization matching. # Separate matching rules into two categories and enumerate common matching patterns which need to be covered by rules. Please check the design doc: [Design Doc|https://docs.google.com/document/d/1JpwGNFE3hw3yXb7W3-95-jXKClZC5UFPKbuhgYDuEu4/edit#] > Refinement for Substitution-Based MV Matching > - > > Key: CALCITE-3334 > URL: https://issues.apache.org/jira/browse/CALCITE-3334 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: jin xing >Priority: Major > > The approach of substitution-based MV matching is an effective way for its > simplicity and extensibility. > This JIRA proposes to refine existing implementation by several points: > # Canonicalize before MV matching -- by such canonicalization we can > significantly simplify the algebra tree and lower the difficulty for > materialization matching. > # Separate matching rules into two categories and enumerate common matching > patterns which need to be covered by rules. > Please check the design doc: [Design > Doc|https://docs.google.com/document/d/1JpwGNFE3hw3yXb7W3-95-jXKClZC5UFPKbuhgYDuEu4/edit#] -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Comment Edited] (CALCITE-3334) Refinement for Substitution-Based MV Matching
[ https://issues.apache.org/jira/browse/CALCITE-3334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16925666#comment-16925666 ] jin xing edited comment on CALCITE-3334 at 9/9/19 1:05 PM: --- I have a commit to illustrate the idea shown in the design doc: [https://github.com/jinxing64/calcite/commit/dd8d7f15faa852641e19f42c51afade5bf7728f2] In the commit, I replaced existing substitution-based rules by new defined rules and passed all tests. Also I added several more test cases. If this idea proposed is interested, I can split the this work into several issues and submit implementations was (Author: jinxing6...@126.com): I have a commit to illustrate the idea shown in the design doc: [https://github.com/jinxing64/calcite/commit/dd8d7f15faa852641e19f42c51afade5bf7728f2] In the commit, I replaced existing substitution-based rules by new defined rules and passed all tests. Also I added several more test cases. If this idea proposed is interested, I can split the this work into several issues and submit implementations > Refinement for Substitution-Based MV Matching > - > > Key: CALCITE-3334 > URL: https://issues.apache.org/jira/browse/CALCITE-3334 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: jin xing >Priority: Major > > The approach of substitution is an effective way for its simplicity and > extensibility. > This JIRA proposes to refine existing implementation by several points: > # Canonicalize before MV matching -- by such canonicalization we can > significantly simplify the algebra tree and lower the difficulty for > materialization matching. > # Separate matching rules into two categories and enumerate common matching > patterns which need to be covered by rules. > Please check the design doc: [Design > Doc|https://docs.google.com/document/d/1JpwGNFE3hw3yXb7W3-95-jXKClZC5UFPKbuhgYDuEu4/edit#] -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (CALCITE-3334) Refinement for Substitution-Based MV Matching
[ https://issues.apache.org/jira/browse/CALCITE-3334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16925666#comment-16925666 ] jin xing commented on CALCITE-3334: --- I have a commit to illustrate the idea shown in the design doc: [https://github.com/jinxing64/calcite/commit/dd8d7f15faa852641e19f42c51afade5bf7728f2] In the commit, I replaced existing substitution-based rules by new defined rules and passed all tests. Also I added several more test cases. If this idea proposed is interested, I can split the this work into several issues and submit implementations > Refinement for Substitution-Based MV Matching > - > > Key: CALCITE-3334 > URL: https://issues.apache.org/jira/browse/CALCITE-3334 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: jin xing >Priority: Major > > The approach of substitution is an effective way for its simplicity and > extensibility. > This JIRA proposes to refine existing implementation by several points: > # Canonicalize before MV matching -- by such canonicalization we can > significantly simplify the algebra tree and lower the difficulty for > materialization matching. > # Separate matching rules into two categories and enumerate common matching > patterns which need to be covered by rules. > Please check the design doc: [Design > Doc|https://docs.google.com/document/d/1JpwGNFE3hw3yXb7W3-95-jXKClZC5UFPKbuhgYDuEu4/edit#] -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Updated] (CALCITE-3334) Refinement for Substitution-Based MV Matching
[ https://issues.apache.org/jira/browse/CALCITE-3334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] jin xing updated CALCITE-3334: -- Description: The approach of substitution is an effective way for its simplicity and extensibility. This JIRA proposes to refine existing implementation by several points: # Canonicalize before MV matching -- by such canonicalization we can significantly simplify the algebra tree and lower the difficulty for materialization matching. # Separate matching rules into two categories and enumerate common matching patterns which need to be covered by rules. Please check the design doc: [Design Doc|https://docs.google.com/document/d/1JpwGNFE3hw3yXb7W3-95-jXKClZC5UFPKbuhgYDuEu4/edit#] was: The approach of substitution is an effective way for its simplicity and extensibility. This JIRA proposes to refine existing implementation by several points: # Canonicalize before MV matching -- by such canonicalization we can significantly simplify the algebra tree and lower the difficulty for materialization matching. # Separate matching rules into two categories and enumerate common matching patterns which need to be covered by rules. [Design Doc|https://docs.google.com/document/d/1JpwGNFE3hw3yXb7W3-95-jXKClZC5UFPKbuhgYDuEu4/edit#] > Refinement for Substitution-Based MV Matching > - > > Key: CALCITE-3334 > URL: https://issues.apache.org/jira/browse/CALCITE-3334 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: jin xing >Priority: Major > > The approach of substitution is an effective way for its simplicity and > extensibility. > This JIRA proposes to refine existing implementation by several points: > # Canonicalize before MV matching -- by such canonicalization we can > significantly simplify the algebra tree and lower the difficulty for > materialization matching. > # Separate matching rules into two categories and enumerate common matching > patterns which need to be covered by rules. > Please check the design doc: [Design > Doc|https://docs.google.com/document/d/1JpwGNFE3hw3yXb7W3-95-jXKClZC5UFPKbuhgYDuEu4/edit#] -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Updated] (CALCITE-3334) Refinement for Substitution-Based MV Matching
[ https://issues.apache.org/jira/browse/CALCITE-3334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] jin xing updated CALCITE-3334: -- Description: The approach of substitution is an effective way for its simplicity and extensibility. This JIRA proposes to refine existing implementation by several points: # Canonicalize before MV matching -- by such canonicalization we can significantly simplify the algebra tree and lower the difficulty for materialization matching. # Separate matching rules into two categories and enumerate common matching patterns which need to be covered by rules. [Design Doc|https://docs.google.com/document/d/1JpwGNFE3hw3yXb7W3-95-jXKClZC5UFPKbuhgYDuEu4/edit#] > Refinement for Substitution-Based MV Matching > - > > Key: CALCITE-3334 > URL: https://issues.apache.org/jira/browse/CALCITE-3334 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: jin xing >Priority: Major > > The approach of substitution is an effective way for its simplicity and > extensibility. > This JIRA proposes to refine existing implementation by several points: > # Canonicalize before MV matching -- by such canonicalization we can > significantly simplify the algebra tree and lower the difficulty for > materialization matching. > # Separate matching rules into two categories and enumerate common matching > patterns which need to be covered by rules. > > [Design > Doc|https://docs.google.com/document/d/1JpwGNFE3hw3yXb7W3-95-jXKClZC5UFPKbuhgYDuEu4/edit#] -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Created] (CALCITE-3334) Refinement for Substitution-Based MV Matching
jin xing created CALCITE-3334: - Summary: Refinement for Substitution-Based MV Matching Key: CALCITE-3334 URL: https://issues.apache.org/jira/browse/CALCITE-3334 Project: Calcite Issue Type: Improvement Components: core Reporter: jin xing -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Assigned] (CALCITE-3332) Query failed with AssertionError: cannot cast null as class java.math.BigDecimal
[
https://issues.apache.org/jira/browse/CALCITE-3332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Feng Zhu reassigned CALCITE-3332:
-
Assignee: Feng Zhu
> Query failed with AssertionError: cannot cast null as class
> java.math.BigDecimal
>
>
> Key: CALCITE-3332
> URL: https://issues.apache.org/jira/browse/CALCITE-3332
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.21.0
>Reporter: Feng Zhu
>Assignee: Feng Zhu
>Priority: Major
>
> The problem can be reproduced by the following test case in
> ReflectiveSchemaTest
> {code:java}
> @Test public void testDivideNull() {
>final CalciteAssert.AssertThat with =
>CalciteAssert.that().withSchema("s", CATCHALL);
>with.query("select \"wrapperLong\" / null as c\n"
> + " from \"s\".\"everyTypes\"")
>.runs();
> }{code}
> The stacktrace is
> {code:java}
> java.lang.AssertionError: cannot cast null as class java.math.BigDecimal
> at org.apache.calcite.sql.SqlLiteral.getValueAs(SqlLiteral.java:351)
> at
> org.apache.calcite.sql.SqlCallBinding.getOperandLiteralValue(SqlCallBinding.java:217)
> at
> org.apache.calcite.sql.SqlBinaryOperator.getMonotonicity(SqlBinaryOperator.java:190)
> at org.apache.calcite.sql.SqlCall.getMonotonicity(SqlCall.java:182)
> at
> org.apache.calcite.sql.SqlCallBinding.getOperandMonotonicity(SqlCallBinding.java:188)
> at
> org.apache.calcite.sql.SqlAsOperator.getMonotonicity(SqlAsOperator.java:139)
> at org.apache.calcite.sql.SqlCall.getMonotonicity(SqlCall.java:182)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertSelectList(SqlToRelConverter.java:3961)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertSelectImpl(SqlToRelConverter.java:670)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertSelect(SqlToRelConverter.java:627)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertQueryRecursive(SqlToRelConverter.java:3180)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertQuery(SqlToRelConverter.java:563)
> ...
> {code}
> When SqlBinaryOperator figuring out its {{Monotonicity}}, if the second
> operand is a Literal, it will cast the literal into BigDecimal. But the
> {{Null}} Literal is not properly handled.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Updated] (CALCITE-3333) Add time-based ResultSet frame size limiting
[
https://issues.apache.org/jira/browse/CALCITE-?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gabriel Reid updated CALCITE-:
--
Summary: Add time-based ResultSet frame size limiting (was: Add time-based
of ResultSet frame size limiting)
> Add time-based ResultSet frame size limiting
>
>
> Key: CALCITE-
> URL: https://issues.apache.org/jira/browse/CALCITE-
> Project: Calcite
> Issue Type: New Feature
> Components: avatica
>Reporter: Gabriel Reid
>Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The size of a single JDBC ResultSet frame returned in a single
> {{prepareAndExecute}} or {{fetch}} invocation is currently 100, meaning that
> each retrieval of a portion of a ResultSet will send 100 rows over the wire.
> This frame size may be too big in some situations, and too small in other
> situations.
> If the underlying data source being queried can provide thousands of (small)
> records per second, then only reading them at 100 per RPC call will be
> unnecessarily slow.
> On the other hand, if the underlying data source is only providing records at
> a rate of 1 per second, then it will take 100 seconds for each RPC call to
> return, which can lead to timeouts (particularly if Avatica server is sitting
> behind a proxy that has a strict request timeout).
> The main factors to take into account when finding an ideal size of frame to
> return for each RPC call are:
> * make the frames small enough that they don't overload either Avatica server
> or the client with overly large amounts of data at one time
> * make the frames large enough so that the percentage of total query time
> that is spent only on RPC overhead is minimized
> The general idea of this ticket is to add a pluggable "frame size limiting"
> functionality so that frame size limiting can be done based on the number of
> rows, number of bytes, amount of time spent building a frame, or any other
> property or combination of properties.
> Note that CALCITE-2322 contains some work to allow configuring the size of a
> single frame on a Connection or Statement (via the {{setFetchSize}} method),
> although it's not yet merged in. That ticket would also be useful, and does
> not conflict with the general intent of this ticket.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Updated] (CALCITE-3333) Add time-based of ResultSet frame size limiting
[
https://issues.apache.org/jira/browse/CALCITE-?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-:
Labels: pull-request-available (was: )
> Add time-based of ResultSet frame size limiting
> ---
>
> Key: CALCITE-
> URL: https://issues.apache.org/jira/browse/CALCITE-
> Project: Calcite
> Issue Type: New Feature
> Components: avatica
>Reporter: Gabriel Reid
>Priority: Major
> Labels: pull-request-available
>
> The size of a single JDBC ResultSet frame returned in a single
> {{prepareAndExecute}} or {{fetch}} invocation is currently 100, meaning that
> each retrieval of a portion of a ResultSet will send 100 rows over the wire.
> This frame size may be too big in some situations, and too small in other
> situations.
> If the underlying data source being queried can provide thousands of (small)
> records per second, then only reading them at 100 per RPC call will be
> unnecessarily slow.
> On the other hand, if the underlying data source is only providing records at
> a rate of 1 per second, then it will take 100 seconds for each RPC call to
> return, which can lead to timeouts (particularly if Avatica server is sitting
> behind a proxy that has a strict request timeout).
> The main factors to take into account when finding an ideal size of frame to
> return for each RPC call are:
> * make the frames small enough that they don't overload either Avatica server
> or the client with overly large amounts of data at one time
> * make the frames large enough so that the percentage of total query time
> that is spent only on RPC overhead is minimized
> The general idea of this ticket is to add a pluggable "frame size limiting"
> functionality so that frame size limiting can be done based on the number of
> rows, number of bytes, amount of time spent building a frame, or any other
> property or combination of properties.
> Note that CALCITE-2322 contains some work to allow configuring the size of a
> single frame on a Connection or Statement (via the {{setFetchSize}} method),
> although it's not yet merged in. That ticket would also be useful, and does
> not conflict with the general intent of this ticket.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Created] (CALCITE-3333) Add time-based of ResultSet frame size limiting
Gabriel Reid created CALCITE-:
-
Summary: Add time-based of ResultSet frame size limiting
Key: CALCITE-
URL: https://issues.apache.org/jira/browse/CALCITE-
Project: Calcite
Issue Type: New Feature
Components: avatica
Reporter: Gabriel Reid
The size of a single JDBC ResultSet frame returned in a single
{{prepareAndExecute}} or {{fetch}} invocation is currently 100, meaning that
each retrieval of a portion of a ResultSet will send 100 rows over the wire.
This frame size may be too big in some situations, and too small in other
situations.
If the underlying data source being queried can provide thousands of (small)
records per second, then only reading them at 100 per RPC call will be
unnecessarily slow.
On the other hand, if the underlying data source is only providing records at a
rate of 1 per second, then it will take 100 seconds for each RPC call to
return, which can lead to timeouts (particularly if Avatica server is sitting
behind a proxy that has a strict request timeout).
The main factors to take into account when finding an ideal size of frame to
return for each RPC call are:
* make the frames small enough that they don't overload either Avatica server
or the client with overly large amounts of data at one time
* make the frames large enough so that the percentage of total query time that
is spent only on RPC overhead is minimized
The general idea of this ticket is to add a pluggable "frame size limiting"
functionality so that frame size limiting can be done based on the number of
rows, number of bytes, amount of time spent building a frame, or any other
property or combination of properties.
Note that CALCITE-2322 contains some work to allow configuring the size of a
single frame on a Connection or Statement (via the {{setFetchSize}} method),
although it's not yet merged in. That ticket would also be useful, and does not
conflict with the general intent of this ticket.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Updated] (CALCITE-3332) Query failed with AssertionError: cannot cast null as class java.math.BigDecimal
[
https://issues.apache.org/jira/browse/CALCITE-3332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Feng Zhu updated CALCITE-3332:
--
Description:
The problem can be reproduced by the following test case in ReflectiveSchemaTest
{code:java}
@Test public void testDivideNull() {
final CalciteAssert.AssertThat with =
CalciteAssert.that().withSchema("s", CATCHALL);
with.query("select \"wrapperLong\" / null as c\n"
+ " from \"s\".\"everyTypes\"")
.runs();
}{code}
The stacktrace is
{code:java}
java.lang.AssertionError: cannot cast null as class java.math.BigDecimal
at org.apache.calcite.sql.SqlLiteral.getValueAs(SqlLiteral.java:351)
at
org.apache.calcite.sql.SqlCallBinding.getOperandLiteralValue(SqlCallBinding.java:217)
at
org.apache.calcite.sql.SqlBinaryOperator.getMonotonicity(SqlBinaryOperator.java:190)
at org.apache.calcite.sql.SqlCall.getMonotonicity(SqlCall.java:182)
at
org.apache.calcite.sql.SqlCallBinding.getOperandMonotonicity(SqlCallBinding.java:188)
at org.apache.calcite.sql.SqlAsOperator.getMonotonicity(SqlAsOperator.java:139)
at org.apache.calcite.sql.SqlCall.getMonotonicity(SqlCall.java:182)
at
org.apache.calcite.sql2rel.SqlToRelConverter.convertSelectList(SqlToRelConverter.java:3961)
at
org.apache.calcite.sql2rel.SqlToRelConverter.convertSelectImpl(SqlToRelConverter.java:670)
at
org.apache.calcite.sql2rel.SqlToRelConverter.convertSelect(SqlToRelConverter.java:627)
at
org.apache.calcite.sql2rel.SqlToRelConverter.convertQueryRecursive(SqlToRelConverter.java:3180)
at
org.apache.calcite.sql2rel.SqlToRelConverter.convertQuery(SqlToRelConverter.java:563)
...
{code}
When SqlBinaryOperator figuring out its {{Monotonicity}}, if the second operand
is a Literal, it will cast the literal into BigDecimal. But the {{Null}}
Literal is not properly handled.
was:
The problem can be reproduced by the following test case in ReflectiveSchemaTest
{code:java}
@Test public void testDivideNull() {
final CalciteAssert.AssertThat with =
CalciteAssert.that().withSchema("s", CATCHALL);
with.query("select \"wrapperLong\" / null as c\n"
+ " from \"s\".\"everyTypes\"")
.runs();
}{code}
The stacktrace is
{code:java}
java.lang.AssertionError: cannot cast null as class java.math.BigDecimal
at org.apache.calcite.sql.SqlLiteral.getValueAs(SqlLiteral.java:351)
at
org.apache.calcite.sql.SqlCallBinding.getOperandLiteralValue(SqlCallBinding.java:217)
at
org.apache.calcite.sql.SqlBinaryOperator.getMonotonicity(SqlBinaryOperator.java:190)
at org.apache.calcite.sql.SqlCall.getMonotonicity(SqlCall.java:182)
at
org.apache.calcite.sql.SqlCallBinding.getOperandMonotonicity(SqlCallBinding.java:188)
at org.apache.calcite.sql.SqlAsOperator.getMonotonicity(SqlAsOperator.java:139)
at org.apache.calcite.sql.SqlCall.getMonotonicity(SqlCall.java:182)
at
org.apache.calcite.sql2rel.SqlToRelConverter.convertSelectList(SqlToRelConverter.java:3961)
at
org.apache.calcite.sql2rel.SqlToRelConverter.convertSelectImpl(SqlToRelConverter.java:670)
at
org.apache.calcite.sql2rel.SqlToRelConverter.convertSelect(SqlToRelConverter.java:627)
at
org.apache.calcite.sql2rel.SqlToRelConverter.convertQueryRecursive(SqlToRelConverter.java:3180)
at
org.apache.calcite.sql2rel.SqlToRelConverter.convertQuery(SqlToRelConverter.java:563)
...
{code}
When SqlBinaryOperator figuring out its {{Monotonicity}}, if the second operand
is a Literal, it will cast the literal into BigDecimal. But the {{Null}}
Literal can not be properly handled.
> Query failed with AssertionError: cannot cast null as class
> java.math.BigDecimal
>
>
> Key: CALCITE-3332
> URL: https://issues.apache.org/jira/browse/CALCITE-3332
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.21.0
>Reporter: Feng Zhu
>Priority: Major
>
> The problem can be reproduced by the following test case in
> ReflectiveSchemaTest
> {code:java}
> @Test public void testDivideNull() {
>final CalciteAssert.AssertThat with =
>CalciteAssert.that().withSchema("s", CATCHALL);
>with.query("select \"wrapperLong\" / null as c\n"
> + " from \"s\".\"everyTypes\"")
>.runs();
> }{code}
> The stacktrace is
> {code:java}
> java.lang.AssertionError: cannot cast null as class java.math.BigDecimal
> at org.apache.calcite.sql.SqlLiteral.getValueAs(SqlLiteral.java:351)
> at
> org.apache.calcite.sql.SqlCallBinding.getOperandLiteralValue(SqlCallBinding.java:217)
> at
> org.apache.calcite.sql.SqlBinaryOperator.getMonotonicity(SqlBinaryOperator.java:190)
> at org.apache.calcite.sql.SqlCall.getMonotonicity(SqlCall.java:182)
> at
>
[jira] [Updated] (CALCITE-3332) Query failed with AssertionError: cannot cast null as class java.math.BigDecimal
[
https://issues.apache.org/jira/browse/CALCITE-3332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Feng Zhu updated CALCITE-3332:
--
Description:
The problem can be reproduced by the following test case in ReflectiveSchemaTest
{code:java}
@Test public void testDivideNull() {
final CalciteAssert.AssertThat with =
CalciteAssert.that().withSchema("s", CATCHALL);
with.query("select \"wrapperLong\" / null as c\n"
+ " from \"s\".\"everyTypes\"")
.runs();
}{code}
The stacktrace is
{code:java}
java.lang.AssertionError: cannot cast null as class java.math.BigDecimal
at org.apache.calcite.sql.SqlLiteral.getValueAs(SqlLiteral.java:351)
at
org.apache.calcite.sql.SqlCallBinding.getOperandLiteralValue(SqlCallBinding.java:217)
at
org.apache.calcite.sql.SqlBinaryOperator.getMonotonicity(SqlBinaryOperator.java:190)
at org.apache.calcite.sql.SqlCall.getMonotonicity(SqlCall.java:182)
at
org.apache.calcite.sql.SqlCallBinding.getOperandMonotonicity(SqlCallBinding.java:188)
at org.apache.calcite.sql.SqlAsOperator.getMonotonicity(SqlAsOperator.java:139)
at org.apache.calcite.sql.SqlCall.getMonotonicity(SqlCall.java:182)
at
org.apache.calcite.sql2rel.SqlToRelConverter.convertSelectList(SqlToRelConverter.java:3961)
at
org.apache.calcite.sql2rel.SqlToRelConverter.convertSelectImpl(SqlToRelConverter.java:670)
at
org.apache.calcite.sql2rel.SqlToRelConverter.convertSelect(SqlToRelConverter.java:627)
at
org.apache.calcite.sql2rel.SqlToRelConverter.convertQueryRecursive(SqlToRelConverter.java:3180)
at
org.apache.calcite.sql2rel.SqlToRelConverter.convertQuery(SqlToRelConverter.java:563)
...
{code}
When SqlBinaryOperator figuring out its {{Monotonicity}}, if the second operand
is a Literal, it will cast the literal into BigDecimal. But the {{Null}}
Literal can not be properly handled.
was:
The problem can be reproduced by the following test case in ReflectiveSchemaTest
{code:java}
@Test public void testDivideNull() {
final CalciteAssert.AssertThat with =
CalciteAssert.that().withSchema("s", CATCHALL);
with.query("select \"wrapperLong\" / null as c\n"
+ " from \"s\".\"everyTypes\"")
.runs();
}{code}
The stacktrace is
{code:java}
java.lang.AssertionError: cannot cast null as class java.math.BigDecimal
at org.apache.calcite.sql.SqlLiteral.getValueAs(SqlLiteral.java:351)
at
org.apache.calcite.sql.SqlCallBinding.getOperandLiteralValue(SqlCallBinding.java:217)
at
org.apache.calcite.sql.SqlBinaryOperator.getMonotonicity(SqlBinaryOperator.java:190)
at org.apache.calcite.sql.SqlCall.getMonotonicity(SqlCall.java:182)
at
org.apache.calcite.sql.SqlCallBinding.getOperandMonotonicity(SqlCallBinding.java:188)
at org.apache.calcite.sql.SqlAsOperator.getMonotonicity(SqlAsOperator.java:139)
at org.apache.calcite.sql.SqlCall.getMonotonicity(SqlCall.java:182)
at
org.apache.calcite.sql2rel.SqlToRelConverter.convertSelectList(SqlToRelConverter.java:3961)
at
org.apache.calcite.sql2rel.SqlToRelConverter.convertSelectImpl(SqlToRelConverter.java:670)
at
org.apache.calcite.sql2rel.SqlToRelConverter.convertSelect(SqlToRelConverter.java:627)
at
org.apache.calcite.sql2rel.SqlToRelConverter.convertQueryRecursive(SqlToRelConverter.java:3180)
at
org.apache.calcite.sql2rel.SqlToRelConverter.convertQuery(SqlToRelConverter.java:563)
{code}
When SqlBinaryOperator figuring out its {{Monotonicity}}, if the second operand
is a Literal, it will cast the literal into BigDecimal. But the {{Null}}
Literal can not be properly handled.
> Query failed with AssertionError: cannot cast null as class
> java.math.BigDecimal
>
>
> Key: CALCITE-3332
> URL: https://issues.apache.org/jira/browse/CALCITE-3332
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.21.0
>Reporter: Feng Zhu
>Priority: Major
>
> The problem can be reproduced by the following test case in
> ReflectiveSchemaTest
> {code:java}
> @Test public void testDivideNull() {
>final CalciteAssert.AssertThat with =
>CalciteAssert.that().withSchema("s", CATCHALL);
>with.query("select \"wrapperLong\" / null as c\n"
> + " from \"s\".\"everyTypes\"")
>.runs();
> }{code}
> The stacktrace is
> {code:java}
> java.lang.AssertionError: cannot cast null as class java.math.BigDecimal
> at org.apache.calcite.sql.SqlLiteral.getValueAs(SqlLiteral.java:351)
> at
> org.apache.calcite.sql.SqlCallBinding.getOperandLiteralValue(SqlCallBinding.java:217)
> at
> org.apache.calcite.sql.SqlBinaryOperator.getMonotonicity(SqlBinaryOperator.java:190)
> at org.apache.calcite.sql.SqlCall.getMonotonicity(SqlCall.java:182)
> at
> org.apache.calcite.sql.SqlCallBinding.getOperandMonotonicity(SqlCallBinding.java:188)
> at
>
[jira] [Updated] (CALCITE-3332) Query failed with AssertionError: cannot cast null as class java.math.BigDecimal
[
https://issues.apache.org/jira/browse/CALCITE-3332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Feng Zhu updated CALCITE-3332:
--
Description:
The problem can be reproduced by the following test case in ReflectiveSchemaTest
{code:java}
@Test public void testDivideNull() {
final CalciteAssert.AssertThat with =
CalciteAssert.that().withSchema("s", CATCHALL);
with.query("select \"wrapperLong\" / null as c\n"
+ " from \"s\".\"everyTypes\"")
.runs();
}{code}
The stacktrace is
{code:java}
java.lang.AssertionError: cannot cast null as class java.math.BigDecimal
at org.apache.calcite.sql.SqlLiteral.getValueAs(SqlLiteral.java:351)
at
org.apache.calcite.sql.SqlCallBinding.getOperandLiteralValue(SqlCallBinding.java:217)
at
org.apache.calcite.sql.SqlBinaryOperator.getMonotonicity(SqlBinaryOperator.java:190)
at org.apache.calcite.sql.SqlCall.getMonotonicity(SqlCall.java:182)
at
org.apache.calcite.sql.SqlCallBinding.getOperandMonotonicity(SqlCallBinding.java:188)
at org.apache.calcite.sql.SqlAsOperator.getMonotonicity(SqlAsOperator.java:139)
at org.apache.calcite.sql.SqlCall.getMonotonicity(SqlCall.java:182)
at
org.apache.calcite.sql2rel.SqlToRelConverter.convertSelectList(SqlToRelConverter.java:3961)
at
org.apache.calcite.sql2rel.SqlToRelConverter.convertSelectImpl(SqlToRelConverter.java:670)
at
org.apache.calcite.sql2rel.SqlToRelConverter.convertSelect(SqlToRelConverter.java:627)
at
org.apache.calcite.sql2rel.SqlToRelConverter.convertQueryRecursive(SqlToRelConverter.java:3180)
at
org.apache.calcite.sql2rel.SqlToRelConverter.convertQuery(SqlToRelConverter.java:563)
{code}
When SqlBinaryOperator figuring out its {{Monotonicity}}, if the second operand
is a Literal, it will cast the literal into BigDecimal. But the {{Null}}
Literal can not be properly handled.
was:
The problem can be reproduced by the following test case in ReflectiveSchemaTest
{code:java}
@Test public void testDivideNull() {
final CalciteAssert.AssertThat with =
CalciteAssert.that().withSchema("s", CATCHALL);
with.query("select \"wrapperLong\" / null as c\n"
+ " from \"s\".\"everyTypes\"")
.runs();
}{code}
The stacktrace is
{code:java}
java.lang.AssertionError: cannot cast null as class java.math.BigDecimal
at org.apache.calcite.sql.SqlLiteral.getValueAs(SqlLiteral.java:351)
at
org.apache.calcite.sql.SqlCallBinding.getOperandLiteralValue(SqlCallBinding.java:217)
at
org.apache.calcite.sql.SqlBinaryOperator.getMonotonicity(SqlBinaryOperator.java:190)
at org.apache.calcite.sql.SqlCall.getMonotonicity(SqlCall.java:182)
at
org.apache.calcite.sql.SqlCallBinding.getOperandMonotonicity(SqlCallBinding.java:188)
at org.apache.calcite.sql.SqlAsOperator.getMonotonicity(SqlAsOperator.java:139)
at org.apache.calcite.sql.SqlCall.getMonotonicity(SqlCall.java:182)
at
org.apache.calcite.sql2rel.SqlToRelConverter.convertSelectList(SqlToRelConverter.java:3961)
at
org.apache.calcite.sql2rel.SqlToRelConverter.convertSelectImpl(SqlToRelConverter.java:670)
at
org.apache.calcite.sql2rel.SqlToRelConverter.convertSelect(SqlToRelConverter.java:627)
at
org.apache.calcite.sql2rel.SqlToRelConverter.convertQueryRecursive(SqlToRelConverter.java:3180)
at
org.apache.calcite.sql2rel.SqlToRelConverter.convertQuery(SqlToRelConverter.java:563)
{code}
When SqlBinaryOperator figuring out its {{Monotonicity}}, if the second operand
is a Literal, it will cast the literal into BigDecimal. But the {{Null}}
Literal can not be properly handled.
> Query failed with AssertionError: cannot cast null as class
> java.math.BigDecimal
>
>
> Key: CALCITE-3332
> URL: https://issues.apache.org/jira/browse/CALCITE-3332
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.21.0
>Reporter: Feng Zhu
>Priority: Major
>
> The problem can be reproduced by the following test case in
> ReflectiveSchemaTest
> {code:java}
> @Test public void testDivideNull() {
>final CalciteAssert.AssertThat with =
>CalciteAssert.that().withSchema("s", CATCHALL);
>with.query("select \"wrapperLong\" / null as c\n"
> + " from \"s\".\"everyTypes\"")
>.runs();
> }{code}
> The stacktrace is
> {code:java}
> java.lang.AssertionError: cannot cast null as class java.math.BigDecimal
> at org.apache.calcite.sql.SqlLiteral.getValueAs(SqlLiteral.java:351)
> at
> org.apache.calcite.sql.SqlCallBinding.getOperandLiteralValue(SqlCallBinding.java:217)
> at
> org.apache.calcite.sql.SqlBinaryOperator.getMonotonicity(SqlBinaryOperator.java:190)
> at org.apache.calcite.sql.SqlCall.getMonotonicity(SqlCall.java:182)
> at
> org.apache.calcite.sql.SqlCallBinding.getOperandMonotonicity(SqlCallBinding.java:188)
> at
>
[jira] [Created] (CALCITE-3332) Query failed with AssertionError: cannot cast null as class java.math.BigDecimal
Feng Zhu created CALCITE-3332:
-
Summary: Query failed with AssertionError: cannot cast null as
class java.math.BigDecimal
Key: CALCITE-3332
URL: https://issues.apache.org/jira/browse/CALCITE-3332
Project: Calcite
Issue Type: Bug
Components: core
Affects Versions: 1.21.0
Reporter: Feng Zhu
The problem can be reproduced by the following test case in ReflectiveSchemaTest
{code:java}
@Test public void testDivideNull() {
final CalciteAssert.AssertThat with =
CalciteAssert.that().withSchema("s", CATCHALL);
with.query("select \"wrapperLong\" / null as c\n"
+ " from \"s\".\"everyTypes\"")
.runs();
}{code}
The stacktrace is
{code:java}
java.lang.AssertionError: cannot cast null as class java.math.BigDecimal
at org.apache.calcite.sql.SqlLiteral.getValueAs(SqlLiteral.java:351)
at
org.apache.calcite.sql.SqlCallBinding.getOperandLiteralValue(SqlCallBinding.java:217)
at
org.apache.calcite.sql.SqlBinaryOperator.getMonotonicity(SqlBinaryOperator.java:190)
at org.apache.calcite.sql.SqlCall.getMonotonicity(SqlCall.java:182)
at
org.apache.calcite.sql.SqlCallBinding.getOperandMonotonicity(SqlCallBinding.java:188)
at org.apache.calcite.sql.SqlAsOperator.getMonotonicity(SqlAsOperator.java:139)
at org.apache.calcite.sql.SqlCall.getMonotonicity(SqlCall.java:182)
at
org.apache.calcite.sql2rel.SqlToRelConverter.convertSelectList(SqlToRelConverter.java:3961)
at
org.apache.calcite.sql2rel.SqlToRelConverter.convertSelectImpl(SqlToRelConverter.java:670)
at
org.apache.calcite.sql2rel.SqlToRelConverter.convertSelect(SqlToRelConverter.java:627)
at
org.apache.calcite.sql2rel.SqlToRelConverter.convertQueryRecursive(SqlToRelConverter.java:3180)
at
org.apache.calcite.sql2rel.SqlToRelConverter.convertQuery(SqlToRelConverter.java:563)
{code}
When SqlBinaryOperator figuring out its {{Monotonicity}}, if the second operand
is a Literal, it will cast the literal into BigDecimal. But the {{Null}}
Literal can not be properly handled.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Updated] (CALCITE-3331) Support implicit type cast for single operand family checker
[ https://issues.apache.org/jira/browse/CALCITE-3331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Danny Chan updated CALCITE-3331: Description: When the FamilyOperandTypeChecker is used to check single operand data type, support implicit type coercion if we can. Now some of the sql operator override method #checkOperandTypes, and use the SqlSingleOperandTypeChecker#checkSingleOperandType to check the operand data type, we should support the implicit type coercion for these operators. One impl that need to note: we seem always pass the "iformalOperand" as "0" with method SqlSingleOperandTypeChecker#checkSingleOperandType when check the single operand, we need to pass in the real operand index in the call to the checker. was: When the FamilyOperandTypeChecker is used to check single operand data type, support implicit type coercion if we can. Now some of the sql operator override method #checkOperandTypes, and use the SqlSingleOperandTypeChecker#checkSingleOperandType to check the operand data type, we should support the implicit type coercion for these operators. > Support implicit type cast for single operand family checker > > > Key: CALCITE-3331 > URL: https://issues.apache.org/jira/browse/CALCITE-3331 > Project: Calcite > Issue Type: Improvement > Components: core >Affects Versions: 1.20.0 >Reporter: Danny Chan >Assignee: Danny Chan >Priority: Minor > Fix For: 1.22.0 > > > When the FamilyOperandTypeChecker is used to check single operand data type, > support implicit type coercion if we can. > Now some of the sql operator override method #checkOperandTypes, and use the > SqlSingleOperandTypeChecker#checkSingleOperandType to check the operand data > type, we should support the implicit type coercion for these operators. > One impl that need to note: > we seem always pass the "iformalOperand" as "0" with method > SqlSingleOperandTypeChecker#checkSingleOperandType when check the single > operand, we need to pass in the real operand index in the call to the checker. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Created] (CALCITE-3331) Support implicit type cast for single operand family checker
Danny Chan created CALCITE-3331: --- Summary: Support implicit type cast for single operand family checker Key: CALCITE-3331 URL: https://issues.apache.org/jira/browse/CALCITE-3331 Project: Calcite Issue Type: Improvement Components: core Affects Versions: 1.20.0 Reporter: Danny Chan Assignee: Danny Chan Fix For: 1.22.0 When the FamilyOperandTypeChecker is used to check single operand data type, support implicit type coercion if we can. Now some of the sql operator override method #checkOperandTypes, and use the SqlSingleOperandTypeChecker#checkSingleOperandType to check the operand data type, we should support the implicit type coercion for these operators. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Updated] (CALCITE-3329) Implement osquery for OS adapter
[ https://issues.apache.org/jira/browse/CALCITE-3329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Forward Xu updated CALCITE-3329: Description: Implement osquery command for OS adapter, Achieve similar features of FaceBook's osquery. E.g: select * from os_version; select * from system_info; select * from mounts; select * from interface_addresses select * from memory_info; select * from interface_addresses; select * from cpu_info; select * from java_info; was: Implement osquery command for OS adapter, Achieve similar features of FaceBook's osquery. E.g: select * from os_version; select * from system_info; select * from mounts; select * from interface_addresses select * from memory_info; select * from interface_addresses; select cpu_info.* from cpu_info; > Implement osquery for OS adapter > > > Key: CALCITE-3329 > URL: https://issues.apache.org/jira/browse/CALCITE-3329 > Project: Calcite > Issue Type: New Feature >Reporter: Forward Xu >Assignee: Forward Xu >Priority: Major > Labels: pull-request-available > Attachments: 2016021823310.png, 20160218233139164.png, > image-2019-09-09-08-27-56-974.png, image-2019-09-09-08-33-41-411.png > > Time Spent: 40m > Remaining Estimate: 0h > > Implement osquery command for OS adapter, Achieve similar features of > FaceBook's osquery. E.g: > select * from os_version; > select * from system_info; > select * from mounts; > select * from interface_addresses > select * from memory_info; > select * from interface_addresses; > select * from cpu_info; > select * from java_info; -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (CALCITE-3330) propagateCostImprovements() could result in stack overflow
[ https://issues.apache.org/jira/browse/CALCITE-3330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16925409#comment-16925409 ] Chunwei Lei commented on CALCITE-3330: -- It seems to be the same with CALCITE-2204. > propagateCostImprovements() could result in stack overflow > -- > > Key: CALCITE-3330 > URL: https://issues.apache.org/jira/browse/CALCITE-3330 > Project: Calcite > Issue Type: Bug >Reporter: Xiening Dai >Assignee: Xiening Dai >Priority: Major > Labels: pull-request-available > Time Spent: 20m > Remaining Estimate: 0h > > Current implementation uses depth first approach for propagating cost > improvements to parent rel nodes. This could lead to stack overflow if the > rel node hierarchy is very deep. Suggest use breath first approach for cost > propagation. -- This message was sent by Atlassian Jira (v8.3.2#803003)
