[jira] [Commented] (CALCITE-2677) Struct types with one field are not mapped correctly to Java Classes
[ https://issues.apache.org/jira/browse/CALCITE-2677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16708268#comment-16708268 ] Stamatis Zampetakis commented on CALCITE-2677: -- I tried to illustrate the problem with a few a simple unit tests. Without the fix the returned type is not the expected one which can lead to exceptions when we execute queries with field accesses involving structs with one field. > Struct types with one field are not mapped correctly to Java Classes > > > Key: CALCITE-2677 > URL: https://issues.apache.org/jira/browse/CALCITE-2677 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.17.0 >Reporter: Stamatis Zampetakis >Assignee: Julian Hyde >Priority: Major > Labels: easy-fix, pull-request-available > Fix For: 1.18.0 > > > There are various places in the code where given a RelDataType we need to > obtain the respective Java Class/Type. This is done mainly through > JavaTypeFactory#getJavaClass. For the Calcite runtime it passes through > PhysType#fieldClass and PhysType#getJavaFieldType. > However, when the RelDataType is a struct of one field the returned > Class/Type is not the correct one since the struct type is simplified to the > type of its component. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-2662) Planner: allow parsing directly a stream instead of a java.lang.String
[ https://issues.apache.org/jira/browse/CALCITE-2662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16708236#comment-16708236 ] Enrico Olivelli commented on CALCITE-2662: -- Thank you Julian and Vladmin for review > Planner: allow parsing directly a stream instead of a java.lang.String > -- > > Key: CALCITE-2662 > URL: https://issues.apache.org/jira/browse/CALCITE-2662 > Project: Calcite > Issue Type: Improvement > Components: core >Affects Versions: 1.17.0 >Reporter: Enrico Olivelli >Assignee: Julian Hyde >Priority: Major > Fix For: 1.18.0 > > > In 1.17.0 the org.apache.calcite.tools.Planner interface only accept a > java.lang.String as input. > In order to reduce memory allocations and copies it will be useful that the > planner could accept the query in a more 'raw' format. > Creating a java.lang.String is very expensive, and if your "query" is coming > from the network (think about a Netty Direct memory ByteBuf) you are forced > to create a copy of the text of the query. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-2468) Validator throws IndexOutOfBoundsException when trying to infer operand type from struct return type
[
https://issues.apache.org/jira/browse/CALCITE-2468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16708094#comment-16708094
]
Rong Rong commented on CALCITE-2468:
Hi [~julianhyde], sorry I somehow missed the 2nd part of your last comment. You
are right, recursive is obviously more elegant! I just changed the code and
remove the TODO ( no longer needed ). please kindly take another look.
> Validator throws IndexOutOfBoundsException when trying to infer operand type
> from struct return type
>
>
> Key: CALCITE-2468
> URL: https://issues.apache.org/jira/browse/CALCITE-2468
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.17.0
>Reporter: Rong Rong
>Assignee: Julian Hyde
>Priority: Major
>
> IOOBE was thrown when trying to acquire {{SqlOperandTypeInference}} using
> {{RETURN_TYPE}} at:
> https://github.com/apache/calcite/blob/branch-1.17/core/src/main/java/org/apache/calcite/sql/type/InferTypes.java#L68
> The follow SQLs demonstrates how to trigger the exception over a simple
> Schema:
> {code:yaml}
> - table1:
> - structType1:
> - intField
> - structType2:
> - intField
> - bigintField
> {code}
> - Exception SQL:
> {code:sql}
> SELECT structType1 AS myStructType FROM table1
> {code}
> - Correct SQL:
> {code:sql}
> SELECT structType1 FROM table1
> {code}
> {code:sql}
> SELECT structType2 AS myStructType FROM table1
> {code}
> E2E example can be found in:
> https://github.com/apache/calcite/commit/d5fb1f9fc5d3f9583128d9ee35c4a23e8470d54d
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2658) Introducing more ReduceExpressionRules
[ https://issues.apache.org/jira/browse/CALCITE-2658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16708091#comment-16708091 ] Julian Hyde commented on CALCITE-2658: -- Reviewing PR 912 WindowReduceExpressionsRule: * Can you please split either 912 or 921 into a separate JIRA case? * The code looks good, but the test case only tests removing ORDER BY keys if they are already in PARTITION BY. It doesn't test constant reduction. Can you add a test for that? * I think you should add the rule to CalcitePrepareImpl.CONSTANT_REDUCTION_RULES, alongside the likes of ReduceExpressionsRule.CALC_INSTANCE, so that the rule will be applied by default. > Introducing more ReduceExpressionRules > -- > > Key: CALCITE-2658 > URL: https://issues.apache.org/jira/browse/CALCITE-2658 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.17.0 >Reporter: Chunwei Lei >Assignee: Julian Hyde >Priority: Major > Fix For: 1.18.0 > > > It is useful to have rules reducing Exchange/Sort/SortExchange keys, e.g., > SELECT key,value FROM (SELECT 1 AS key, value FROM src) r DISTRIBUTE BY key; > can be reduced to > SELECT 1 AS key, value FROM src;# Since singleton requirement may already > required by SELECT. > SELECT key,value FROM (SELECT 1 AS key, value FROM src) r ORDER BY key; > can be reduced to > SELECT 1 AS key, value FROM src;# Since ordering on constant is useless. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (CALCITE-2658) Introducing more ReduceExpressionRules
[
https://issues.apache.org/jira/browse/CALCITE-2658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16708078#comment-16708078
]
Julian Hyde edited comment on CALCITE-2658 at 12/4/18 2:03 AM:
---
Reviewing PR 921 ExchangeRemoveConstantKeysRule:
* You have mutable state inside the rule, {{hashDistribution}}. Can you remove
that? Rule instances need to be thread-safe.
* I think you should change Distributions.hash to return a singleton
distribution if the keys are empty (and change its javadoc).
* Can you add more description to the rules' javadoc about what 'removing
constant keys' means. Maybe a SQL example.
* Maybe I'm paranoid, but simplifyDistributionKeys seems to be allocating
rather a lot of objects. Rather than speculatively creating {{RexInputRef}}
objects, could you look for constants of type {{RexInputRef}} and then see
whether that bit is a distribution key. And check whether you can simplify
before you start to simplify.
was (Author: julianhyde):
Reviewing PR 921 ExchangeRemoveConstantKeysRule:
* You have mutable state inside the rule, {{hashDistribution}}. Can you remove
that? Rule instances need to be thread-safe.
* I think you should change Distributions.hash to return a singleton
distribution if the keys are empty (and change its javadoc).
* Can you add more description to the rules' javadoc about what 'removing
constant keys' means. Maybe a SQL example.
* Maybe I'm paranoid, but simplifyDistributionKeys seems to be allocating
rather a lot of objects. Rather than speculatively creating {{RexInputRef}}s,
could you look for {{RexInputRef}}s that are constants and then see whether
that bit is set in the distribution. And check whether you can simplify before
you start to simplify.
> Introducing more ReduceExpressionRules
> --
>
> Key: CALCITE-2658
> URL: https://issues.apache.org/jira/browse/CALCITE-2658
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.17.0
>Reporter: Chunwei Lei
>Assignee: Julian Hyde
>Priority: Major
> Fix For: 1.18.0
>
>
> It is useful to have rules reducing Exchange/Sort/SortExchange keys, e.g.,
> SELECT key,value FROM (SELECT 1 AS key, value FROM src) r DISTRIBUTE BY key;
> can be reduced to
> SELECT 1 AS key, value FROM src;# Since singleton requirement may already
> required by SELECT.
> SELECT key,value FROM (SELECT 1 AS key, value FROM src) r ORDER BY key;
> can be reduced to
> SELECT 1 AS key, value FROM src;# Since ordering on constant is useless.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2658) Introducing more ReduceExpressionRules
[
https://issues.apache.org/jira/browse/CALCITE-2658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16708078#comment-16708078
]
Julian Hyde commented on CALCITE-2658:
--
Reviewing PR 921 ExchangeRemoveConstantKeysRule:
* You have mutable state inside the rule, {{hashDistribution}}. Can you remove
that? Rule instances need to be thread-safe.
* I think you should change Distributions.hash to return a singleton
distribution if the keys are empty (and change its javadoc).
* Can you add more description to the rules' javadoc about what 'removing
constant keys' means. Maybe a SQL example.
* Maybe I'm paranoid, but simplifyDistributionKeys seems to be allocating
rather a lot of objects. Rather than speculatively creating {{RexInputRef}}s,
could you look for {{RexInputRef}}s that are constants and then see whether
that bit is set in the distribution. And check whether you can simplify before
you start to simplify.
> Introducing more ReduceExpressionRules
> --
>
> Key: CALCITE-2658
> URL: https://issues.apache.org/jira/browse/CALCITE-2658
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.17.0
>Reporter: Chunwei Lei
>Assignee: Julian Hyde
>Priority: Major
> Fix For: 1.18.0
>
>
> It is useful to have rules reducing Exchange/Sort/SortExchange keys, e.g.,
> SELECT key,value FROM (SELECT 1 AS key, value FROM src) r DISTRIBUTE BY key;
> can be reduced to
> SELECT 1 AS key, value FROM src;# Since singleton requirement may already
> required by SELECT.
> SELECT key,value FROM (SELECT 1 AS key, value FROM src) r ORDER BY key;
> can be reduced to
> SELECT 1 AS key, value FROM src;# Since ordering on constant is useless.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2677) Struct types with one field are not mapped correctly to Java Classes
[ https://issues.apache.org/jira/browse/CALCITE-2677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16708063#comment-16708063 ] Julian Hyde commented on CALCITE-2677: -- It depends on your definition of "correct". > Struct types with one field are not mapped correctly to Java Classes > > > Key: CALCITE-2677 > URL: https://issues.apache.org/jira/browse/CALCITE-2677 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.17.0 >Reporter: Stamatis Zampetakis >Assignee: Julian Hyde >Priority: Major > Labels: easy-fix, pull-request-available > Fix For: 1.18.0 > > > There are various places in the code where given a RelDataType we need to > obtain the respective Java Class/Type. This is done mainly through > JavaTypeFactory#getJavaClass. For the Calcite runtime it passes through > PhysType#fieldClass and PhysType#getJavaFieldType. > However, when the RelDataType is a struct of one field the returned > Class/Type is not the correct one since the struct type is simplified to the > type of its component. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-2468) Validator throws IndexOutOfBoundsException when trying to infer operand type from struct return type
[
https://issues.apache.org/jira/browse/CALCITE-2468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16708045#comment-16708045
]
Julian Hyde commented on CALCITE-2468:
--
Did you try recursing? The code for AS still looks very brittle. Also, there is
one more TODO than before, which I find worrying.
> Validator throws IndexOutOfBoundsException when trying to infer operand type
> from struct return type
>
>
> Key: CALCITE-2468
> URL: https://issues.apache.org/jira/browse/CALCITE-2468
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.17.0
>Reporter: Rong Rong
>Assignee: Julian Hyde
>Priority: Major
>
> IOOBE was thrown when trying to acquire {{SqlOperandTypeInference}} using
> {{RETURN_TYPE}} at:
> https://github.com/apache/calcite/blob/branch-1.17/core/src/main/java/org/apache/calcite/sql/type/InferTypes.java#L68
> The follow SQLs demonstrates how to trigger the exception over a simple
> Schema:
> {code:yaml}
> - table1:
> - structType1:
> - intField
> - structType2:
> - intField
> - bigintField
> {code}
> - Exception SQL:
> {code:sql}
> SELECT structType1 AS myStructType FROM table1
> {code}
> - Correct SQL:
> {code:sql}
> SELECT structType1 FROM table1
> {code}
> {code:sql}
> SELECT structType2 AS myStructType FROM table1
> {code}
> E2E example can be found in:
> https://github.com/apache/calcite/commit/d5fb1f9fc5d3f9583128d9ee35c4a23e8470d54d
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CALCITE-2719) MySQL does not support cast to BIGINT type
[ https://issues.apache.org/jira/browse/CALCITE-2719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Hyde updated CALCITE-2719: - Summary: MySQL does not support cast to BIGINT type (was: MySQL does not support cast to bigint type) > MySQL does not support cast to BIGINT type > -- > > Key: CALCITE-2719 > URL: https://issues.apache.org/jira/browse/CALCITE-2719 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.17.0 >Reporter: Piotr Bojko >Assignee: Julian Hyde >Priority: Major > > Cast to BIGING is not supported in MySQL. The trick is to use CAST to SIGNED > INT. > When accepted I will try to fix this. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (CALCITE-2709) GeodeFilter Support for temporal types and searches (DATE, TIME, TIMESTAMP etc.)
[ https://issues.apache.org/jira/browse/CALCITE-2709?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Hyde resolved CALCITE-2709. -- Resolution: Fixed Fix Version/s: 1.18.0 Fixed in [be5404713|http://git-wip-us.apache.org/repos/asf/calcite/commit/be5404713]; thanks for the PR, [~chadasa-gs]! > GeodeFilter Support for temporal types and searches (DATE, TIME, TIMESTAMP > etc.) > > > Key: CALCITE-2709 > URL: https://issues.apache.org/jira/browse/CALCITE-2709 > Project: Calcite > Issue Type: Improvement > Components: geode >Reporter: Sandeep Chada >Assignee: Julian Hyde >Priority: Major > Fix For: 1.18.0 > > > Right now we cannot search for field like DATE, TIME, TIMESTAMP in > GeodeFilter. > This change in GeodeFilter will allow to search by the temporal data types -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (CALCITE-2619) Reduce string literal creation cost by removing unnecessary charset check
[ https://issues.apache.org/jira/browse/CALCITE-2619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16706429#comment-16706429 ] Julian Hyde edited comment on CALCITE-2619 at 12/4/18 12:46 AM: Fixed in [69750ff7|http://git-wip-us.apache.org/repos/asf/calcite/commit/69750ff7]; thanks for the PR, [~tedxu]! I made some changes to your PR. I changed the two public NlsString constructors to use the same private constructor, made all fields final (so NlsString is now immutable), and obsoleted your ByteString class, using instead a pair of Avatica's ByteString and a Charset in the cache. (Your ByteString had a charset, while Avatica's ByteString only has an array of bytes.) Lastly, I made your cache static; a non-static cache would have been useless. was (Author: julianhyde): Fixed in [36bd5fb2|http://git-wip-us.apache.org/repos/asf/calcite/commit/36bd5fb2]; thanks for the PR, [~tedxu]! I made some changes to your PR. I changed the two public NlsString constructors to use the same private constructor, made all fields final (so NlsString is now immutable), and obsoleted your ByteString class, using instead a pair of Avatica's ByteString and a Charset in the cache. (Your ByteString had a charset, while Avatica's ByteString only has an array of bytes.) Lastly, I made your cache static; a non-static cache would have been useless. > Reduce string literal creation cost by removing unnecessary charset check > - > > Key: CALCITE-2619 > URL: https://issues.apache.org/jira/browse/CALCITE-2619 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: Ted Xu >Assignee: Julian Hyde >Priority: Major > Fix For: 1.18.0 > > > The cost of creating NlsString is very high, due to its charset check. In > some cases, e.g., expression evaluate because of Partition Prune, the > NlsString creation costs 40%+ of total executor's overhead. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (CALCITE-2529) linq4j should promote integer to floating point when generating function calls
[ https://issues.apache.org/jira/browse/CALCITE-2529?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Hyde resolved CALCITE-2529. -- Resolution: Fixed Fixed in [25c332d6|http://git-wip-us.apache.org/repos/asf/calcite/commit/25c332d6]. > linq4j should promote integer to floating point when generating function calls > -- > > Key: CALCITE-2529 > URL: https://issues.apache.org/jira/browse/CALCITE-2529 > Project: Calcite > Issue Type: Improvement >Reporter: Andrew Pilloud >Assignee: Julian Hyde >Priority: Major > Fix For: 1.18.0 > > > For example, I get "RuntimeException: while resolving method 'atan2[double, > int]'" when trying to execute a query with "ATAN2(c_double, 2)" (where > c_double is a column containing the double type). atan2[double, double] > should resolve as a valid implementation in this case. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (CALCITE-2662) Planner: allow parsing directly a stream instead of a java.lang.String
[ https://issues.apache.org/jira/browse/CALCITE-2662?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Hyde resolved CALCITE-2662. -- Resolution: Fixed Fixed in [03c88b69|http://git-wip-us.apache.org/repos/asf/calcite/commit/03c88b69]; thanks for the PR, [~eolivelli]! > Planner: allow parsing directly a stream instead of a java.lang.String > -- > > Key: CALCITE-2662 > URL: https://issues.apache.org/jira/browse/CALCITE-2662 > Project: Calcite > Issue Type: Improvement > Components: core >Affects Versions: 1.17.0 >Reporter: Enrico Olivelli >Assignee: Julian Hyde >Priority: Major > Fix For: 1.18.0 > > > In 1.17.0 the org.apache.calcite.tools.Planner interface only accept a > java.lang.String as input. > In order to reduce memory allocations and copies it will be useful that the > planner could accept the query in a more 'raw' format. > Creating a java.lang.String is very expensive, and if your "query" is coming > from the network (think about a Netty Direct memory ByteBuf) you are forced > to create a copy of the text of the query. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-2688) Improve diagnosability when return type could not be inferred.
[
https://issues.apache.org/jira/browse/CALCITE-2688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16708028#comment-16708028
]
Julian Hyde commented on CALCITE-2688:
--
Fixed in
[e274f1ba|http://git-wip-us.apache.org/repos/asf/calcite/commit/e274f1ba];
thanks for the PR, [~kgyrtkirk]!
> Improve diagnosability when return type could not be inferred.
> --
>
> Key: CALCITE-2688
> URL: https://issues.apache.org/jira/browse/CALCITE-2688
> Project: Calcite
> Issue Type: Improvement
>Reporter: Zoltan Haindrich
>Assignee: Zoltan Haindrich
>Priority: Major
> Fix For: 1.18.0
>
>
> Currently when the return type inferenence fails; a {{null}} is returned;
> while leads to an NPE very quickly - the resulting Exception is not
> informative at all.
> {code}
> @Test(expected = IllegalArgumentException.class)
> public void checkNoCommonReturnTypeException() {
> coalesce(vVarchar(1), vInt(2));
> }
> {code}
> example NPE:
> {code}
> java.lang.NullPointerException
> at java.util.Objects.requireNonNull(Objects.java:203)
> at org.apache.calcite.rex.RexCall.(RexCall.java:59)
> at org.apache.calcite.rex.RexBuilder.makeCall(RexBuilder.java:242)
> at org.apache.calcite.rex.RexBuilder.makeCall(RexBuilder.java:254)
> at
> org.apache.calcite.test.RexProgramBuilderBase.coalesce(RexProgramBuilderBase.java:300)
> at
> org.apache.calcite.test.RexProgramTest.checkNoCommonReturnTypeException(RexProgramTest.java:753)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (CALCITE-2701) Ensure that the "Baz" classes generated by Janino are thread-safe
[
https://issues.apache.org/jira/browse/CALCITE-2701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16706433#comment-16706433
]
Julian Hyde edited comment on CALCITE-2701 at 12/4/18 12:46 AM:
Fixed in
[16ebc963|http://git-wip-us.apache.org/repos/asf/calcite/commit/16ebc963];
thanks for the PR, [~zabetak]!
was (Author: julianhyde):
Fixed in
[fbf193b1|http://git-wip-us.apache.org/repos/asf/calcite/commit/fbf193b1];
thanks for the PR, [~zabetak]!
> Ensure that the "Baz" classes generated by Janino are thread-safe
> -
>
> Key: CALCITE-2701
> URL: https://issues.apache.org/jira/browse/CALCITE-2701
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.17.0
>Reporter: Stamatis Zampetakis
>Assignee: Julian Hyde
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.18.0
>
>
> Currently the Baz classes that are used to execute queries in the
> EnumerableConvention are stateful since the code generated by
> EnumerableRelImplementor#implementRoot method creates an instance variable
> (i.e., DataContext root). Every call to the bind method changes the value of
> the root variable making the object mutable.
> I propose to remove the instance variable and in the body of the method use
> the DataContext passed as a parameter.
> It appears that the addition of the instance variable was a workaround for a
> bug in Janino (JANINO-169). It seems that the bug is no longer present at the
> current version of Janino used in Calcite (3.0.9) since the test
> JdbcTest#testJanino169 (and the complete suite) pass successfully with the
> proposed modification.
> Unfortunately, I couldn't verify the fix in the release notes of Janino
> neither in the commit history. The best, I could find is the following
> commits in the Janino repository:
> {code:none}
> commit fe5edc1904278c1c189f3379e06417aaf4a26315
> Author: aunkrig
> Date: Wed Jan 22 21:19:48 2014 +
> Partly fixed JANINO-169 - now you get "Compiler limitation: Initializers
> cannot access local variables declared in an enclosing block".
> commit 4d2bacf16229ac1278eafa0fb4d5a0377134d3f2
> Author: aunkrig
> Date: Wed Jan 22 15:03:17 2014 +
> Added test case for JANINO-169.
> {code}
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (CALCITE-2679) Group by without aggregation function cannot be translated to correct JSON in Elasticsearch Adapter
[
https://issues.apache.org/jira/browse/CALCITE-2679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16706432#comment-16706432
]
Julian Hyde edited comment on CALCITE-2679 at 12/4/18 12:45 AM:
Fixed in
[d7d28a27|http://git-wip-us.apache.org/repos/asf/calcite/commit/d7d28a27];
thanks for the PR, [~Functor10]!
was (Author: julianhyde):
Fixed in
[96605a86|http://git-wip-us.apache.org/repos/asf/calcite/commit/96605a86];
thanks for the PR, [~Functor10]!
> Group by without aggregation function cannot be translated to correct JSON in
> Elasticsearch Adapter
> ---
>
> Key: CALCITE-2679
> URL: https://issues.apache.org/jira/browse/CALCITE-2679
> Project: Calcite
> Issue Type: Bug
> Components: elasticsearch-adapter
>Affects Versions: 1.18.0
>Reporter: Siyuan Liu
>Assignee: Julian Hyde
>Priority: Major
> Labels: easyfix
> Fix For: 1.18.0
>
>
> The Elasticsearch Adapter of the current master branch has some problems when
> querying for group by clause without aggregation function. For example, when
> I query the following SQL:
> {code:sql}
> select state, city from zips group by state, city
> {code}
> After translation, adapter should return the following JSON:
> {code:json}
> {
> "_source": false,
> "size": 0,
> "aggregations": {
> "g_state": {
> "terms": {
> "field": "state",
> "missing": "__MISSING__"
> },
> "aggregations": {
> "g_city ": {
> "terms ": {
> "field ":"city ",
> "missing":"__MISSING__ "
> }
> }
> }
> }
> }
> }
> {code}
> But it returns the following JSON now:
> {code:sql}
> {
> "_source": ["state", "city"]
> }
> {code}
> The reason for this problem is that there is a missing condition for judging
> the aggregation query.
> In addition, there is the other associated problem. After building
> aggregation JSON, the code of current version will remove empty aggregation
> block in ElasticsearchTable class, the code just like this:
> {code:java}
> JsonNode agg = query;
> while (agg.has(AGGREGATIONS) && agg.get(AGGREGATIONS).elements().hasNext()) {
> agg = agg.get(AGGREGATIONS);
> }
> ((ObjectNode) agg).remove(AGGREGATIONS);
> {code}
> But if input the JSON like above, this code will not work out.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (CALCITE-2699) TIMESTAMPADD function handles TIME incorrectly
[
https://issues.apache.org/jira/browse/CALCITE-2699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16706434#comment-16706434
]
Julian Hyde edited comment on CALCITE-2699 at 12/4/18 12:45 AM:
Fixed in
[d0bdec4f|http://git-wip-us.apache.org/repos/asf/calcite/commit/d0bdec4f];
thanks for the PR, [~x1q1j1]!
was (Author: julianhyde):
Fixed in
[18caf38f|http://git-wip-us.apache.org/repos/asf/calcite/commit/18caf38f];
thanks for the PR, [~x1q1j1]!
> TIMESTAMPADD function handles TIME incorrectly
> --
>
> Key: CALCITE-2699
> URL: https://issues.apache.org/jira/browse/CALCITE-2699
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.17.0
>Reporter: xuqianjin
>Assignee: Julian Hyde
>Priority: Major
> Fix For: 1.18.0
>
>
> Two errors occur when {{timestampadd(MINUTE, 1, time '01:00:00')}} is
> executed:
> # The return result can only be of {{TimeStamp}} type and is expected to be
> of {{Time}} type
> # The return value is {{1970-01-01 01:01:00}}, and the expectation is
> {{01:01:00}}
> # I think it should meet the following conditions:
> ||expression||Expect the result||
> |timestampadd(MINUTE, -1, time '00:00:00')|23:59:00|
> |timestampadd(MINUTE, 1, time '00:00:00')|00:01:00|
> |timestampadd(MINUTE, 1, time '23:59:59')|00:00:59|
> |timestampadd(SECOND, 1, time '23:59:59')|00:00:00|
> |timestampadd(HOUR, 1, time '23:59:59')|00:59:59|
> |timestampadd(DAY, -1, time '23:59:59')|23:59:59|
> |timestampadd(WEEK, -1, time '23:59:59')|23:59:59|
> |timestampadd(MONTH, -1, time '23:59:59')|23:59:59|
> |timestampadd(QUARTER, -1, time '23:59:59')|23:59:59|
> |timestampadd(YEAR, -1, time '23:59:59')|23:59:59|
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (CALCITE-2720) Presence of an empty aggregation should not lead to Exceptions
[
https://issues.apache.org/jira/browse/CALCITE-2720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16706426#comment-16706426
]
Julian Hyde edited comment on CALCITE-2720 at 12/4/18 12:44 AM:
Fixed in
[5ebf458f|http://git-wip-us.apache.org/repos/asf/calcite/commit/5ebf458f];
thanks for the PR, [~kgyrtkirk]!
was (Author: julianhyde):
Fixed in
[7f8556e6|http://git-wip-us.apache.org/repos/asf/calcite/commit/7f8556e6];
thanks for the PR, [~kgyrtkirk]!
> Presence of an empty aggregation should not lead to Exceptions
> --
>
> Key: CALCITE-2720
> URL: https://issues.apache.org/jira/browse/CALCITE-2720
> Project: Calcite
> Issue Type: Bug
>Reporter: Zoltan Haindrich
>Assignee: Zoltan Haindrich
>Priority: Major
> Fix For: 1.18.0
>
>
> After some transformations if an "empty" aggregation is present;
> {{LoptOptimizeJoinRule}} may bump into an array index violation.
> Original query is complicated; but this small {{RelMetadataTest}} testcase
> reproduces the root cause.
> {code}
> @Test public void testEmptyAggregateNotCausesException() throws Exception {
> final FrameworkConfig config = RelBuilderTest.config().build();
> final RelBuilder builder = RelBuilder.create(config);
> RelMetadataQuery mq = RelMetadataQuery.instance();
> RelNode agg = builder
> .scan("EMP")
> .aggregate(builder.groupKey(), Collections.
> emptyList()).build();
> mq.getTableOrigin(agg);
> }
> {code}
> Exception is:
> {code}
> java.lang.IndexOutOfBoundsException: index (0) must be less than size (0)
> at
> com.google.common.base.Preconditions.checkElementIndex(Preconditions.java:310)
> at
> com.google.common.base.Preconditions.checkElementIndex(Preconditions.java:293)
> at
> com.google.common.collect.RegularImmutableList.get(RegularImmutableList.java:67)
> at
> org.apache.calcite.rel.metadata.RelMdColumnOrigins.getColumnOrigins(RelMdColumnOrigins.java:77)
> at GeneratedMetadataHandler_ColumnOrigin.getColumnOrigins_$(Unknown
> Source)
> at GeneratedMetadataHandler_ColumnOrigin.getColumnOrigins(Unknown
> Source)
> at
> org.apache.calcite.rel.metadata.RelMetadataQuery.getColumnOrigins(RelMetadataQuery.java:345)
> at
> org.apache.calcite.rel.metadata.RelMetadataQuery.getTableOrigin(RelMetadataQuery.java:418)
> at
> org.apache.calcite.test.RelMetadataTest.testEmptyAggregateNotCausesException(RelMetadataTest.java:2396)
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (CALCITE-2713) JDBC adapter may generate casts on PostgreSQL for VARCHAR type exceeding max length
[
https://issues.apache.org/jira/browse/CALCITE-2713?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jesus Camacho Rodriguez resolved CALCITE-2713.
--
Resolution: Fixed
[~julianhyde], I have merged it because I understand you have enough on your
plate. If you see any issue, I will tackle in a follow-up.
Fixed in
[6c7a7edd1|http://git-wip-us.apache.org/repos/asf/calcite/commit/6c7a7edd1].
> JDBC adapter may generate casts on PostgreSQL for VARCHAR type exceeding max
> length
> ---
>
> Key: CALCITE-2713
> URL: https://issues.apache.org/jira/browse/CALCITE-2713
> Project: Calcite
> Issue Type: Bug
> Components: jdbc-adapter
>Reporter: Jesus Camacho Rodriguez
>Assignee: Jesus Camacho Rodriguez
>Priority: Major
> Fix For: 1.18.0
>
>
> Varchar length in PostgreSQL cannot exceed 10485760, however Calcite may
> generate a cast with length larger than that number, resulting in an
> exception.
> {noformat}
> org.postgresql.util.PSQLException: ERROR: length for type varchar cannot
> exceed 10485760
> {noformat}
> From {{htup_details.h}} in postgresql:
> {noformat}
> * MaxAttrSize is a somewhat arbitrary upper limit on the declared size of
> * data fields of char(n) and similar types. It need not have anything
> * directly to do with the *actual* upper limit of varlena values, which
> * is currently 1Gb (see TOAST structures in postgres.h). I've set it
> * at 10Mb which seems like a reasonable number --- tgl 8/6/00. */
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2713) JDBC adapter may generate casts on PostgreSQL for VARCHAR type exceeding max length
[
https://issues.apache.org/jira/browse/CALCITE-2713?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16707898#comment-16707898
]
Jesus Camacho Rodriguez commented on CALCITE-2713:
--
[~julianhyde], I have updated the PR, could you take a quick look? If it is OK,
I will merge it.
I have moved the tests to RelToSqlConverterTest and I created a custom dialect
to test the fix. Since Calcite max precision is 65536, we are not hitting this
issue with default type system impl.
> JDBC adapter may generate casts on PostgreSQL for VARCHAR type exceeding max
> length
> ---
>
> Key: CALCITE-2713
> URL: https://issues.apache.org/jira/browse/CALCITE-2713
> Project: Calcite
> Issue Type: Bug
> Components: jdbc-adapter
>Reporter: Jesus Camacho Rodriguez
>Assignee: Jesus Camacho Rodriguez
>Priority: Major
> Fix For: 1.18.0
>
>
> Varchar length in PostgreSQL cannot exceed 10485760, however Calcite may
> generate a cast with length larger than that number, resulting in an
> exception.
> {noformat}
> org.postgresql.util.PSQLException: ERROR: length for type varchar cannot
> exceed 10485760
> {noformat}
> From {{htup_details.h}} in postgresql:
> {noformat}
> * MaxAttrSize is a somewhat arbitrary upper limit on the declared size of
> * data fields of char(n) and similar types. It need not have anything
> * directly to do with the *actual* upper limit of varlena values, which
> * is currently 1Gb (see TOAST structures in postgres.h). I've set it
> * at 10Mb which seems like a reasonable number --- tgl 8/6/00. */
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2688) Improve diagnosability when return type could not be inferred.
[
https://issues.apache.org/jira/browse/CALCITE-2688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16707755#comment-16707755
]
Julian Hyde commented on CALCITE-2688:
--
Ah, good catch. I screwed up the messages, and then, seeing two consecutive
messages the same, I squashed the commits together. I'll do a force-push
sometime today to fix things. Then I'll mark this case fixed, with a pointer to
the actual commit.
> Improve diagnosability when return type could not be inferred.
> --
>
> Key: CALCITE-2688
> URL: https://issues.apache.org/jira/browse/CALCITE-2688
> Project: Calcite
> Issue Type: Improvement
>Reporter: Zoltan Haindrich
>Assignee: Zoltan Haindrich
>Priority: Major
> Fix For: 1.18.0
>
>
> Currently when the return type inferenence fails; a {{null}} is returned;
> while leads to an NPE very quickly - the resulting Exception is not
> informative at all.
> {code}
> @Test(expected = IllegalArgumentException.class)
> public void checkNoCommonReturnTypeException() {
> coalesce(vVarchar(1), vInt(2));
> }
> {code}
> example NPE:
> {code}
> java.lang.NullPointerException
> at java.util.Objects.requireNonNull(Objects.java:203)
> at org.apache.calcite.rex.RexCall.(RexCall.java:59)
> at org.apache.calcite.rex.RexBuilder.makeCall(RexBuilder.java:242)
> at org.apache.calcite.rex.RexBuilder.makeCall(RexBuilder.java:254)
> at
> org.apache.calcite.test.RexProgramBuilderBase.coalesce(RexProgramBuilderBase.java:300)
> at
> org.apache.calcite.test.RexProgramTest.checkNoCommonReturnTypeException(RexProgramTest.java:753)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2713) JDBC adapter may generate casts on PostgreSQL for VARCHAR type exceeding max length
[
https://issues.apache.org/jira/browse/CALCITE-2713?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16707735#comment-16707735
]
Julian Hyde commented on CALCITE-2713:
--
I'd like to do a force-push because I messed up the commit message in
https://github.com/apache/calcite/commit/e80934465cee318fd306159489ee3e5c768dcb68.
May I proceed? If you'd like to go first, that would be fine, just let me know.
> JDBC adapter may generate casts on PostgreSQL for VARCHAR type exceeding max
> length
> ---
>
> Key: CALCITE-2713
> URL: https://issues.apache.org/jira/browse/CALCITE-2713
> Project: Calcite
> Issue Type: Bug
> Components: jdbc-adapter
>Reporter: Jesus Camacho Rodriguez
>Assignee: Jesus Camacho Rodriguez
>Priority: Major
> Fix For: 1.18.0
>
>
> Varchar length in PostgreSQL cannot exceed 10485760, however Calcite may
> generate a cast with length larger than that number, resulting in an
> exception.
> {noformat}
> org.postgresql.util.PSQLException: ERROR: length for type varchar cannot
> exceed 10485760
> {noformat}
> From {{htup_details.h}} in postgresql:
> {noformat}
> * MaxAttrSize is a somewhat arbitrary upper limit on the declared size of
> * data fields of char(n) and similar types. It need not have anything
> * directly to do with the *actual* upper limit of varlena values, which
> * is currently 1Gb (see TOAST structures in postgres.h). I've set it
> * at 10Mb which seems like a reasonable number --- tgl 8/6/00. */
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2713) JDBC adapter may generate casts on PostgreSQL for VARCHAR type exceeding max length
[
https://issues.apache.org/jira/browse/CALCITE-2713?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16707578#comment-16707578
]
Jesus Camacho Rodriguez commented on CALCITE-2713:
--
Sure [~julianhyde], I will start working on it right now.
> JDBC adapter may generate casts on PostgreSQL for VARCHAR type exceeding max
> length
> ---
>
> Key: CALCITE-2713
> URL: https://issues.apache.org/jira/browse/CALCITE-2713
> Project: Calcite
> Issue Type: Bug
> Components: jdbc-adapter
>Reporter: Jesus Camacho Rodriguez
>Assignee: Jesus Camacho Rodriguez
>Priority: Major
> Fix For: 1.18.0
>
>
> Varchar length in PostgreSQL cannot exceed 10485760, however Calcite may
> generate a cast with length larger than that number, resulting in an
> exception.
> {noformat}
> org.postgresql.util.PSQLException: ERROR: length for type varchar cannot
> exceed 10485760
> {noformat}
> From {{htup_details.h}} in postgresql:
> {noformat}
> * MaxAttrSize is a somewhat arbitrary upper limit on the declared size of
> * data fields of char(n) and similar types. It need not have anything
> * directly to do with the *actual* upper limit of varlena values, which
> * is currently 1Gb (see TOAST structures in postgres.h). I've set it
> * at 10Mb which seems like a reasonable number --- tgl 8/6/00. */
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (CALCITE-2688) Improve diagnosability when return type could not be inferred.
[
https://issues.apache.org/jira/browse/CALCITE-2688?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Zoltan Haindrich resolved CALCITE-2688.
---
Resolution: Fixed
Fix Version/s: 1.18.0
[~julianhyde]: This change seem to have landed with a [commit message
referencing CALCITE-2720 instead of this ticket
|https://github.com/apache/calcite/commit/e80934465cee318fd306159489ee3e5c768dcb68]
...but its there! :)
> Improve diagnosability when return type could not be inferred.
> --
>
> Key: CALCITE-2688
> URL: https://issues.apache.org/jira/browse/CALCITE-2688
> Project: Calcite
> Issue Type: Improvement
>Reporter: Zoltan Haindrich
>Assignee: Zoltan Haindrich
>Priority: Major
> Fix For: 1.18.0
>
>
> Currently when the return type inferenence fails; a {{null}} is returned;
> while leads to an NPE very quickly - the resulting Exception is not
> informative at all.
> {code}
> @Test(expected = IllegalArgumentException.class)
> public void checkNoCommonReturnTypeException() {
> coalesce(vVarchar(1), vInt(2));
> }
> {code}
> example NPE:
> {code}
> java.lang.NullPointerException
> at java.util.Objects.requireNonNull(Objects.java:203)
> at org.apache.calcite.rex.RexCall.(RexCall.java:59)
> at org.apache.calcite.rex.RexBuilder.makeCall(RexBuilder.java:242)
> at org.apache.calcite.rex.RexBuilder.makeCall(RexBuilder.java:254)
> at
> org.apache.calcite.test.RexProgramBuilderBase.coalesce(RexProgramBuilderBase.java:300)
> at
> org.apache.calcite.test.RexProgramTest.checkNoCommonReturnTypeException(RexProgramTest.java:753)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2719) MySQL does not support cast to bigint type
[ https://issues.apache.org/jira/browse/CALCITE-2719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16706975#comment-16706975 ] Piotr Bojko commented on CALCITE-2719: -- I've pushed the suggested change for CAST to INTEGER > MySQL does not support cast to bigint type > -- > > Key: CALCITE-2719 > URL: https://issues.apache.org/jira/browse/CALCITE-2719 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.17.0 >Reporter: Piotr Bojko >Assignee: Julian Hyde >Priority: Major > > Cast to BIGING is not supported in MySQL. The trick is to use CAST to SIGNED > INT. > When accepted I will try to fix this. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-2714) Make BasicSqlType immutable, and now createWithNullability re-uses existing type if possible
[
https://issues.apache.org/jira/browse/CALCITE-2714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16706955#comment-16706955
]
Ruben Quesada Lopez commented on CALCITE-2714:
--
My pleasure, [~julianhyde]. Thanks for your review.
> Make BasicSqlType immutable, and now createWithNullability re-uses existing
> type if possible
>
>
> Key: CALCITE-2714
> URL: https://issues.apache.org/jira/browse/CALCITE-2714
> Project: Calcite
> Issue Type: Improvement
>Reporter: Ruben Quesada Lopez
>Assignee: Julian Hyde
>Priority: Trivial
> Fix For: 1.18.0
>
>
> As it is done in the parent implementation
> RelDataTypeFactoryImpl#createTypeWithNullability where the parameter 'type'
> is directly used as 'newType' if nullable matches:
> {code:java}
> public RelDataType createTypeWithNullability(final RelDataType type, final
> boolean nullable) {
> RelDataType newType;
> if (type.isNullable() == nullable) {
> newType = type;
> } else ...
> {code}
> I think that SqlTypeFactoryImpl#createTypeWithNullability should be modified
> in the same way when handling a BasicSqlType, to avoid calling
> BasicSqlType#createWithNullability (which internally executes a clone) if
> nullable matches:
> {code:java}
> public RelDataType createTypeWithNullability(final RelDataType type, final
> boolean nullable) {
> RelDataType newType;
> if (type instanceof BasicSqlType) {
> if (type.isNullable() == nullable) { // new piece of code
> newType = type;
> } else { // previously, this block was always executed
> BasicSqlType sqlType = (BasicSqlType) type;
> newType = sqlType.createWithNullability(nullable);
> }
> } else ...
> {code}
> I have verified, and Calcite Core unit tests run fine with this modification.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2701) Ensure that the "Baz" classes generated by Janino are thread-safe
[
https://issues.apache.org/jira/browse/CALCITE-2701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16706946#comment-16706946
]
Stamatis Zampetakis commented on CALCITE-2701:
--
Thanks for the review and commit [~julianhyde]!
> Ensure that the "Baz" classes generated by Janino are thread-safe
> -
>
> Key: CALCITE-2701
> URL: https://issues.apache.org/jira/browse/CALCITE-2701
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.17.0
>Reporter: Stamatis Zampetakis
>Assignee: Julian Hyde
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.18.0
>
>
> Currently the Baz classes that are used to execute queries in the
> EnumerableConvention are stateful since the code generated by
> EnumerableRelImplementor#implementRoot method creates an instance variable
> (i.e., DataContext root). Every call to the bind method changes the value of
> the root variable making the object mutable.
> I propose to remove the instance variable and in the body of the method use
> the DataContext passed as a parameter.
> It appears that the addition of the instance variable was a workaround for a
> bug in Janino (JANINO-169). It seems that the bug is no longer present at the
> current version of Janino used in Calcite (3.0.9) since the test
> JdbcTest#testJanino169 (and the complete suite) pass successfully with the
> proposed modification.
> Unfortunately, I couldn't verify the fix in the release notes of Janino
> neither in the commit history. The best, I could find is the following
> commits in the Janino repository:
> {code:none}
> commit fe5edc1904278c1c189f3379e06417aaf4a26315
> Author: aunkrig
> Date: Wed Jan 22 21:19:48 2014 +
> Partly fixed JANINO-169 - now you get "Compiler limitation: Initializers
> cannot access local variables declared in an enclosing block".
> commit 4d2bacf16229ac1278eafa0fb4d5a0377134d3f2
> Author: aunkrig
> Date: Wed Jan 22 15:03:17 2014 +
> Added test case for JANINO-169.
> {code}
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (CALCITE-2722) SqlImplementor createLeftCall method throws StackOverflowError
Mykola Zerniuk created CALCITE-2722:
---
Summary: SqlImplementor createLeftCall method throws
StackOverflowError
Key: CALCITE-2722
URL: https://issues.apache.org/jira/browse/CALCITE-2722
Project: Calcite
Issue Type: Bug
Components: core
Reporter: Mykola Zerniuk
Assignee: Julian Hyde
SqlImplementor _createLeftCall_ method is implemented using recursion. In this
case if sql has a lot of AND or OR operators it throws StackOverflowError.
{code:java}
Caused by: java.lang.StackOverflowError
at org.apache.calcite.util.Util.skipLast(Util.java:1940)
at org.apache.calcite.util.Util.skipLast(Util.java:1935)
at
org.apache.calcite.rel.rel2sql.SqlImplementor$Context.createLeftCall(SqlImplementor.java:763)
at
org.apache.calcite.rel.rel2sql.SqlImplementor$Context.createLeftCall(SqlImplementor.java:765)
at
org.apache.calcite.rel.rel2sql.SqlImplementor$Context.createLeftCall(SqlImplementor.java:765){code}
Since calcite converts IN list to OR this bug is also reproduces on huge IN
list.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (CALCITE-2719) MySQL does not support cast to bigint type
[ https://issues.apache.org/jira/browse/CALCITE-2719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16706859#comment-16706859 ] Piotr Bojko edited comment on CALCITE-2719 at 12/3/18 9:16 AM: --- [~julianhyde] I am afraid MySQL - as far I have read the docs - does not support any casting to explicite 32 bit integer. I would go with CAST to SIGNED for INTEGER - this would be still a step further from current implementation. Then I would log following issues: # CAST to INTEGER when pushed to MySQL can produce overflow (bug, now it is similar but with signed/unsigned values) # Escaping to alien built in data types is based on hardcoding uderscore in an identifier (bug/improvement) was (Author: ptrbojko): [~julianhyde] I am afraid MySQL - as far I have read the docs - does not support any casting to explicite 32 bit integer. I would go with CAST to SIGNED for INTEGER - this would be still a step further from current implementation. The I would log to issues: # CAST to INTEGER when pushed to MySQL can produce overflow (bug, now it is similar but with signed/unsigned values) # Escaping to alien built in data types is based on hardcoding uderscore in an identifier (bug/improvement) > MySQL does not support cast to bigint type > -- > > Key: CALCITE-2719 > URL: https://issues.apache.org/jira/browse/CALCITE-2719 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.17.0 >Reporter: Piotr Bojko >Assignee: Julian Hyde >Priority: Major > > Cast to BIGING is not supported in MySQL. The trick is to use CAST to SIGNED > INT. > When accepted I will try to fix this. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (CALCITE-2719) MySQL does not support cast to bigint type
[ https://issues.apache.org/jira/browse/CALCITE-2719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16706859#comment-16706859 ] Piotr Bojko edited comment on CALCITE-2719 at 12/3/18 9:16 AM: --- [~julianhyde] I am afraid MySQL - as far I have read the docs - does not support any casting to explicite 32 bit integer. I would go with CAST to SIGNED for INTEGER - this would be still a step further from current implementation. The I would log to issues: # CAST to INTEGER when pushed to MySQL can produce overflow (bug, now it is similar but with signed/unsigned values) # Escaping to alien built in data types is based on hardcoding uderscore in an identifier (bug/improvement) was (Author: ptrbojko): [~julianhyde] I am afraid MySQL - as far I have read the docs - does not support any casting to explicite 32 bit integer. I would go with CAST to SIGNED for INTEGER - this would be still a step further from current. The I would log to issues: # CAST to INTEGER when pushed to MySQL can produce overflow (bug, now it is similar but with signed/unsigned values) # Escaping to alien built in data types is based on hardcoding uderscore in an identifier (bug/improvement) > MySQL does not support cast to bigint type > -- > > Key: CALCITE-2719 > URL: https://issues.apache.org/jira/browse/CALCITE-2719 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.17.0 >Reporter: Piotr Bojko >Assignee: Julian Hyde >Priority: Major > > Cast to BIGING is not supported in MySQL. The trick is to use CAST to SIGNED > INT. > When accepted I will try to fix this. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-2719) MySQL does not support cast to bigint type
[ https://issues.apache.org/jira/browse/CALCITE-2719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16706859#comment-16706859 ] Piotr Bojko commented on CALCITE-2719: -- [~julianhyde] I am afraid MySQL - as far I have read the docs - does not support any casting to explicite 32 bit integer. I would go with CAST to SIGNED for INTEGER - this would be still a step further from current. The I would log to issues: # CAST to INTEGER when pushed to MySQL can produce overflow (bug, now it is similar but with signed/unsigned values) # Escaping to alien built in data types is based on hardcoding uderscore in an identifier (bug/improvement) > MySQL does not support cast to bigint type > -- > > Key: CALCITE-2719 > URL: https://issues.apache.org/jira/browse/CALCITE-2719 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.17.0 >Reporter: Piotr Bojko >Assignee: Julian Hyde >Priority: Major > > Cast to BIGING is not supported in MySQL. The trick is to use CAST to SIGNED > INT. > When accepted I will try to fix this. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
