[jira] [Commented] (CALCITE-2046) Support "CREATE FUNCTION" DDL
[
https://issues.apache.org/jira/browse/CALCITE-2046?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16383271#comment-16383271
]
Shuyi Chen commented on CALCITE-2046:
-
Hi [~julianhyde], similar to "CREATE TYPE", I am thinking maybe we need add
library into the JSON model as well, and keep the fullClassPath for each
library added, and this is used to remove all added functions when drop or
alter is invoked. What do you think?
> Support "CREATE FUNCTION" DDL
> -
>
> Key: CALCITE-2046
> URL: https://issues.apache.org/jira/browse/CALCITE-2046
> Project: Calcite
> Issue Type: New Feature
>Reporter: Shuyi Chen
>Assignee: Shuyi Chen
>Priority: Major
>
> We want to add DDL support for creating external function like Apache Drill
> ([https://drill.apache.org/docs/create-function-using-jar/]).
> {code:java}
> CREATE FUNCTION USING JAR '.jar';
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2198) ClassCastException in RexBuilder when makeLiteral for BINARY and VARBINARY
[
https://issues.apache.org/jira/browse/CALCITE-2198?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16383159#comment-16383159
]
Hequn Cheng commented on CALCITE-2198:
--
Hi, [~julianhyde]
Thanks very much for your reply. It make sense to require a value immutable and
implements Comparable for RexLiteral, but i think Calcite should also provide
utils to convert the type of a value to comply with
RexLiteral.valueMatchesType(), so that users don't have to convert by
themselves. What do you think?
PS: Whenever I create an issue, it will assign to you automatically. How can I
assign it to myself? Thanks.
Best, Hequn
> ClassCastException in RexBuilder when makeLiteral for BINARY and VARBINARY
> --
>
> Key: CALCITE-2198
> URL: https://issues.apache.org/jira/browse/CALCITE-2198
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Hequn Cheng
>Assignee: Julian Hyde
>Priority: Major
>
> Currently, makeLiteral for {{BINARY}} and {{VARBINARY}} will throw
> {{ClassCastException}} when value type is {{byte[]}}:
> {code:java}
> java.lang.ClassCastException: [B cannot be cast to
> org.apache.calcite.avatica.util.ByteString
> at org.apache.calcite.rex.RexBuilder.makeLiteral(RexBuilder.java:1336)
> at
> org.apache.calcite.test.RexProgramTest.testSimplifyCastLiteral(RexProgramTest.java:1567){code}
> The exception can be reproduced by the following test case(in
> RexProgramTest.testSimplifyCastLiteral()):
> {code:java}
> literals.add((RexLiteral)
> rexBuilder.makeLiteral(new byte[] {1, 2, -34, 0, -128},
> typeFactory.createSqlType(SqlTypeName.BINARY, 5), false));{code}
> To avoid this exception we have to add support for type of {{byte[]}}. One
> choice is to convert {{byte[]}} to {{ByteString}} in {{RexBuilder.clean()}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CALCITE-2195) AggregateJoinTransposeRule fails to aggregate over unique column
[
https://issues.apache.org/jira/browse/CALCITE-2195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde updated CALCITE-2195:
-
Fix Version/s: (was: 1.15.0)
1.16.0
> AggregateJoinTransposeRule fails to aggregate over unique column
>
>
> Key: CALCITE-2195
> URL: https://issues.apache.org/jira/browse/CALCITE-2195
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.15.0
>Reporter: Zhong Yu
>Assignee: Julian Hyde
>Priority: Major
> Fix For: 1.16.0
>
>
> The following query, in which "A.sal" is unique,
> {code:java}
> select sum(A.sal)
> from (select distinct sal from sales.emp) as A
> join sales.emp as B on A.sal=B.sal
> {code}
> causes AggregateJoinTransposeRule to fail with message
> {code:java}
> java.lang.AssertionError: type mismatch:
> aggCall type:
> INTEGER
> inferred type:
> BIGINT
> {code}
> Apparently, this is a bug in the rule when `unique` is true on the A side, in
> which case the rule does not aggregate on the A side, `leftSubTotal==null`,
> causing `splitter.topSplit()` to only sum over `count()` coming from the B
> side.
> A solution would be to introduce `splitter.singleton()` on the A side, so
> that it can be fed to topSplit() to be multiplied by the count.
> In the case that the `unique` side does not contain the column of an agg
> call, it seems that we should do `other_singleton()` on this side, and feed
> it to topSplit(). However, realize that the `other()` expression is
> necessarily a `count()`, or a scalar function of `count()`, because it does
> not depend on any column values. In the same way, the proposed
> `other_singleton()` necessarily returns 1, or some constant value.
> `topSplit()` would not have any need of that constant value.Therefore in this
> case, we don't need a split on this side, just leave its subtotal as null.
>
> I'm working on a pull-request based on these understandings. BTW, is there a
> reference to the algorithm used in the code? I can only find some old papers
> that don't exactly cover the logic of the code. Thanks.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2195) AggregateJoinTransposeRule fails to aggregate over unique column
[
https://issues.apache.org/jira/browse/CALCITE-2195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16383037#comment-16383037
]
Julian Hyde commented on CALCITE-2195:
--
PR looks good; testing now and will merge shortly.
> AggregateJoinTransposeRule fails to aggregate over unique column
>
>
> Key: CALCITE-2195
> URL: https://issues.apache.org/jira/browse/CALCITE-2195
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.15.0
>Reporter: Zhong Yu
>Assignee: Julian Hyde
>Priority: Major
> Fix For: 1.16.0
>
>
> The following query, in which "A.sal" is unique,
> {code:java}
> select sum(A.sal)
> from (select distinct sal from sales.emp) as A
> join sales.emp as B on A.sal=B.sal
> {code}
> causes AggregateJoinTransposeRule to fail with message
> {code:java}
> java.lang.AssertionError: type mismatch:
> aggCall type:
> INTEGER
> inferred type:
> BIGINT
> {code}
> Apparently, this is a bug in the rule when `unique` is true on the A side, in
> which case the rule does not aggregate on the A side, `leftSubTotal==null`,
> causing `splitter.topSplit()` to only sum over `count()` coming from the B
> side.
> A solution would be to introduce `splitter.singleton()` on the A side, so
> that it can be fed to topSplit() to be multiplied by the count.
> In the case that the `unique` side does not contain the column of an agg
> call, it seems that we should do `other_singleton()` on this side, and feed
> it to topSplit(). However, realize that the `other()` expression is
> necessarily a `count()`, or a scalar function of `count()`, because it does
> not depend on any column values. In the same way, the proposed
> `other_singleton()` necessarily returns 1, or some constant value.
> `topSplit()` would not have any need of that constant value.Therefore in this
> case, we don't need a split on this side, just leave its subtotal as null.
>
> I'm working on a pull-request based on these understandings. BTW, is there a
> reference to the algorithm used in the code? I can only find some old papers
> that don't exactly cover the logic of the code. Thanks.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CALCITE-2181) Release Calcite 1.16.0
[ https://issues.apache.org/jira/browse/CALCITE-2181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Hyde updated CALCITE-2181: - Fix Version/s: 1.16.0 > Release Calcite 1.16.0 > -- > > Key: CALCITE-2181 > URL: https://issues.apache.org/jira/browse/CALCITE-2181 > Project: Calcite > Issue Type: Task >Reporter: Jesus Camacho Rodriguez >Assignee: Jesus Camacho Rodriguez >Priority: Major > Fix For: 1.16.0 > > > Release Calcite 1.16.0 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CALCITE-2197) Test failures on Windows
[ https://issues.apache.org/jira/browse/CALCITE-2197?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Hyde updated CALCITE-2197: - Fix Version/s: 1.16.0 > Test failures on Windows > > > Key: CALCITE-2197 > URL: https://issues.apache.org/jira/browse/CALCITE-2197 > Project: Calcite > Issue Type: Bug >Reporter: Julian Hyde >Assignee: Julian Hyde >Priority: Major > Fix For: 1.16.0 > > > There are currently test failures on Windows. Fix by defining matchers that > compare strings regardless of line-endings. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-2154) Upgrade jackson to 2.9.4
[ https://issues.apache.org/jira/browse/CALCITE-2154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16382998#comment-16382998 ] Julian Hyde commented on CALCITE-2154: -- I have this working in https://github.com/julianhyde/calcite/tree/2154-upgrade-avatica; will push after Avatica 1.11. > Upgrade jackson to 2.9.4 > - > > Key: CALCITE-2154 > URL: https://issues.apache.org/jira/browse/CALCITE-2154 > Project: Calcite > Issue Type: Bug > Components: avatica, core >Affects Versions: 1.15.0 >Reporter: Alexey Roytman >Assignee: Julian Hyde >Priority: Major > Fix For: avatica-1.11.0, 1.16.0 > > > Calcite now uses FasterXML Jackson 2.6.3. Please upgrade to last version of > FasterXML Jackson (on 2018-02-25 it's version 2.9.4). > I hope that fixing pom.xml files and running tests is enough. > See also CALCITE-1021, KYLIN-3027. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-2190) Extend SubstitutionVisitor.splitFilter to cover different order of operands
[
https://issues.apache.org/jira/browse/CALCITE-2190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16382981#comment-16382981
]
Jesus Camacho Rodriguez commented on CALCITE-2190:
--
I forgot to merge last commit addressing the comment about single element;
fixed in http://git-wip-us.apache.org/repos/asf/calcite/commit/483c0a61b .
> Extend SubstitutionVisitor.splitFilter to cover different order of operands
> ---
>
> Key: CALCITE-2190
> URL: https://issues.apache.org/jira/browse/CALCITE-2190
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: Jesus Camacho Rodriguez
>Assignee: Jesus Camacho Rodriguez
>Priority: Major
> Fix For: 1.16.0
>
>
> {{SubstitutionVisitor.splitFilter}} does structural comparison to identify
> relevant predicates. The method could sort the operands for some expressions
> in a deterministic way to maximize possible matches.
> For instance, currently this example yields correct results:
> {code}
> condition: x = 1 or y = 2
> target:y = 2 or x = 1
> -> residue: true
> {code}
> However, the following equivalent example fails:
> {code}
> condition: x = 1 or y = 2
> target:y = 2 or 1 = x
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (CALCITE-508) Reading from ResultSet before calling next() should throw SQLException not NoSuchElementException
[ https://issues.apache.org/jira/browse/CALCITE-508?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Hyde resolved CALCITE-508. - Resolution: Fixed Fixed in [fcbf42eb|http://git-wip-us.apache.org/repos/asf/calcite-avatica/commit/fcbf42eb]; thanks for the PR, [~asolimando]! > Reading from ResultSet before calling next() should throw SQLException not > NoSuchElementException > - > > Key: CALCITE-508 > URL: https://issues.apache.org/jira/browse/CALCITE-508 > Project: Calcite > Issue Type: Bug > Components: avatica >Reporter: Julian Hyde >Assignee: Julian Hyde >Priority: Major > Labels: newbie > Fix For: avatica-1.11.0 > > > Reading from ResultSet before calling next() should throw SQLException not > NoSuchElementException. > Each of the Cursor.Accessor.getXxx methods should convert runtime exceptions > to SQLException. > JdbcTest.testExtract currently demonstrates this problem; it passes if there > is a NoSuchElementException, but should look for a SQLException. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (CALCITE-2140) Basic implementation of Statement#getMoreResults()
[
https://issues.apache.org/jira/browse/CALCITE-2140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde resolved CALCITE-2140.
--
Resolution: Fixed
Fix Version/s: avatica-1.11.0
Fixed in
[02d00b77|http://git-wip-us.apache.org/repos/asf/calcite-avatica/commit/02d00b77];
thanks for the PR, [~laurentgo]!
> Basic implementation of Statement#getMoreResults()
> --
>
> Key: CALCITE-2140
> URL: https://issues.apache.org/jira/browse/CALCITE-2140
> Project: Calcite
> Issue Type: Improvement
> Components: avatica
>Reporter: Laurent Goujon
>Priority: Minor
> Fix For: avatica-1.11.0
>
>
> Methods {{Statement#getMoreResults}} and {{Statement#getMoreResults(int)}}
> are currently throwing a {{SQLFeatureNotSupportedException}}, but at least
> one tool (DataGrip) is calling the first method after each SQL request.
> Avatica doesn't support multiple {{ResultSet}} for a given {{Statement}} (see
> [https://github.com/apache/calcite-avatica/blob/master/core/src/main/java/org/apache/calcite/avatica/AvaticaDatabaseMetaData.java#L1148]),
> so a basic implementation could close the current open result set (if any),
> and return {{false}} for both methods (unless the int argument is equal to
> {{Statement.KEEP_CURRENT_RESULT}} or {{Statement.CLOSE_ALL_RESULTS}}).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2154) Upgrade jackson to 2.9.4
[ https://issues.apache.org/jira/browse/CALCITE-2154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16382833#comment-16382833 ] Julian Hyde commented on CALCITE-2154: -- Fixed in Avatica in [100469ad|http://git-wip-us.apache.org/repos/asf/calcite-avatica/commit/100469ad]. Will keep this case open until fixed in Calcite (which should happen shortly after Calcite upgrades to Avatica 1.11, next week hopefully). > Upgrade jackson to 2.9.4 > - > > Key: CALCITE-2154 > URL: https://issues.apache.org/jira/browse/CALCITE-2154 > Project: Calcite > Issue Type: Bug > Components: avatica, core >Affects Versions: 1.15.0 >Reporter: Alexey Roytman >Assignee: Julian Hyde >Priority: Major > Fix For: avatica-1.11.0, 1.16.0 > > > Calcite now uses FasterXML Jackson 2.6.3. Please upgrade to last version of > FasterXML Jackson (on 2018-02-25 it's version 2.9.4). > I hope that fixing pom.xml files and running tests is enough. > See also CALCITE-1021, KYLIN-3027. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (CALCITE-2013) Bump HSQLDB version in avatica
[ https://issues.apache.org/jira/browse/CALCITE-2013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Hyde resolved CALCITE-2013. -- Resolution: Fixed Fixed in [02726a87|http://git-wip-us.apache.org/repos/asf/calcite-avatica/commit/02726a87]. After the upgrade, HSQLDB returns a TIMESTAMP WITH TIMEZONE value in one query. Avatica does not not fully support that type, so I removed that test. The change includes limited support for TIMESTAMP WITH TIMEZONE and TIME WITH TIMEZONE, including enum values in SqlType. > Bump HSQLDB version in avatica > -- > > Key: CALCITE-2013 > URL: https://issues.apache.org/jira/browse/CALCITE-2013 > Project: Calcite > Issue Type: Improvement > Components: avatica >Affects Versions: avatica-1.10.0 >Reporter: Francis Chuang >Priority: Minor > Fix For: avatica-1.11.0 > > > It would be nice if the HSQLDB used in avatica can be bumped to the latest > version. The 2.4.x series was released around 6 months ago and should be > quite stable. 2.3.1 which is currently being used is around 4 years old and > there has been a lot of bug fixes since. > I ran into a bunch of issues while testing the avatica-go driver against > HSQLDB and I am hoping an upgrade to 2.4.x will resolve some or most of the > issues. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-2140) Basic implementation of Statement#getMoreResults()
[
https://issues.apache.org/jira/browse/CALCITE-2140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16382824#comment-16382824
]
ASF GitHub Bot commented on CALCITE-2140:
-
Github user asfgit closed the pull request at:
https://github.com/apache/calcite-avatica/pull/24
> Basic implementation of Statement#getMoreResults()
> --
>
> Key: CALCITE-2140
> URL: https://issues.apache.org/jira/browse/CALCITE-2140
> Project: Calcite
> Issue Type: Improvement
> Components: avatica
>Reporter: Laurent Goujon
>Priority: Minor
>
> Methods {{Statement#getMoreResults}} and {{Statement#getMoreResults(int)}}
> are currently throwing a {{SQLFeatureNotSupportedException}}, but at least
> one tool (DataGrip) is calling the first method after each SQL request.
> Avatica doesn't support multiple {{ResultSet}} for a given {{Statement}} (see
> [https://github.com/apache/calcite-avatica/blob/master/core/src/main/java/org/apache/calcite/avatica/AvaticaDatabaseMetaData.java#L1148]),
> so a basic implementation could close the current open result set (if any),
> and return {{false}} for both methods (unless the int argument is equal to
> {{Statement.KEEP_CURRENT_RESULT}} or {{Statement.CLOSE_ALL_RESULTS}}).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-508) Reading from ResultSet before calling next() should throw SQLException not NoSuchElementException
[ https://issues.apache.org/jira/browse/CALCITE-508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16382825#comment-16382825 ] ASF GitHub Bot commented on CALCITE-508: Github user asfgit closed the pull request at: https://github.com/apache/calcite-avatica/pull/23 > Reading from ResultSet before calling next() should throw SQLException not > NoSuchElementException > - > > Key: CALCITE-508 > URL: https://issues.apache.org/jira/browse/CALCITE-508 > Project: Calcite > Issue Type: Bug > Components: avatica >Reporter: Julian Hyde >Assignee: Julian Hyde >Priority: Major > Labels: newbie > Fix For: avatica-1.11.0 > > > Reading from ResultSet before calling next() should throw SQLException not > NoSuchElementException. > Each of the Cursor.Accessor.getXxx methods should convert runtime exceptions > to SQLException. > JdbcTest.testExtract currently demonstrates this problem; it passes if there > is a NoSuchElementException, but should look for a SQLException. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-2194) Ability to hide a schema
[
https://issues.apache.org/jira/browse/CALCITE-2194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16382685#comment-16382685
]
Piotr Bojko commented on CALCITE-2194:
--
I have a POC for this feature and tomorrow will adding more tests.
Iv'e ended up with following solution:
# Setting up the user on behalf which connection will execute sql statements
is done via standard user property or standard jdbcmanager method. Julian -
probably you want to have something less "full-fledged" but any other approach
would end up with more complex mockup of some kind of default principal/user in
the code
# Configuring schema in json is following:
{code}
{
"name": "HIDDEN_SCHEMA",
"type": "custom",
"factory": "some-factory",
"operand": {},
"access" : {
"factory" : "some-new-factory-for-user-based-access-logic",
"operand" : {
"user01" : "SELECT",
"user02" : "SELECT, UPDATE"
"user03" : "INSERT, DELETE"
}
}
}{code}
There is no authencitation - user passed from DriverManager will create
Principal with appropriate name.
Some early POC is here -
https://github.com/ptrbojko/calcite/tree/experimental-hidden-schema
> Ability to hide a schema
>
>
> Key: CALCITE-2194
> URL: https://issues.apache.org/jira/browse/CALCITE-2194
> Project: Calcite
> Issue Type: New Feature
> Components: core
>Affects Versions: 1.16.0
>Reporter: Piotr Bojko
>Assignee: Piotr Bojko
>Priority: Minor
>
> See:
> [https://mail-archives.apache.org/mod_mbox/calcite-dev/201711.mbox/ajax/%3C6F6E52D4-6860-4384-A1CB-A2301D05394D%40apache.org%3E]
> I've looked into the core and the notion of an user could be hard to achieved
> now.
> Though, I am able to implement the "hidden schema" feature through following
> changes:
> # JsonSchema - add a holder for the feature, boolean flag or flags field
> with enum (CACHED which now exists as a separate flag - some deprecation
> could be needed, HIDDEN)
> # CalciteSchema - pass through of a flag
> # RelOptSchema - pass through of a flag
> # CalciteCatalogReader - pass through of a flag
> # Other derivatives of RelOptSchema - mocked value, false
> # RelOptTable and impl - pass through of a flag
> # SqlValidatorImpl - validation whether object from hidden schema is used
> (in the same places like validateAccess)
> # ViewTableMacro.apply -> Schemas.analyzeView ->
> CalcitePrepareImpl.analyzeView -> CalcitePrepareImpl.parse_ ->
> CalcitePrepareImpl.CalcitePrepareImpl - this path of execution should build
> SqlValidatorImpl which has the check from point 7 disabled-
> Such feature could be useful for end users.
> If the solution is ok - I can contribute it.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2198) ClassCastException in RexBuilder when makeLiteral for BINARY and VARBINARY
[
https://issues.apache.org/jira/browse/CALCITE-2198?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16382514#comment-16382514
]
Julian Hyde commented on CALCITE-2198:
--
This isn't a "bug". It is a feature request, and I don't agree that the feature
is necessary.
If you create a BINARY or VARBINARY literal, Calcite requires a value of type
ByteString. Just supply one of those. (ByteString is better than byte[] because
it is immutable and implements Comparable.)
See RexLiteral.valueMatchesType for what is acceptable for each type.
> ClassCastException in RexBuilder when makeLiteral for BINARY and VARBINARY
> --
>
> Key: CALCITE-2198
> URL: https://issues.apache.org/jira/browse/CALCITE-2198
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Hequn Cheng
>Assignee: Julian Hyde
>Priority: Major
>
> Currently, makeLiteral for {{BINARY}} and {{VARBINARY}} will throw
> {{ClassCastException}} when value type is {{byte[]}}:
> {code:java}
> java.lang.ClassCastException: [B cannot be cast to
> org.apache.calcite.avatica.util.ByteString
> at org.apache.calcite.rex.RexBuilder.makeLiteral(RexBuilder.java:1336)
> at
> org.apache.calcite.test.RexProgramTest.testSimplifyCastLiteral(RexProgramTest.java:1567){code}
> The exception can be reproduced by the following test case(in
> RexProgramTest.testSimplifyCastLiteral()):
> {code:java}
> literals.add((RexLiteral)
> rexBuilder.makeLiteral(new byte[] {1, 2, -34, 0, -128},
> typeFactory.createSqlType(SqlTypeName.BINARY, 5), false));{code}
> To avoid this exception we have to add support for type of {{byte[]}}. One
> choice is to convert {{byte[]}} to {{ByteString}} in {{RexBuilder.clean()}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CALCITE-2198) ClassCastException in RexBuilder when makeLiteral for BINARY and VARBINARY
[
https://issues.apache.org/jira/browse/CALCITE-2198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hequn Cheng updated CALCITE-2198:
-
Description:
Currently, makeLiteral for {{BINARY}} and {{VARBINARY}} will throw
{{ClassCastException}} when value type is {{byte[]}}:
{code:java}
java.lang.ClassCastException: [B cannot be cast to
org.apache.calcite.avatica.util.ByteString
at org.apache.calcite.rex.RexBuilder.makeLiteral(RexBuilder.java:1336)
at
org.apache.calcite.test.RexProgramTest.testSimplifyCastLiteral(RexProgramTest.java:1567){code}
The exception can be reproduced by the following test case(in
RexProgramTest.testSimplifyCastLiteral()):
{code:java}
literals.add((RexLiteral)
rexBuilder.makeLiteral(new byte[] {1, 2, -34, 0, -128},
typeFactory.createSqlType(SqlTypeName.BINARY, 5), false));{code}
To avoid this exception we have to add support for type of {{byte[]}}. One
choice is to convert {{byte[]}} to {{ByteString}} in {{RexBuilder.clean()}}.
was:
Currently, makeLiteral for {{BINARY}} and {{VARBINARY}} will throw
{{ClassCastException}} when value type is {{byte[]}}:
{code:java}
java.lang.ClassCastException: [B cannot be cast to
org.apache.calcite.avatica.util.ByteString
at org.apache.calcite.rex.RexBuilder.makeLiteral(RexBuilder.java:1271)
at org.apache.calcite.rex.RexBuilder.makeLiteral(RexBuilder.java:1251){code}
To avoid this exception we have to add support for type of {{byte[]}}. One
choice is to convert {{byte[]}} to {{ByteString}} in {{RexBuilder.clean()}}.
> ClassCastException in RexBuilder when makeLiteral for BINARY and VARBINARY
> --
>
> Key: CALCITE-2198
> URL: https://issues.apache.org/jira/browse/CALCITE-2198
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Hequn Cheng
>Assignee: Julian Hyde
>Priority: Major
>
> Currently, makeLiteral for {{BINARY}} and {{VARBINARY}} will throw
> {{ClassCastException}} when value type is {{byte[]}}:
> {code:java}
> java.lang.ClassCastException: [B cannot be cast to
> org.apache.calcite.avatica.util.ByteString
> at org.apache.calcite.rex.RexBuilder.makeLiteral(RexBuilder.java:1336)
> at
> org.apache.calcite.test.RexProgramTest.testSimplifyCastLiteral(RexProgramTest.java:1567){code}
> The exception can be reproduced by the following test case(in
> RexProgramTest.testSimplifyCastLiteral()):
> {code:java}
> literals.add((RexLiteral)
> rexBuilder.makeLiteral(new byte[] {1, 2, -34, 0, -128},
> typeFactory.createSqlType(SqlTypeName.BINARY, 5), false));{code}
> To avoid this exception we have to add support for type of {{byte[]}}. One
> choice is to convert {{byte[]}} to {{ByteString}} in {{RexBuilder.clean()}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (CALCITE-2197) Test failures on Windows
Julian Hyde created CALCITE-2197: Summary: Test failures on Windows Key: CALCITE-2197 URL: https://issues.apache.org/jira/browse/CALCITE-2197 Project: Calcite Issue Type: Bug Reporter: Julian Hyde Assignee: Julian Hyde There are currently test failures on Windows. Fix by defining matchers that compare strings regardless of line-endings. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
