[jira] [Commented] (CALCITE-1308) Implement remaining DatabaseMetaData operations in RemoteMeta
[ https://issues.apache.org/jira/browse/CALCITE-1308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17705677#comment-17705677 ] Magnus Mogren commented on CALCITE-1308: Any news on this one? Would really be helpful if the connection could return a useful java.sql.DatabaseMetaData > Implement remaining DatabaseMetaData operations in RemoteMeta > - > > Key: CALCITE-1308 > URL: https://issues.apache.org/jira/browse/CALCITE-1308 > Project: Calcite > Issue Type: Bug > Components: avatica >Reporter: Josh Elser >Assignee: Josh Elser >Priority: Critical > > Noticed in CALCITE-1291: sqlline normally highlights the column(s) which are > (part of the) primary key. Running a debugger over it quickly, showed that no > keys were returned over the DatabaseMetaData.getPrimaryKeys call. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CALCITE-5588) ArrayIndexOutOfBoundsException on "on not exists" or "on exists"
[
https://issues.apache.org/jira/browse/CALCITE-5588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17705675#comment-17705675
]
Magnus Mogren commented on CALCITE-5588:
Alright, the subject is changed now.
Same exception on "on exists" as for "on not exists".
You guys have my blessing to change the subject to whatever you want.
> ArrayIndexOutOfBoundsException on "on not exists" or "on exists"
>
>
> Key: CALCITE-5588
> URL: https://issues.apache.org/jira/browse/CALCITE-5588
> Project: Calcite
> Issue Type: Bug
>Affects Versions: 1.33.0
>Reporter: Magnus Mogren
>Priority: Major
>
> Execute this SQL
> {code:java}
> select Header.Name from ( VALUES (1, 'A'), (2, 'B')) as Header(Id, Name) join
> (values (11, 1), (12, 1), (21, 2)) as Version(Id, Parent) on not exists
> (select 1 from (values (11, 1), (12, 1), (21, 2)) as Version2(Id, Parent)
> where Version2.Parent = Header.Id and Version2.Id > Version.Id) {code}
>
> *Expected result*
> A ResultSet containing this
> |*NAME*|
> |A|
> |A|
> |B|
>
> *Actual result*
> {color:#FF}ArrayIndexOutOfBoundsException: Index 2 out of bounds for
> length 2{color}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-5588) ArrayIndexOutOfBoundsException on "on not exists" or "on exists"
[
https://issues.apache.org/jira/browse/CALCITE-5588?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Magnus Mogren updated CALCITE-5588:
---
Summary: ArrayIndexOutOfBoundsException on "on not exists" or "on exists"
(was: ArrayIndexOutOfBoundsException on select)
> ArrayIndexOutOfBoundsException on "on not exists" or "on exists"
>
>
> Key: CALCITE-5588
> URL: https://issues.apache.org/jira/browse/CALCITE-5588
> Project: Calcite
> Issue Type: Bug
>Affects Versions: 1.33.0
>Reporter: Magnus Mogren
>Priority: Major
>
> Execute this SQL
> {code:java}
> select Header.Name from ( VALUES (1, 'A'), (2, 'B')) as Header(Id, Name) join
> (values (11, 1), (12, 1), (21, 2)) as Version(Id, Parent) on not exists
> (select 1 from (values (11, 1), (12, 1), (21, 2)) as Version2(Id, Parent)
> where Version2.Parent = Header.Id and Version2.Id > Version.Id) {code}
>
> *Expected result*
> A ResultSet containing this
> |*NAME*|
> |A|
> |A|
> |B|
>
> *Actual result*
> {color:#FF}ArrayIndexOutOfBoundsException: Index 2 out of bounds for
> length 2{color}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CALCITE-5588) ArrayIndexOutOfBoundsException on select
Magnus Mogren created CALCITE-5588:
--
Summary: ArrayIndexOutOfBoundsException on select
Key: CALCITE-5588
URL: https://issues.apache.org/jira/browse/CALCITE-5588
Project: Calcite
Issue Type: Bug
Affects Versions: 1.33.0
Reporter: Magnus Mogren
Execute this SQL
{code:java}
select Header.Name from ( VALUES (1, 'A'), (2, 'B')) as Header(Id, Name) join
(values (11, 1), (12, 1), (21, 2)) as Version(Id, Parent) on not exists (select
1 from (values (11, 1), (12, 1), (21, 2)) as Version2(Id, Parent) where
Version2.Parent = Header.Id and Version2.Id > Version.Id) {code}
*Expected result*
A ResultSet containing this
|*NAME*|
|A|
|A|
|B|
*Actual result*
{color:#FF}ArrayIndexOutOfBoundsException: Index 2 out of bounds for length
2{color}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-5552) Returned timestamp is incorrect after the 100th row
[
https://issues.apache.org/jira/browse/CALCITE-5552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17695923#comment-17695923
]
Magnus Mogren commented on CALCITE-5552:
[~julianhyde] no that is not the case.
I have simplified the test case in the project even more to use raw java code
instead of any connection pool.
This is what the client does.
# Create a java.sql.Connection
# Create a java.sql.Statement
# Call statement.executeQuery to get a java.sql.ResultSet
# Get all rows returned in the resultset
If anything is re-executing something it is out of the control of my code. It
must be happening in Calcite/Avatica.
[calcite-timestamp-bug/ApplicationTests.java at main ·
nytro77/calcite-timestamp-bug
(github.com)|https://github.com/nytro77/calcite-timestamp-bug/blob/main/src/test/java/nytro77/calcitetimestampbug/ApplicationTests.java]
> Returned timestamp is incorrect after the 100th row
> ---
>
> Key: CALCITE-5552
> URL: https://issues.apache.org/jira/browse/CALCITE-5552
> Project: Calcite
> Issue Type: Bug
>Affects Versions: 1.33.0
>Reporter: Magnus Mogren
>Priority: Critical
> Attachments: TSTAMPS.csv
>
>
> When fetching data that contains timestamps the returned timestamp after row
> 100 is incorrect.
> This can be reproduced using the CSV adapter (calcite-csv) using the
> TSTAMPS.csv file attached. It contains 101 timestamps with the value
> 1900-01-01 00:00:00. The first 100 is returned correctly, but number 101 in
> the result has the value 1899-12-31 23:00:00 instead.
> Marking this bug as critical since not beeing able to trust the values
> returned by calcite is as bad as it gets in my opinion.
> I do not know if the bug is in calcite or avatica.
> I have created a project that reproduces the issue. You can find that here:
> [nytro77/calcite-timestamp-bug: Showcase bug in Calcite or Avatica that
> causes faulty timestamps to be returned
> (github.com)|https://github.com/nytro77/calcite-timestamp-bug]
> It starts an AvaticaServer that serves the attached file as a table using
> calcite-csv and a unit tests that connects to the server and fetches the data.
> Run it with
> {code:java}
> ./mvnw test{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-5552) Returned timestamp is incorrect after the 100th row
[
https://issues.apache.org/jira/browse/CALCITE-5552?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Magnus Mogren updated CALCITE-5552:
---
Summary: Returned timestamp is incorrect after the 100th row (was:
Returned timestamp is incorrect after the 100:th row)
> Returned timestamp is incorrect after the 100th row
> ---
>
> Key: CALCITE-5552
> URL: https://issues.apache.org/jira/browse/CALCITE-5552
> Project: Calcite
> Issue Type: Bug
>Affects Versions: 1.33.0
>Reporter: Magnus Mogren
>Priority: Critical
> Attachments: TSTAMPS.csv
>
>
> When fetching data that contains timestamps the returned timestamp after row
> 100 is incorrect.
> This can be reproduced using the CSV adapter (calcite-csv) using the
> TSTAMPS.csv file attached. It contains 101 timestamps with the value
> 1900-01-01 00:00:00. The first 100 is returned correctly, but number 101 in
> the result has the value 1899-12-31 23:00:00 instead.
> Marking this bug as critical since not beeing able to trust the values
> returned by calcite is as bad as it gets in my opinion.
> I do not know if the bug is in calcite or avatica.
> I have created a project that reproduces the issue. You can find that here:
> [nytro77/calcite-timestamp-bug: Showcase bug in Calcite or Avatica that
> causes faulty timestamps to be returned
> (github.com)|https://github.com/nytro77/calcite-timestamp-bug]
> It starts an AvaticaServer that serves the attached file as a table using
> calcite-csv and a unit tests that connects to the server and fetches the data.
> Run it with
> {code:java}
> ./mvnw test{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CALCITE-5552) Returned timestamp is incorrect after the 100:th row
Magnus Mogren created CALCITE-5552:
--
Summary: Returned timestamp is incorrect after the 100:th row
Key: CALCITE-5552
URL: https://issues.apache.org/jira/browse/CALCITE-5552
Project: Calcite
Issue Type: Bug
Affects Versions: 1.33.0
Reporter: Magnus Mogren
Attachments: TSTAMPS.csv
When fetching data that contains timestamps the returned timestamp after row
100 is incorrect.
This can be reproduced using the CSV adapter (calcite-csv) using the
TSTAMPS.csv file attached. It contains 101 timestamps with the value 1900-01-01
00:00:00. The first 100 is returned correctly, but number 101 in the result has
the value 1899-12-31 23:00:00 instead.
Marking this bug as critical since not beeing able to trust the values returned
by calcite is as bad as it gets in my opinion.
I do not know if the bug is in calcite or avatica.
I have created a project that reproduces the issue. You can find that here:
[nytro77/calcite-timestamp-bug: Showcase bug in Calcite or Avatica that causes
faulty timestamps to be returned
(github.com)|https://github.com/nytro77/calcite-timestamp-bug]
It starts an AvaticaServer that serves the attached file as a table using
calcite-csv and a unit tests that connects to the server and fetches the data.
Run it with
{code:java}
./mvnw test{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (CALCITE-5400) EnumerableCalc should not generate Enumerable.current with a non-idempotent function inside
[
https://issues.apache.org/jira/browse/CALCITE-5400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17687976#comment-17687976
]
Magnus Mogren edited comment on CALCITE-5400 at 2/13/23 3:08 PM:
-
[~dmsysolyatin] do you think that there will be time to fix this to 1.34.0 ?
was (Author: mamo):
[~dmsysolyatin] do you thing that there will be time to fix this to 1.34.0 ?
> EnumerableCalc should not generate Enumerable.current with a non-idempotent
> function inside
> ---
>
> Key: CALCITE-5400
> URL: https://issues.apache.org/jira/browse/CALCITE-5400
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.32.0
>Reporter: Dmitry Sysolyatin
>Priority: Major
>
> The problem has been found inside CALCITE-5388. The following query can
> return wrong result:
> {code:java}
> with
> CTE1(rand1, val1) as ( select RAND_INTEGER(2), id from (values (1), (2))
> as Vals1(id) ),
> CTE2(rand2, val2) as ( select RAND_INTEGER(2), id from (values (1), (2))
> as Vals2(id) )
> select
> CTE1.rand1,CTE1.val1,
> CTE2.rand2,
> CTE2.val2
> from
> CTE1,
> CTE2
> where
> CTE1.rand1 = CTE2.rand2
> {code}
> For instance it can return:
> |RAND1|VAL1|RAND2|VAL2|
> |1|1|1|1|
> |*{color:#ff}0{color}*|1|*{color:#ff}1{color}*|2|
> The problem is that EnumerableCalc generates Enumerable class that uses
> non-idempotent function `randInteger` inside 'current()' method:
> {code:java}
> new org.apache.calcite.linq4j.AbstractEnumerable() {
> public org.apache.calcite.linq4j.Enumerator enumerator() {
> return new org.apache.calcite.linq4j.Enumerator() {
> <.>
> public Object current() {
> return new Object[]{
>
> $L4J$C$new_org_apache_calcite_runtime_RandomFunction_.randInteger(2),
>
> org.apache.calcite.runtime.SqlFunctions.toInt(inputEnumerator.current())};
> }
> static final org.apache.calcite.runtime.RandomFunction
> $L4J$C$new_org_apache_calcite_runtime_RandomFunction_ = new
> org.apache.calcite.runtime.RandomFunction();
> };
> }
> };
> {code}
> if current() is called twice it can produce different results. What exactly
> happens inside EnumerableDefault.hashEquiJoin_ function (outers.current() is
> called inside moveNext() and current())
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-5400) EnumerableCalc should not generate Enumerable.current with a non-idempotent function inside
[
https://issues.apache.org/jira/browse/CALCITE-5400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17687976#comment-17687976
]
Magnus Mogren commented on CALCITE-5400:
[~dmsysolyatin] do you thing that there will be time to fix this to 1.34.0 ?
> EnumerableCalc should not generate Enumerable.current with a non-idempotent
> function inside
> ---
>
> Key: CALCITE-5400
> URL: https://issues.apache.org/jira/browse/CALCITE-5400
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.32.0
>Reporter: Dmitry Sysolyatin
>Priority: Major
>
> The problem has been found inside CALCITE-5388. The following query can
> return wrong result:
> {code:java}
> with
> CTE1(rand1, val1) as ( select RAND_INTEGER(2), id from (values (1), (2))
> as Vals1(id) ),
> CTE2(rand2, val2) as ( select RAND_INTEGER(2), id from (values (1), (2))
> as Vals2(id) )
> select
> CTE1.rand1,CTE1.val1,
> CTE2.rand2,
> CTE2.val2
> from
> CTE1,
> CTE2
> where
> CTE1.rand1 = CTE2.rand2
> {code}
> For instance it can return:
> |RAND1|VAL1|RAND2|VAL2|
> |1|1|1|1|
> |*{color:#ff}0{color}*|1|*{color:#ff}1{color}*|2|
> The problem is that EnumerableCalc generates Enumerable class that uses
> non-idempotent function `randInteger` inside 'current()' method:
> {code:java}
> new org.apache.calcite.linq4j.AbstractEnumerable() {
> public org.apache.calcite.linq4j.Enumerator enumerator() {
> return new org.apache.calcite.linq4j.Enumerator() {
> <.>
> public Object current() {
> return new Object[]{
>
> $L4J$C$new_org_apache_calcite_runtime_RandomFunction_.randInteger(2),
>
> org.apache.calcite.runtime.SqlFunctions.toInt(inputEnumerator.current())};
> }
> static final org.apache.calcite.runtime.RandomFunction
> $L4J$C$new_org_apache_calcite_runtime_RandomFunction_ = new
> org.apache.calcite.runtime.RandomFunction();
> };
> }
> };
> {code}
> if current() is called twice it can produce different results. What exactly
> happens inside EnumerableDefault.hashEquiJoin_ function (outers.current() is
> called inside moveNext() and current())
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (CALCITE-5388) No result when using ROW_NUMBER in two common table expressions
[
https://issues.apache.org/jira/browse/CALCITE-5388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17637815#comment-17637815
]
Magnus Mogren edited comment on CALCITE-5388 at 11/23/22 2:56 PM:
--
[~dmsysolyatin] found another strange thing. Should i register another bug for
this or is it something that is missing from your bugfix?
This SQL sometimes gives faulty matches.
{code:java}
with
CTE1(rand1, val1) as ( select RAND_INTEGER(2), id from (values (1), (2)) as
Vals1(id) ),
CTE2(rand2, val2) as ( select RAND_INTEGER(2), id from (values (1), (2)) as
Vals2(id) )
select
CTE1.rand1,
CTE1.val1,
CTE2.rand2,
CTE2.val2
from
CTE1,
CTE2
where
CTE1.rand1 = CTE2.rand2 {code}
Just run it a few times and you will get faulty result.
For instance:
|RAND1|VAL1|RAND2|VAL2|
|1|1|1|1|
|*{color:#ff}0{color}*|1|*{color:#ff}1{color}*|2|
or
|RAND1|VAL1|RAND2|VAL2|
|{color:#ff}*1*{color}|1|*{color:#ff}0{color}*|1|
|0|2|0|1|
was (Author: mamo):
[~dmsysolyatin] found onother strange thing. Should i register another bug for
this or is it something that is missing from your bugfix?
This SQL sometimes gives faulty matches.
{code:java}
with
CTE1(rand1, val1) as ( select RAND_INTEGER(2), id from (values (1), (2)) as
Vals1(id) ),
CTE2(rand2, val2) as ( select RAND_INTEGER(2), id from (values (1), (2)) as
Vals2(id) )
select
CTE1.rand1,
CTE1.val1,
CTE2.rand2,
CTE2.val2
from
CTE1,
CTE2
where
CTE1.rand1 = CTE2.rand2 {code}
Just run it a few times and you will get faulty result.
For instance:
|RAND1|VAL1|RAND2|VAL2|
|1|1|1|1|
|*{color:#FF}0{color}*|1|*{color:#FF}1{color}*|2|
or
|RAND1|VAL1|RAND2|VAL2|
|{color:#FF}*1*{color}|1|*{color:#FF}0{color}*|1|
|0|2|0|1|
> No result when using ROW_NUMBER in two common table expressions
> ---
>
> Key: CALCITE-5388
> URL: https://issues.apache.org/jira/browse/CALCITE-5388
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.32.0
>Reporter: Magnus Mogren
>Assignee: Dmitry Sysolyatin
>Priority: Major
> Fix For: 1.33.0
>
>
> This SQL produces no result.
>
> {code:java}
> with
> CTE1(rownr1, val1) as ( select ROW_NUMBER() OVER(ORDER BY id ASC), id
> from (values (1), (2)) as Vals1(id) ),
> CTE2(rownr2, val2) as ( select ROW_NUMBER() OVER(ORDER BY id ASC), id
> from (values (1), (2)) as Vals2(id) )
> select
> CTE1.rownr1,
> CTE1.val1,
> CTE2.rownr2,
> CTE2.val2
> from
> CTE1,
> CTE2
> where
> CTE1.val1 = CTE2.val2{code}
>
> However, if you remove CTE.rownr2 from the selected columns it produces the 2
> rows as expected:
> |ROWNR1|VAL1|VAL2|
> |1|1|1|
> |2|2|2|
>
> Same type of problem occurs of you try to compare the two rownr columns. No
> result for this:
> {code:java}
> with
> CTE1(rownr1, val1) as ( select ROW_NUMBER() OVER(ORDER BY id ASC), id
> from (values (1), (2)) as Vals1(id) ),
> CTE2(rownr2, val2) as ( select ROW_NUMBER() OVER(ORDER BY id ASC), id
> from (values (1), (2)) as Vals2(id) )
> select
> CTE1.val1,
> CTE2.val2
> from
> CTE1,
> CTE2
> where
> CTE1.rownr1 = CTE2.rownr2{code}
>
> Does calcite get confused over the fact that two ROW_NUMBER functions are
> used among the common table expressions?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-5388) No result when using ROW_NUMBER in two common table expressions
[
https://issues.apache.org/jira/browse/CALCITE-5388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17637815#comment-17637815
]
Magnus Mogren commented on CALCITE-5388:
[~dmsysolyatin] found onother strange thing. Should i register another bug for
this or is it something that is missing from your bugfix?
This SQL sometimes gives faulty matches.
{code:java}
with
CTE1(rand1, val1) as ( select RAND_INTEGER(2), id from (values (1), (2)) as
Vals1(id) ),
CTE2(rand2, val2) as ( select RAND_INTEGER(2), id from (values (1), (2)) as
Vals2(id) )
select
CTE1.rand1,
CTE1.val1,
CTE2.rand2,
CTE2.val2
from
CTE1,
CTE2
where
CTE1.rand1 = CTE2.rand2 {code}
Just run it a few times and you will get faulty result.
For instance:
|RAND1|VAL1|RAND2|VAL2|
|1|1|1|1|
|*{color:#FF}0{color}*|1|*{color:#FF}1{color}*|2|
or
|RAND1|VAL1|RAND2|VAL2|
|{color:#FF}*1*{color}|1|*{color:#FF}0{color}*|1|
|0|2|0|1|
> No result when using ROW_NUMBER in two common table expressions
> ---
>
> Key: CALCITE-5388
> URL: https://issues.apache.org/jira/browse/CALCITE-5388
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.32.0
>Reporter: Magnus Mogren
>Assignee: Dmitry Sysolyatin
>Priority: Major
> Fix For: 1.33.0
>
>
> This SQL produces no result.
>
> {code:java}
> with
> CTE1(rownr1, val1) as ( select ROW_NUMBER() OVER(ORDER BY id ASC), id
> from (values (1), (2)) as Vals1(id) ),
> CTE2(rownr2, val2) as ( select ROW_NUMBER() OVER(ORDER BY id ASC), id
> from (values (1), (2)) as Vals2(id) )
> select
> CTE1.rownr1,
> CTE1.val1,
> CTE2.rownr2,
> CTE2.val2
> from
> CTE1,
> CTE2
> where
> CTE1.val1 = CTE2.val2{code}
>
> However, if you remove CTE.rownr2 from the selected columns it produces the 2
> rows as expected:
> |ROWNR1|VAL1|VAL2|
> |1|1|1|
> |2|2|2|
>
> Same type of problem occurs of you try to compare the two rownr columns. No
> result for this:
> {code:java}
> with
> CTE1(rownr1, val1) as ( select ROW_NUMBER() OVER(ORDER BY id ASC), id
> from (values (1), (2)) as Vals1(id) ),
> CTE2(rownr2, val2) as ( select ROW_NUMBER() OVER(ORDER BY id ASC), id
> from (values (1), (2)) as Vals2(id) )
> select
> CTE1.val1,
> CTE2.val2
> from
> CTE1,
> CTE2
> where
> CTE1.rownr1 = CTE2.rownr2{code}
>
> Does calcite get confused over the fact that two ROW_NUMBER functions are
> used among the common table expressions?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-5388) No result when using ROW_NUMBER in two common table expressions
[
https://issues.apache.org/jira/browse/CALCITE-5388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17636814#comment-17636814
]
Magnus Mogren commented on CALCITE-5388:
[~dmsysolyatin] [~libenchao] I checked out the PR and tried it out with my real
use case and it works like a charm! Will run with 1.33.0-SNAPSHOT from the PR
branch until 1.33.0 is released. Thanks so much for fixing this! :)
> No result when using ROW_NUMBER in two common table expressions
> ---
>
> Key: CALCITE-5388
> URL: https://issues.apache.org/jira/browse/CALCITE-5388
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.32.0
>Reporter: Magnus Mogren
>Assignee: Dmitry Sysolyatin
>Priority: Major
> Fix For: 1.33.0
>
>
> This SQL produces no result.
>
> {code:java}
> with
> CTE1(rownr1, val1) as ( select ROW_NUMBER() OVER(ORDER BY id ASC), id
> from (values (1), (2)) as Vals1(id) ),
> CTE2(rownr2, val2) as ( select ROW_NUMBER() OVER(ORDER BY id ASC), id
> from (values (1), (2)) as Vals2(id) )
> select
> CTE1.rownr1,
> CTE1.val1,
> CTE2.rownr2,
> CTE2.val2
> from
> CTE1,
> CTE2
> where
> CTE1.val1 = CTE2.val2{code}
>
> However, if you remove CTE.rownr2 from the selected columns it produces the 2
> rows as expected:
> |ROWNR1|VAL1|VAL2|
> |1|1|1|
> |2|2|2|
>
> Same type of problem occurs of you try to compare the two rownr columns. No
> result for this:
> {code:java}
> with
> CTE1(rownr1, val1) as ( select ROW_NUMBER() OVER(ORDER BY id ASC), id
> from (values (1), (2)) as Vals1(id) ),
> CTE2(rownr2, val2) as ( select ROW_NUMBER() OVER(ORDER BY id ASC), id
> from (values (1), (2)) as Vals2(id) )
> select
> CTE1.val1,
> CTE2.val2
> from
> CTE1,
> CTE2
> where
> CTE1.rownr1 = CTE2.rownr2{code}
>
> Does calcite get confused over the fact that two ROW_NUMBER functions are
> used among the common table expressions?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-5388) No result when using ROW_NUMBER in two common table expressions
[
https://issues.apache.org/jira/browse/CALCITE-5388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Magnus Mogren updated CALCITE-5388:
---
Affects Version/s: 1.32.0
> No result when using ROW_NUMBER in two common table expressions
> ---
>
> Key: CALCITE-5388
> URL: https://issues.apache.org/jira/browse/CALCITE-5388
> Project: Calcite
> Issue Type: Bug
>Affects Versions: 1.32.0
>Reporter: Magnus Mogren
>Priority: Major
>
> This SQL produces no result.
>
> {code:java}
> with
> CTE1(rownr1, val1) as ( select ROW_NUMBER() OVER(ORDER BY id ASC), id
> from (values (1), (2)) as Vals1(id) ),
> CTE2(rownr2, val2) as ( select ROW_NUMBER() OVER(ORDER BY id ASC), id
> from (values (1), (2)) as Vals2(id) )
> select
> CTE1.rownr1,
> CTE1.val1,
> CTE2.rownr2,
> CTE2.val2
> from
> CTE1,
> CTE2
> where
> CTE1.val1 = CTE2.val2{code}
>
> However, if you remove CTE.rownr2 from the selected columns it produces the 2
> rows as expected:
> |ROWNR1|VAL1|VAL2|
> |1|1|1|
> |2|2|2|
>
> Same type of problem occurs of you try to compare the two rownr columns. No
> result for this:
> {code:java}
> with
> CTE1(rownr1, val1) as ( select ROW_NUMBER() OVER(ORDER BY id ASC), id
> from (values (1), (2)) as Vals1(id) ),
> CTE2(rownr2, val2) as ( select ROW_NUMBER() OVER(ORDER BY id ASC), id
> from (values (1), (2)) as Vals2(id) )
> select
> CTE1.val1,
> CTE2.val2
> from
> CTE1,
> CTE2
> where
> CTE1.rownr1 = CTE2.rownr2{code}
>
> Does calcite get confused over the fact that two ROW_NUMBER functions are
> used among the common table expressions?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-5388) No result when using ROW_NUMBER in two common table expressions
[
https://issues.apache.org/jira/browse/CALCITE-5388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Magnus Mogren updated CALCITE-5388:
---
Description:
This SQL produces no result.
{code:java}
with
CTE1(rownr1, val1) as ( select ROW_NUMBER() OVER(ORDER BY id ASC), id from
(values (1), (2)) as Vals1(id) ),
CTE2(rownr2, val2) as ( select ROW_NUMBER() OVER(ORDER BY id ASC), id from
(values (1), (2)) as Vals2(id) )
select
CTE1.rownr1,
CTE1.val1,
CTE2.rownr2,
CTE2.val2
from
CTE1,
CTE2
where
CTE1.val1 = CTE2.val2{code}
However, if you remove CTE.rownr2 from the selected columns it produces the 2
rows as expected:
|ROWNR1|VAL1|VAL2|
|1|1|1|
|2|2|2|
Same type of problem occurs of you try to compare the two rownr columns. No
result for this:
{code:java}
with
CTE1(rownr1, val1) as ( select ROW_NUMBER() OVER(ORDER BY id ASC), id from
(values (1), (2)) as Vals1(id) ),
CTE2(rownr2, val2) as ( select ROW_NUMBER() OVER(ORDER BY id ASC), id from
(values (1), (2)) as Vals2(id) )
select
CTE1.val1,
CTE2.val2
from
CTE1,
CTE2
where
CTE1.rownr1 = CTE2.rownr2{code}
Does calcite get confused over the fact that two ROW_NUMBER functions are used
among the common table expressions?
was:
This SQL produces no result.
{code:java}
with
CTE1(rownr1, val1) as ( select ROW_NUMBER() OVER(ORDER BY id ASC), id from
(values (1), (2)) as Vals1(id) ),
CTE2(rownr2, val2) as ( select ROW_NUMBER() OVER(ORDER BY id ASC), id from
(values (1), (2)) as Vals2(id) )
select
CTE1.rownr1,
CTE1.val1,
CTE2.rownr2,
CTE2.val2
from
CTE1,
CTE2
where
CTE1.val1 = CTE2.val2{code}
However, if you remove CTE.rownr2 from the selected columns it produces the 2
rows as expected:
|ROWNR1|VAL1|VAL2|
|1|1|1|
|2|2|2|
Same type of problem occurs of you try to compare the two rownr columns. No
result for this:
{code:java}
with
CTE1(rownr1, val1) as ( select ROW_NUMBER() OVER(ORDER BY id ASC), id from
(values (1), (2)) as Vals1(id) ),
CTE2(rownr2, val2) as ( select ROW_NUMBER() OVER(ORDER BY id ASC), id from
(values (1), (2)) as Vals2(id) )
select
CTE1.val1,
CTE2.val2
from
CTE1,
CTE2
where
CTE1.rownr1 = CTE2.rownr2{code}
Does calcite get confused over the fact that to ROW_NUMBER functions are used
among the common table expressions?
> No result when using ROW_NUMBER in two common table expressions
> ---
>
> Key: CALCITE-5388
> URL: https://issues.apache.org/jira/browse/CALCITE-5388
> Project: Calcite
> Issue Type: Bug
>Reporter: Magnus Mogren
>Priority: Major
>
> This SQL produces no result.
>
> {code:java}
> with
> CTE1(rownr1, val1) as ( select ROW_NUMBER() OVER(ORDER BY id ASC), id
> from (values (1), (2)) as Vals1(id) ),
> CTE2(rownr2, val2) as ( select ROW_NUMBER() OVER(ORDER BY id ASC), id
> from (values (1), (2)) as Vals2(id) )
> select
> CTE1.rownr1,
> CTE1.val1,
> CTE2.rownr2,
> CTE2.val2
> from
> CTE1,
> CTE2
> where
> CTE1.val1 = CTE2.val2{code}
>
> However, if you remove CTE.rownr2 from the selected columns it produces the 2
> rows as expected:
> |ROWNR1|VAL1|VAL2|
> |1|1|1|
> |2|2|2|
>
> Same type of problem occurs of you try to compare the two rownr columns. No
> result for this:
> {code:java}
> with
> CTE1(rownr1, val1) as ( select ROW_NUMBER() OVER(ORDER BY id ASC), id
> from (values (1), (2)) as Vals1(id) ),
> CTE2(rownr2, val2) as ( select ROW_NUMBER() OVER(ORDER BY id ASC), id
> from (values (1), (2)) as Vals2(id) )
> select
> CTE1.val1,
> CTE2.val2
> from
> CTE1,
> CTE2
> where
> CTE1.rownr1 = CTE2.rownr2{code}
>
> Does calcite get confused over the fact that two ROW_NUMBER functions are
> used among the common table expressions?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CALCITE-5388) No result when using ROW_NUMBER in two common table expressions
Magnus Mogren created CALCITE-5388:
--
Summary: No result when using ROW_NUMBER in two common table
expressions
Key: CALCITE-5388
URL: https://issues.apache.org/jira/browse/CALCITE-5388
Project: Calcite
Issue Type: Bug
Reporter: Magnus Mogren
This SQL produces no result.
{code:java}
with
CTE1(rownr1, val1) as ( select ROW_NUMBER() OVER(ORDER BY id ASC), id from
(values (1), (2)) as Vals1(id) ),
CTE2(rownr2, val2) as ( select ROW_NUMBER() OVER(ORDER BY id ASC), id from
(values (1), (2)) as Vals2(id) )
select
CTE1.rownr1,
CTE1.val1,
CTE2.rownr2,
CTE2.val2
from
CTE1,
CTE2
where
CTE1.val1 = CTE2.val2{code}
However, if you remove CTE.rownr2 from the selected columns it produces the 2
rows as expected:
|ROWNR1|VAL1|VAL2|
|1|1|1|
|2|2|2|
Same type of problem occurs of you try to compare the two rownr columns. No
result for this:
{code:java}
with
CTE1(rownr1, val1) as ( select ROW_NUMBER() OVER(ORDER BY id ASC), id from
(values (1), (2)) as Vals1(id) ),
CTE2(rownr2, val2) as ( select ROW_NUMBER() OVER(ORDER BY id ASC), id from
(values (1), (2)) as Vals2(id) )
select
CTE1.val1,
CTE2.val2
from
CTE1,
CTE2
where
CTE1.rownr1 = CTE2.rownr2{code}
Does calcite get confused over the fact that to ROW_NUMBER functions are used
among the common table expressions?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-4945) Runtime compilation fails on subquery.
[
https://issues.apache.org/jira/browse/CALCITE-4945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17633560#comment-17633560
]
Magnus Mogren commented on CALCITE-4945:
[~julianhyde] Is this bug scheduled for fix in any upcoming release?
Encountered this error today on Calcite 1.32.
> Runtime compilation fails on subquery.
> --
>
> Key: CALCITE-4945
> URL: https://issues.apache.org/jira/browse/CALCITE-4945
> Project: Calcite
> Issue Type: Bug
>Affects Versions: 1.29.0
>Reporter: Vladimir Steshin
>Priority: Major
>
> While researching CALCITE-685 (calcite 1.29, master branch), I met an
> calcite-runtime compilation error.
> Request example:
> {code:sql}
> select e.department_id, (select 1 from employee e2 where e.department_id =
> -100) from employee e;
> {code}
> Stacktrace:
> {code:java}
> 2021-12-16 21:42:38,032 [ForkJoinPool-1-worker-9] INFO - open start - state
> modified
> 2021-12-16 21:42:43,612 [ForkJoinPool-1-worker-9] INFO - Checkpoint start
> 2021-12-16 21:42:43,613 [ForkJoinPool-1-worker-9] INFO - Checkpoint end -
> txts: 279
> Error while executing SQL "select e.department_id,
>( select e2.employee_id
> from employee e2
> where e.department_id = 1000
>)
> from employee e
> ": Error while compiling generated Java code:
> public static class Record2_0 implements java.io.Serializable {
> public boolean f0;
> public int f1;
> public Record2_0() {}
> public boolean equals(Object o) {
> if (this == o) {
> return true;
> }
> if (!(o instanceof Record2_0)) {
> return false;
> }
> return this.f0 == ((Record2_0) o).f0 && this.f1 == ((Record2_0) o).f1;
> }
> public int hashCode() {
> int h = 0;
> h = org.apache.calcite.runtime.Utilities.hash(h, this.f0);
> h = org.apache.calcite.runtime.Utilities.hash(h, this.f1);
> return h;
> }
> public int compareTo(Record2_0 that) {
> int c;
> c = org.apache.calcite.runtime.Utilities.compare(this.f0, that.f0);
> if (c != 0) {
> return c;
> }
> c = org.apache.calcite.runtime.Utilities.compare(this.f1, that.f1);
> if (c != 0) {
> return c;
> }
> return 0;
> }
> public String toString() {
> return "{f0=" + this.f0 + ", f1=" + this.f1 + "}";
> }
> }
> public org.apache.calcite.linq4j.Enumerable bind(final
> org.apache.calcite.DataContext root) {
> final org.apache.calcite.linq4j.Enumerable _inputEnumerable =
> org.apache.calcite.schema.Schemas.queryable(root,
> root.getRootSchema().getSubSchema("foodmart2"), java.lang.Object[].class,
> "employee").asEnumerable();
> final org.apache.calcite.linq4j.AbstractEnumerable child = new
> org.apache.calcite.linq4j.AbstractEnumerable(){
> public org.apache.calcite.linq4j.Enumerator enumerator() {
> return new org.apache.calcite.linq4j.Enumerator(){
> public final org.apache.calcite.linq4j.Enumerator inputEnumerator =
> _inputEnumerable.enumerator();
> public void reset() {
> inputEnumerator.reset();
> }
> public boolean moveNext() {
> return inputEnumerator.moveNext();
> }
> public void close() {
> inputEnumerator.close();
> }
> public Object current() {
> final Object[] current = (Object[]) inputEnumerator.current();
> return new Object[] {
> current[0],
> current[7],
> org.apache.calcite.runtime.SqlFunctions.toInt(current[7]) ==
> 1000};
> }
> };
> }
> };
> final org.apache.calcite.linq4j.Enumerable _inputEnumerable0 =
> org.apache.calcite.schema.Schemas.queryable(root,
> root.getRootSchema().getSubSchema("foodmart2"), java.lang.Object[].class,
> "employee").asEnumerable();
> final org.apache.calcite.linq4j.AbstractEnumerable left0 = new
> org.apache.calcite.linq4j.AbstractEnumerable(){
> public org.apache.calcite.linq4j.Enumerator enumerator() {
> return new org.apache.calcite.linq4j.Enumerator(){
> public final org.apache.calcite.linq4j.Enumerator inputEnumerator =
> _inputEnumerable0.enumerator();
> public void reset() {
> inputEnumerator.reset();
> }
> public boolean moveNext() {
> return inputEnumerator.moveNext();
> }
> public void close() {
> inputEnumerator.close();
> }
> public Object current() {
> return org.apache.calcite.runtime.SqlFunctions.toInt(((Object[])
> inputEnumerator.current())[0]);
> }
> };
> }
> };
> final org.apache.calcite.linq4j.Enumerable _inputEnumerable00 =
> org.apache.calcite.schema.Schemas.queryable(root,
>
[jira] [Commented] (CALCITE-5078) ORDER BY gets confused by upper/lower case
[
https://issues.apache.org/jira/browse/CALCITE-5078?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17515963#comment-17515963
]
Magnus Mogren commented on CALCITE-5078:
Great! Thanks for the help
> ORDER BY gets confused by upper/lower case
> --
>
> Key: CALCITE-5078
> URL: https://issues.apache.org/jira/browse/CALCITE-5078
> Project: Calcite
> Issue Type: Bug
>Affects Versions: 1.30.0
>Reporter: Magnus Mogren
>Priority: Major
>
> This SQL returnes the values in the wrong order:
> {{SELECT * FROM (VALUES ('a'), ('B')) AS tbl(col1) order by col1 asc}}
> "B" is returned before "a".
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (CALCITE-5078) ORDER BY gets confused by upper/lower case
[
https://issues.apache.org/jira/browse/CALCITE-5078?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17515896#comment-17515896
]
Magnus Mogren commented on CALCITE-5078:
Ok. I tried the SQL on both PostgreSQL, DB2 and SQL Server and they all
returned 'a' before 'B' but never reflected on collation. They all use some
Swedish collation.
> ORDER BY gets confused by upper/lower case
> --
>
> Key: CALCITE-5078
> URL: https://issues.apache.org/jira/browse/CALCITE-5078
> Project: Calcite
> Issue Type: Bug
>Affects Versions: 1.30.0
>Reporter: Magnus Mogren
>Priority: Major
>
> This SQL returnes the values in the wrong order:
> {{SELECT * FROM (VALUES ('a'), ('B')) AS tbl(col1) order by col1 asc}}
> "B" is returned before "a".
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (CALCITE-5078) ORDER BY gets confused by upper/lower case
Magnus Mogren created CALCITE-5078:
--
Summary: ORDER BY gets confused by upper/lower case
Key: CALCITE-5078
URL: https://issues.apache.org/jira/browse/CALCITE-5078
Project: Calcite
Issue Type: Bug
Affects Versions: 1.30.0
Reporter: Magnus Mogren
This SQL returnes the values in the wrong order:
{{SELECT * FROM (VALUES ('a'), ('B')) AS tbl(col1) order by col1 asc}}
"B" is returned before "a".
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (CALCITE-4903) Avatica pads values returned from values-clause to same length
[
https://issues.apache.org/jira/browse/CALCITE-4903?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17450325#comment-17450325
]
Magnus Mogren commented on CALCITE-4903:
[~julianhyde] there seems to be some bug in Calcite or Avatica after all..
When returning more than one value from the values clause all works as expected.
Calling ResultSet.getMetaData().getColumnType(1) for the ResultSet returned
when executing the SQL statement now returns 12 (java.sql.Types.VARCHAR)
When just one value from values clause it still treats that as CHAR with fixed
length.
{code:java}
select * from (values ('abcd')) {code}
> Avatica pads values returned from values-clause to same length
> --
>
> Key: CALCITE-4903
> URL: https://issues.apache.org/jira/browse/CALCITE-4903
> Project: Calcite
> Issue Type: Bug
> Components: avatica, jdbc-driver
>Affects Versions: avatica-1.19.0
>Reporter: Magnus Mogren
>Priority: Critical
>
> When executing a values clause, the avatica driver returns the wrong values.
> It seems it checks what value is longest and then pads all other values in
> the values clause to the same length.
> {*}SQL{*}:
> {code:java}
> select * from (values ('a'),('abcd')){code}
> {*}Expected values to be returned{*}:
> {{'a'}}
> {{'abcd'}}
>
> {*}Actual values returned{*}:
> {{'a '}}
> {{'abcd'}}
> It seems that for some reason the driver thinks the columns for the
> values-clause should be treated as fixed length CHAR(4) instead of VARCHAR.
> This is also verified by calling ResultSet.getMetaData().getColumnType(1) for
> the ResultSet returned when executing the SQL statement. Indeed it returns 1
> (java.sql.Types.CHAR)
> IMHO this is a high priority bug because:
> # It affects all Calcite adapters. In my example above no remote call is
> ever done.
> # The values in the values-clause is distorted by the driver. It is not just
> faulty metadata returned by the call to ResultSet.getMetaData() but the
> actual returned data itself that are corrupted.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (CALCITE-4903) Avatica pads values returned from values-clause to same length
[
https://issues.apache.org/jira/browse/CALCITE-4903?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17449304#comment-17449304
]
Magnus Mogren commented on CALCITE-4903:
[~julianhyde] I looked through the commens of CALCITE-4590 and then created a
class that extends org.apache.calcite.rel.type.RelDataTypeSystemImpl and
returns true instead of false from the shouldConvertRaggedUnionTypesToVarying()
method.
Problem solved! :)
This bug can be closed.
> Avatica pads values returned from values-clause to same length
> --
>
> Key: CALCITE-4903
> URL: https://issues.apache.org/jira/browse/CALCITE-4903
> Project: Calcite
> Issue Type: Bug
> Components: avatica, jdbc-driver
>Affects Versions: avatica-1.19.0
>Reporter: Magnus Mogren
>Priority: Critical
>
> When executing a values clause, the avatica driver returns the wrong values.
> It seems it checks what value is longest and then pads all other values in
> the values clause to the same length.
> {*}SQL{*}:
> {code:java}
> select * from (values ('a'),('abcd')){code}
> {*}Expected values to be returned{*}:
> {{'a'}}
> {{'abcd'}}
>
> {*}Actual values returned{*}:
> {{'a '}}
> {{'abcd'}}
> It seems that for some reason the driver thinks the columns for the
> values-clause should be treated as fixed length CHAR(4) instead of VARCHAR.
> This is also verified by calling ResultSet.getMetaData().getColumnType(1) for
> the ResultSet returned when executing the SQL statement. Indeed it returns 1
> (java.sql.Types.CHAR)
> IMHO this is a high priority bug because:
> # It affects all Calcite adapters. In my example above no remote call is
> ever done.
> # The values in the values-clause is distorted by the driver. It is not just
> faulty metadata returned by the call to ResultSet.getMetaData() but the
> actual returned data itself that are corrupted.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (CALCITE-4903) Avatica pads values returned from values-clause to same length
[
https://issues.apache.org/jira/browse/CALCITE-4903?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Magnus Mogren updated CALCITE-4903:
---
Description:
When executing a values clause, the avatica driver returns the wrong values.
It seems it checks what value is longest and then pads all other values in the
values clause to the same length.
{*}SQL{*}:
{code:java}
select * from (values ('a'),('abcd')){code}
{*}Expected values to be returned{*}:
{{'a'}}
{{'abcd'}}
{*}Actual values returned{*}:
{{'a '}}
{{'abcd'}}
It seems that for some reason the driver thinks the columns for the
values-clause should be treated as fixed length CHAR(4) instead of VARCHAR.
This is also verified by calling ResultSet.getMetaData().getColumnType(1) for
the ResultSet returned when executing the SQL statement. Indeed it returns 1
(java.sql.Types.CHAR)
IMHO this is a high priority bug because:
# It affects all Calcite adapters. In my example above no remote call is ever
done.
# The values in the values-clause is distorted by the driver. It is not just
faulty metadata returned by the call to ResultSet.getMetaData() but the actual
returned data itself that are corrupted.
was:
When executing a values clause, the avatica driver returns the wrong values.
It seems it checks what value is longest and then pads all other values in the
values clause to the same length.
{*}SQL{*}:
{code:java}
select * from (values ('a'),('abcd')){code}
{*}Expected values to be returned{*}:
{{'a'}}
{{'abcd'}}
{*}Actual values returned{*}:
{{'a '}}
{{'abcd'}}
It seems that for some reason the driver thinks the columns for the
values-clause should be treated as fixed length CHAR(4) instead of VARCHAR.
This is also verified by calling ResultSet.getMetaData().getColumnType(1) for
the ResultSet returned when executing the SQL statement. Indeed it returns 1
(java.sql.Types.CHAR)
In my optinion this is a high priority bug because:
# It affects all Calcite adapters. In my example above no remote call is ever
done.
# The values in the values-clause is distorted by the driver. It is not just
faulty metadata returned by the call to ResultSet.getMetaData() but the actual
returned data itself that are corrupted.
> Avatica pads values returned from values-clause to same length
> --
>
> Key: CALCITE-4903
> URL: https://issues.apache.org/jira/browse/CALCITE-4903
> Project: Calcite
> Issue Type: Bug
> Components: avatica, jdbc-driver
>Affects Versions: avatica-1.19.0
>Reporter: Magnus Mogren
>Priority: Critical
>
> When executing a values clause, the avatica driver returns the wrong values.
> It seems it checks what value is longest and then pads all other values in
> the values clause to the same length.
> {*}SQL{*}:
> {code:java}
> select * from (values ('a'),('abcd')){code}
> {*}Expected values to be returned{*}:
> {{'a'}}
> {{'abcd'}}
>
> {*}Actual values returned{*}:
> {{'a '}}
> {{'abcd'}}
> It seems that for some reason the driver thinks the columns for the
> values-clause should be treated as fixed length CHAR(4) instead of VARCHAR.
> This is also verified by calling ResultSet.getMetaData().getColumnType(1) for
> the ResultSet returned when executing the SQL statement. Indeed it returns 1
> (java.sql.Types.CHAR)
> IMHO this is a high priority bug because:
> # It affects all Calcite adapters. In my example above no remote call is
> ever done.
> # The values in the values-clause is distorted by the driver. It is not just
> faulty metadata returned by the call to ResultSet.getMetaData() but the
> actual returned data itself that are corrupted.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (CALCITE-4903) Avatica pads values returned from values-clause to same length
[
https://issues.apache.org/jira/browse/CALCITE-4903?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Magnus Mogren updated CALCITE-4903:
---
Priority: Critical (was: Major)
> Avatica pads values returned from values-clause to same length
> --
>
> Key: CALCITE-4903
> URL: https://issues.apache.org/jira/browse/CALCITE-4903
> Project: Calcite
> Issue Type: Bug
> Components: avatica, jdbc-driver
>Affects Versions: avatica-1.19.0
>Reporter: Magnus Mogren
>Priority: Critical
>
> When executing a values clause, the avatica driver returns the wrong values.
> It seems it checks what value is longest and then pads all other values in
> the values clause to the same length.
> {*}SQL{*}:
> {code:java}
> select * from (values ('a'),('abcd')){code}
> {*}Expected values to be returned{*}:
> {{'a'}}
> {{'abcd'}}
>
> {*}Actual values returned{*}:
> {{'a '}}
> {{'abcd'}}
> It seems that for some reason the driver thinks the columns for the
> values-clause should be treated as fixed length CHAR(4) instead of VARCHAR.
> This is also verified by calling ResultSet.getMetaData().getColumnType(1) for
> the ResultSet returned when executing the SQL statement. Indeed it returns 1
> (java.sql.Types.CHAR)
> In my optinion this is a high priority bug because:
> # It affects all Calcite adapters. In my example above no remote call is
> ever done.
> # The values in the values-clause is distorted by the driver. It is not just
> faulty metadata returned by the call to ResultSet.getMetaData() but the
> actual returned data itself that are corrupted.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (CALCITE-4903) Avatica pads values returned from values-clause to same length
[
https://issues.apache.org/jira/browse/CALCITE-4903?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Magnus Mogren updated CALCITE-4903:
---
Description:
When executing a values clause, the avatica driver returns the wrong values.
It seems it checks what value is longest and then pads all other values in the
values clause to the same length.
{*}SQL{*}:
{code:java}
select * from (values ('a'),('abcd')){code}
{*}Expected values to be returned{*}:
{{'a'}}
{{'abcd'}}
{*}Actual values returned{*}:
{{'a '}}
{{'abcd'}}
It seems that for some reason the driver thinks the columns for the
values-clause should be treated as fixed length CHAR(4) instead of VARCHAR.
This is also verified by calling ResultSet.getMetaData().getColumnType(1) for
the ResultSet returned when executing the SQL statement. Indeed it returns 1
(java.sql.Types.CHAR)
In my optinion this is a high priority bug because:
# It affects all Calcite adapters. In my example above no remote call is ever
done.
# The values in the values-clause is distorted by the driver. It is not just
faulty metadata returned by the call to ResultSet.getMetaData() but the actual
returned data itself that are corrupted.
was:
When executing a values clause, the avatica driver returns the wrong values.
It seems it checks what value is longest and then pads all other values in the
values clause to the same length.
{*}SQL{*}:
{code:java}
select * from (values ('a'),('abcd')){code}
{*}Expected values to be returned{*}:
{{'a'}}
{{'abcd'}}
{*}Actual values returned{*}:
{{'a '}}
{{'abcd'}}
It seems that for some reason the driver thinks the columns for the
values-clause should be treated as fixed length CHAR(4) instead of VARCHAR.
This is also verified by calling ResultSet.getMetaData().getColumnType(1) for
the ResultSet returned when executing the SQL statement. Indeed it returns 1
(java.sql.Types.CHAR)
In my optinion this is a high priority bug since it affects any and all calcite
adapters. In my example above no remote call is ever done.
> Avatica pads values returned from values-clause to same length
> --
>
> Key: CALCITE-4903
> URL: https://issues.apache.org/jira/browse/CALCITE-4903
> Project: Calcite
> Issue Type: Bug
> Components: avatica, jdbc-driver
>Affects Versions: avatica-1.19.0
>Reporter: Magnus Mogren
>Priority: Major
>
> When executing a values clause, the avatica driver returns the wrong values.
> It seems it checks what value is longest and then pads all other values in
> the values clause to the same length.
> {*}SQL{*}:
> {code:java}
> select * from (values ('a'),('abcd')){code}
> {*}Expected values to be returned{*}:
> {{'a'}}
> {{'abcd'}}
>
> {*}Actual values returned{*}:
> {{'a '}}
> {{'abcd'}}
> It seems that for some reason the driver thinks the columns for the
> values-clause should be treated as fixed length CHAR(4) instead of VARCHAR.
> This is also verified by calling ResultSet.getMetaData().getColumnType(1) for
> the ResultSet returned when executing the SQL statement. Indeed it returns 1
> (java.sql.Types.CHAR)
> In my optinion this is a high priority bug because:
> # It affects all Calcite adapters. In my example above no remote call is
> ever done.
> # The values in the values-clause is distorted by the driver. It is not just
> faulty metadata returned by the call to ResultSet.getMetaData() but the
> actual returned data itself that are corrupted.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (CALCITE-4903) Avatica pads values returned from values-clause to same length
[
https://issues.apache.org/jira/browse/CALCITE-4903?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Magnus Mogren updated CALCITE-4903:
---
Component/s: jdbc-driver
> Avatica pads values returned from values-clause to same length
> --
>
> Key: CALCITE-4903
> URL: https://issues.apache.org/jira/browse/CALCITE-4903
> Project: Calcite
> Issue Type: Bug
> Components: avatica, jdbc-driver
>Affects Versions: avatica-1.19.0
>Reporter: Magnus Mogren
>Priority: Major
>
> When executing a values clause, the avatica driver returns the wrong values.
> It seems it checks what value is longest and then pads all other values in
> the values clause to the same length.
> {*}SQL{*}:
> {code:java}
> select * from (values ('a'),('abcd')){code}
> {*}Expected values to be returned{*}:
> {{'a'}}
> {{'abcd'}}
>
> {*}Actual values returned{*}:
> {{'a '}}
> {{'abcd'}}
> It seems that for some reason the driver thinks the columns for the
> values-clause should be treated as fixed length CHAR(4) instead of VARCHAR.
> This is also verified by calling ResultSet.getMetaData().getColumnType(1) for
> the ResultSet returned when executing the SQL statement. Indeed it returns 1
> (java.sql.Types.CHAR)
> In my optinion this is a high priority bug since it affects any and all
> calcite adapters. In my example above no remote call is ever done.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (CALCITE-4903) Avatica pads values returned from values-clause to same length
Magnus Mogren created CALCITE-4903:
--
Summary: Avatica pads values returned from values-clause to same
length
Key: CALCITE-4903
URL: https://issues.apache.org/jira/browse/CALCITE-4903
Project: Calcite
Issue Type: Bug
Components: avatica
Affects Versions: avatica-1.19.0
Reporter: Magnus Mogren
When executing a values clause, the avatica driver returns the wrong values.
It seems it checks what value is longest and then pads all other values in the
values clause to the same length.
{*}SQL{*}:
{code:java}
select * from (values ('a'),('abcd')){code}
{*}Expected values to be returned{*}:
{{'a'}}
{{'abcd'}}
{*}Actual values returned{*}:
{{'a '}}
{{'abcd'}}
It seems that for some reason the driver thinks the columns for the
values-clause should be treated as fixed length CHAR(4) instead of VARCHAR.
This is also verified by calling ResultSet.getMetaData().getColumnType(1) for
the ResultSet returned when executing the SQL statement. Indeed it returns 1
(java.sql.Types.CHAR)
In my optinion this is a high priority bug since it affects any and all calcite
adapters. In my example above no remote call is ever done.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (CALCITE-3989) Release Calcite 1.23.0
[ https://issues.apache.org/jira/browse/CALCITE-3989?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17116959#comment-17116959 ] Magnus Mogren commented on CALCITE-3989: [~hyuan] i cannot find the 1.23.0 release in Maven Central > Release Calcite 1.23.0 > -- > > Key: CALCITE-3989 > URL: https://issues.apache.org/jira/browse/CALCITE-3989 > Project: Calcite > Issue Type: Task >Reporter: Haisheng Yuan >Assignee: Haisheng Yuan >Priority: Major > Fix For: 1.23.0 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
