[jira] [Commented] (CALCITE-2211) Type of BigInteger should be BIGINT
[ https://issues.apache.org/jira/browse/CALCITE-2211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16411855#comment-16411855 ] Eyal Segal commented on CALCITE-2211: - You are correct. I don't think that MySql is the issue here but how JDBC creates the objects based on the column type due to the "unsigned". Unsigned BIGINT can bring up to 2^64-1 positive values, were regular long provides 2^64 positive and negative values, so in JDBC they had to use BigInteger to represent unsigned BIGINT properly. > Type of BigInteger should be BIGINT > --- > > Key: CALCITE-2211 > URL: https://issues.apache.org/jira/browse/CALCITE-2211 > Project: Calcite > Issue Type: Bug >Affects Versions: 1.15.0 >Reporter: Eyal Segal >Assignee: Julian Hyde >Priority: Major > > Vertica DB returns BigInteger values as BigInteger. It seems that > JavaToSqlTypeConversionRules doesn't support mapping between BigInteger to > BIGINT. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-2211) Type of BigInteger should be BIGINT
[ https://issues.apache.org/jira/browse/CALCITE-2211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16407776#comment-16407776 ] Eyal Segal commented on CALCITE-2211: - The to the left is actually a "bigint(11)" column. The is the "bigint(20) unsigned" that we're discussing. Based on your CSV adapter, we didn't want to interfere with the type resolving. So JDBC resolves to BigInteger, and the type factory fails to resolve that to BIGINT. In anyway our workaround was indeed to interfere with the resolving process, so when the code sees BigInteger we cast it to Long. > Type of BigInteger should be BIGINT > --- > > Key: CALCITE-2211 > URL: https://issues.apache.org/jira/browse/CALCITE-2211 > Project: Calcite > Issue Type: Bug >Affects Versions: 1.15.0 >Reporter: Eyal Segal >Assignee: Julian Hyde >Priority: Major > > Vertica DB returns BigInteger values as BigInteger. It seems that > JavaToSqlTypeConversionRules doesn't support mapping between BigInteger to > BIGINT. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-2211) Type of BigInteger should be BIGINT
[ https://issues.apache.org/jira/browse/CALCITE-2211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16404023#comment-16404023 ] Eyal Segal commented on CALCITE-2211: - We don't use Calcite to read from MySql directly. We created an adapter based on the CSV adapter that creates several "tables" from different data sources and uses Calcite as the final join. We don't use Calcite directly over the data sources since in most cases it doesn't send the filter to the DB (I think you guys call it "push down"). This is the stack trace: Caused by: org.apache.calcite.runtime.CalciteContextException: From line 15, column 29 to line 15, column 49: Cannot apply '=' to arguments of type ' = '. Supported form(s): ' = ' at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) ~[?:1.8.0_151] at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) ~[?:1.8.0_151] at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) ~[?:1.8.0_151] at java.lang.reflect.Constructor.newInstance(Constructor.java:423) ~[?:1.8.0_151] at org.apache.calcite.runtime.Resources$ExInstWithCause.ex(Resources.java:463) ~[calcite-core-1.15.0.jar:1.15.0] at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:803) ~[calcite-core-1.15.0.jar:1.15.0] at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:788) ~[calcite-core-1.15.0.jar:1.15.0] at org.apache.calcite.sql.validate.SqlValidatorImpl.newValidationError(SqlValidatorImpl.java:4712) ~[calcite-core-1.15.0.jar:1.15.0] at org.apache.calcite.sql.SqlCallBinding.newValidationSignatureError(SqlCallBinding.java:284) ~[calcite-core-1.15.0.jar:1.15.0] at org.apache.calcite.sql.type.ComparableOperandTypeChecker.checkOperandTypes(ComparableOperandTypeChecker.java:66) ~[calcite-core-1.15.0.jar:1.15.0] at org.apache.calcite.sql.SqlOperator.checkOperandTypes(SqlOperator.java:659) ~[calcite-core-1.15.0.jar:1.15.0] at org.apache.calcite.sql.SqlOperator.validateOperands(SqlOperator.java:432) ~[calcite-core-1.15.0.jar:1.15.0] at org.apache.calcite.sql.SqlOperator.deriveType(SqlOperator.java:509) ~[calcite-core-1.15.0.jar:1.15.0] at org.apache.calcite.sql.SqlBinaryOperator.deriveType(SqlBinaryOperator.java:144) ~[calcite-core-1.15.0.jar:1.15.0] at org.apache.calcite.sql.validate.SqlValidatorImpl$DeriveTypeVisitor.visit(SqlValidatorImpl.java:5438) ~[calcite-core-1.15.0.jar:1.15.0] at org.apache.calcite.sql.validate.SqlValidatorImpl$DeriveTypeVisitor.visit(SqlValidatorImpl.java:5425) ~[calcite-core-1.15.0.jar:1.15.0] at org.apache.calcite.sql.SqlCall.accept(SqlCall.java:138) ~[calcite-core-1.15.0.jar:1.15.0] at org.apache.calcite.sql.validate.SqlValidatorImpl.deriveTypeImpl(SqlValidatorImpl.java:1606) ~[calcite-core-1.15.0.jar:1.15.0] at org.apache.calcite.sql.validate.SqlValidatorImpl.deriveType(SqlValidatorImpl.java:1591) ~[calcite-core-1.15.0.jar:1.15.0] at org.apache.calcite.sql.validate.SqlValidatorImpl.validateWhereOrOn(SqlValidatorImpl.java:3916) ~[calcite-core-1.15.0.jar:1.15.0] at org.apache.calcite.sql.validate.SqlValidatorImpl.validateJoin(SqlValidatorImpl.java:3021) ~[calcite-core-1.15.0.jar:1.15.0] at org.apache.calcite.sql.validate.SqlValidatorImpl.validateFrom(SqlValidatorImpl.java:2966) ~[calcite-core-1.15.0.jar:1.15.0] at org.apache.calcite.sql.validate.SqlValidatorImpl.validateSelect(SqlValidatorImpl.java:3216) ~[calcite-core-1.15.0.jar:1.15.0] at org.apache.calcite.sql.validate.SelectNamespace.validateImpl(SelectNamespace.java:60) ~[calcite-core-1.15.0.jar:1.15.0] at org.apache.calcite.sql.validate.AbstractNamespace.validate(AbstractNamespace.java:84) ~[calcite-core-1.15.0.jar:1.15.0] at org.apache.calcite.sql.validate.SqlValidatorImpl.validateNamespace(SqlValidatorImpl.java:947) ~[calcite-core-1.15.0.jar:1.15.0] at org.apache.calcite.sql.validate.SqlValidatorImpl.validateQuery(SqlValidatorImpl.java:928) ~[calcite-core-1.15.0.jar:1.15.0] at org.apache.calcite.sql.SqlSelect.validate(SqlSelect.java:226) ~[calcite-core-1.15.0.jar:1.15.0] at org.apache.calcite.sql.validate.SqlValidatorImpl.validateScopedExpression(SqlValidatorImpl.java:903) ~[calcite-core-1.15.0.jar:1.15.0] at org.apache.calcite.sql.validate.SqlValidatorImpl.validate(SqlValidatorImpl.java:613) ~[calcite-core-1.15.0.jar:1.15.0] at org.apache.calcite.sql2rel.SqlToRelConverter.convertQuery(SqlToRelConverter.java:552) ~[calcite-core-1.15.0.jar:1.15.0] at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:264) ~[calcite-core-1.15.0.jar:1.15.0] at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:230) ~[calcite-core-1.15.0.jar:1.15.0] at org.apache.calcite.prepare.CalcitePrepareImpl.prepare2_(CalcitePrepareImpl.java:781) ~[calcite-core-1.15.0.jar:1.15.0] at org.apache.calcite.prepare.CalcitePrepareImpl.prepare_(CalcitePrepareImpl.java:640)
[jira] [Commented] (CALCITE-2211) Type of BigInteger should be BIGINT
[ https://issues.apache.org/jira/browse/CALCITE-2211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16403676#comment-16403676 ] Eyal Segal commented on CALCITE-2211: - [~julianhyde], BigInteger is what JDBC returns by default, I have no control over that and can't set it to BigDecimal. [~suez1224], thanks I'll try to find some time to do it, just wanted to let you know about this bug. > Type of BigInteger should be BIGINT > --- > > Key: CALCITE-2211 > URL: https://issues.apache.org/jira/browse/CALCITE-2211 > Project: Calcite > Issue Type: Bug >Affects Versions: 1.15.0 >Reporter: Eyal Segal >Assignee: Julian Hyde >Priority: Major > > Vertica DB returns BigInteger values as BigInteger. It seems that > JavaToSqlTypeConversionRules doesn't support mapping between BigInteger to > BIGINT. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-2211) Type of BigInteger should be BIGINT
[
https://issues.apache.org/jira/browse/CALCITE-2211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16400155#comment-16400155
]
Eyal Segal commented on CALCITE-2211:
-
{code:java}
DESC test_table;{code}
Prints:
{code:java}
+---+-+--+-+-+---+
| Field | Type | Null | Key | Default | Extra |
+---+-+--+-+-+---+
| id | bigint(20) unsigned | NO | | NULL | |
+---+-+--+-+-+---+
1 row in set (0.00 sec){code}
> Type of BigInteger should be BIGINT
> ---
>
> Key: CALCITE-2211
> URL: https://issues.apache.org/jira/browse/CALCITE-2211
> Project: Calcite
> Issue Type: Bug
>Affects Versions: 1.15.0
>Reporter: Eyal Segal
>Assignee: Julian Hyde
>Priority: Major
>
> Vertica DB returns BigInteger values as BigInteger. It seems that
> JavaToSqlTypeConversionRules doesn't support mapping between BigInteger to
> BIGINT.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (CALCITE-2211) Type of BigInteger should be BIGINT
[
https://issues.apache.org/jira/browse/CALCITE-2211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16399040#comment-16399040
]
Eyal Segal edited comment on CALCITE-2211 at 3/14/18 6:23 PM:
--
It is also reproduced on MySql, with unsigned bigint column.
Consider this table:
{code:java}
create table test_table (id bigint(20) unsigned not null);
insert into test_table values (1);
{code}
Then when we fetch the result using JDBC:
{code:java}
try (Connection conn = new JDBC4Connection(db, 3306, p, "common",
"jdbc:apache:commons:dbcp:/db")) {
try (ResultSet rs = conn.prepareStatement("SELECT id FROM common.test_table
WHERE id=1").executeQuery()) {
while (rs.next()) {
System.out.print(rs.getObject("id").getClass());
}
}
}{code}
This will print "class java.math.BigInteger"
was (Author: eysegal):
It is also reproduced on MySql, with unsigned bigint column.
Consider this table:
{code:java}
create table test_table (id bigint(20) unsigned not null);
insert into test_table values (1);
{code}
Then when we fetch the result using JDBC:
{code:java}
try (Connection conn = new JDBC4Connection(db, 3306, p, "common",
"jdbc:apache:commons:dbcp:/db")) {
try (ResultSet rs = conn.prepareStatement("SELECT id FROM common.test_table
WHERE id=1").executeQuery()) {
while (rs.next()) {
System.out.print(rs.getObject("id").getClass());
}
}
}{code}
This will print java.math.BigInteger
> Type of BigInteger should be BIGINT
> ---
>
> Key: CALCITE-2211
> URL: https://issues.apache.org/jira/browse/CALCITE-2211
> Project: Calcite
> Issue Type: Bug
>Affects Versions: 1.15.0
>Reporter: Eyal Segal
>Assignee: Julian Hyde
>Priority: Major
>
> Vertica DB returns BigInteger values as BigInteger. It seems that
> JavaToSqlTypeConversionRules doesn't support mapping between BigInteger to
> BIGINT.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (CALCITE-2211) Type of BigInteger should be BIGINT
[
https://issues.apache.org/jira/browse/CALCITE-2211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16399040#comment-16399040
]
Eyal Segal edited comment on CALCITE-2211 at 3/14/18 6:21 PM:
--
It is also reproduced on MySql, with unsigned bigint column.
Consider this table:
{code:java}
create table test_table (id bigint(20) unsigned not null);
insert into test_table values (1);
{code}
Then when we fetch the result using JDBC:
{code:java}
try (Connection conn = new JDBC4Connection(db, 3306, p, "common",
"jdbc:apache:commons:dbcp:/db")) {
try (ResultSet rs = conn.prepareStatement("SELECT id FROM common.test_table
WHERE id=1").executeQuery()) {
while (rs.next()) {
System.out.print(rs.getObject("id").getClass());
}
}
}{code}
This will print java.math.BigInteger
was (Author: eysegal):
It is also reproduced on MySq, with unsigned bigint column.
Consider this table:
{code:java}
create table test_table (id bigint(20) unsigned not null);
insert into test_table values (1);
{code}
Then when we fetch the result using JDBC:
{code:java}
try (Connection conn = new JDBC4Connection(db, 3306, p, "common",
"jdbc:apache:commons:dbcp:/db")) {
try (ResultSet rs = conn.prepareStatement("SELECT id FROM common.test_table
WHERE id=1").executeQuery()) {
while (rs.next()) {
System.out.print(rs.getObject("id").getClass());
}
}
}{code}
This will print java.math.BigInteger
> Type of BigInteger should be BIGINT
> ---
>
> Key: CALCITE-2211
> URL: https://issues.apache.org/jira/browse/CALCITE-2211
> Project: Calcite
> Issue Type: Bug
>Affects Versions: 1.15.0
>Reporter: Eyal Segal
>Assignee: Julian Hyde
>Priority: Major
>
> Vertica DB returns BigInteger values as BigInteger. It seems that
> JavaToSqlTypeConversionRules doesn't support mapping between BigInteger to
> BIGINT.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2211) Type of BigInteger should be BIGINT
[
https://issues.apache.org/jira/browse/CALCITE-2211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16399040#comment-16399040
]
Eyal Segal commented on CALCITE-2211:
-
It is also reproduced on MySq, with unsigned bigint column.
Consider this table:
{code:java}
create table test_table (id bigint(20) unsigned not null);
insert into test_table values (1);
{code}
Then when we fetch the result using JDBC:
{code:java}
try (Connection conn = new JDBC4Connection(db, 3306, p, "common",
"jdbc:apache:commons:dbcp:/db")) {
try (ResultSet rs = conn.prepareStatement("SELECT id FROM common.test_table
WHERE id=1").executeQuery()) {
while (rs.next()) {
System.out.print(rs.getObject("id").getClass());
}
}
}{code}
This will print java.math.BigInteger
> Type of BigInteger should be BIGINT
> ---
>
> Key: CALCITE-2211
> URL: https://issues.apache.org/jira/browse/CALCITE-2211
> Project: Calcite
> Issue Type: Bug
>Affects Versions: 1.15.0
>Reporter: Eyal Segal
>Assignee: Julian Hyde
>Priority: Major
>
> Vertica DB returns BigInteger values as BigInteger. It seems that
> JavaToSqlTypeConversionRules doesn't support mapping between BigInteger to
> BIGINT.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (CALCITE-2211) Type of BigInteger should be BIGINT
Eyal Segal created CALCITE-2211: --- Summary: Type of BigInteger should be BIGINT Key: CALCITE-2211 URL: https://issues.apache.org/jira/browse/CALCITE-2211 Project: Calcite Issue Type: Bug Affects Versions: 1.15.0 Reporter: Eyal Segal Assignee: Julian Hyde Vertica DB returns BigInteger values as BigInteger. It seems that JavaToSqlTypeConversionRules doesn't support mapping between BigInteger to BIGINT. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CALCITE-2057) StackOverflowError when running a JDBC query
Eyal Segal created CALCITE-2057:
---
Summary: StackOverflowError when running a JDBC query
Key: CALCITE-2057
URL: https://issues.apache.org/jira/browse/CALCITE-2057
Project: Calcite
Issue Type: Bug
Components: build
Affects Versions: 1.14.0
Reporter: Eyal Segal
Assignee: Julian Hyde
Priority: Minor
I've ran the following code:
{code:java}
try (ResultSet rs = statement.executeQuery(
"SELECT p.name, r.views " +
"FROM reports.a as r " +
"INNER JOIN main.b as p ON p.id = CAST(r.p_id AS INT) AND
p.id = 196 " +
"WHERE p.id = 196 " +
"AND r.p_id = 196 " +
"AND r.data_timestamp = TIMESTAMP '2017-11-14 00:00:00' "
)) {
{code}
And I'm getting the following StackOverflowError:
{code:java}
Exception in thread "main" java.lang.StackOverflowError
at
com.google.common.collect.ImmutableList.indexOf(ImmutableList.java:339)
at GeneratedMetadataHandler_RowCount.getRowCount_$(Unknown Source)
at GeneratedMetadataHandler_RowCount.getRowCount(Unknown Source)
at
org.apache.calcite.rel.metadata.RelMetadataQuery.getRowCount(RelMetadataQuery.java:235)
at
org.apache.calcite.rel.metadata.RelMdRowCount.getRowCount(RelMdRowCount.java:71)
at GeneratedMetadataHandler_RowCount.getRowCount_$(Unknown Source)
at GeneratedMetadataHandler_RowCount.getRowCount(Unknown Source)
at
org.apache.calcite.rel.metadata.RelMetadataQuery.getRowCount(RelMetadataQuery.java:235)
at
org.apache.calcite.rel.metadata.RelMdUtil.estimateFilteredRows(RelMdUtil.java:718)
at
org.apache.calcite.rel.metadata.RelMdRowCount.getRowCount(RelMdRowCount.java:123)
at GeneratedMetadataHandler_RowCount.getRowCount_$(Unknown Source)
at GeneratedMetadataHandler_RowCount.getRowCount(Unknown Source)
at
org.apache.calcite.rel.metadata.RelMetadataQuery.getRowCount(RelMetadataQuery.java:235)
at
org.apache.calcite.rel.metadata.RelMdRowCount.getRowCount(RelMdRowCount.java:71)
at GeneratedMetadataHandler_RowCount.getRowCount_$(Unknown Source)
at GeneratedMetadataHandler_RowCount.getRowCount(Unknown Source)
at
org.apache.calcite.rel.metadata.RelMetadataQuery.getRowCount(RelMetadataQuery.java:235)
at
org.apache.calcite.rel.metadata.RelMdUtil.estimateFilteredRows(RelMdUtil.java:718)
at
org.apache.calcite.rel.metadata.RelMdRowCount.getRowCount(RelMdRowCount.java:123)
at GeneratedMetadataHandler_RowCount.getRowCount_$(Unknown Source)
at GeneratedMetadataHandler_RowCount.getRowCount(Unknown Source)
...
{code}
It's solved by removing "AND p.id = 196" from the INNER JOIN, but it's still
worth fixing.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
