[jira] [Commented] (CALCITE-5744) Add MAP_FROM_ARRAYS, STR_TO_MAP for Spark dialect
[
https://issues.apache.org/jira/browse/CALCITE-5744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17729545#comment-17729545
]
jackylau commented on CALCITE-5744:
---
change the description [~tanclary] ,thanks for your review
> Add MAP_FROM_ARRAYS, STR_TO_MAP for Spark dialect
> -
>
> Key: CALCITE-5744
> URL: https://issues.apache.org/jira/browse/CALCITE-5744
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.35.0
>Reporter: jackylau
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.35.0
>
>
> MAP_FROM_ARRAYS (array1, array2)
> * Returns a map created from an *array1* and *array2. Note that the lengths
> of two arrays should be the same
> {code:java}
> // code placeholder
> > SELECT map_from_arrays(array(1.0, 3.0), array('2', '4'));
> {1.0:"2",3.0:"4"} {code}
>
>
> STR_TO_MAP(string[, stringDelimiter[, keyValueDelimiter]])
> - Returns a map after splitting the *string* into key/value pairs using
> delimiters. Default delimiters are ',' for *stringDelimiter* and ':' for
> *keyValueDelimiter* Both {{pairDelim}} and {{keyValueDelim}} are treated as
> regular expressions.
> *Examples:*
> {code:java}
> > SELECT str_to_map('a:1,b:2,c:3', ',', ':');
> - {"a":"1","b":"2","c":"3"}
> > SELECT str_to_map('a');
> {"a":null} {code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (CALCITE-5739) Add MAP_FROM_ARRAYS for Spark dialect
[
https://issues.apache.org/jira/browse/CALCITE-5739?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
jackylau closed CALCITE-5739.
-
Resolution: Duplicate
> Add MAP_FROM_ARRAYS for Spark dialect
> -
>
> Key: CALCITE-5739
> URL: https://issues.apache.org/jira/browse/CALCITE-5739
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.35.0
>Reporter: jackylau
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.35.0
>
>
> MAP_FROM_ARRAYS (array1, array2)
> * Returns a map created from an *array1* and *array2. Note that the lengths
> of two arrays should be the same
> {code:java}
> // code placeholder
> > SELECT map_from_arrays(array(1.0, 3.0), array('2', '4'));
> {1.0:"2",3.0:"4"} {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-5739) Add MAP_FROM_ARRAYS for Spark dialect
[
https://issues.apache.org/jira/browse/CALCITE-5739?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17729544#comment-17729544
]
jackylau commented on CALCITE-5739:
---
add it to https://issues.apache.org/jira/browse/CALCITE-5744
> Add MAP_FROM_ARRAYS for Spark dialect
> -
>
> Key: CALCITE-5739
> URL: https://issues.apache.org/jira/browse/CALCITE-5739
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.35.0
>Reporter: jackylau
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.35.0
>
>
> MAP_FROM_ARRAYS (array1, array2)
> * Returns a map created from an *array1* and *array2. Note that the lengths
> of two arrays should be the same
> {code:java}
> // code placeholder
> > SELECT map_from_arrays(array(1.0, 3.0), array('2', '4'));
> {1.0:"2",3.0:"4"} {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-5744) Add MAP_FROM_ARRAYS, STR_TO_MAP for Spark dialect
[
https://issues.apache.org/jira/browse/CALCITE-5744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
jackylau updated CALCITE-5744:
--
Description:
MAP_FROM_ARRAYS (array1, array2)
* Returns a map created from an *array1* and *array2. Note that the lengths of
two arrays should be the same
{code:java}
// code placeholder
> SELECT map_from_arrays(array(1.0, 3.0), array('2', '4'));
{1.0:"2",3.0:"4"} {code}
STR_TO_MAP(string[, stringDelimiter[, keyValueDelimiter]])
- Returns a map after splitting the *string* into key/value pairs using
delimiters. Default delimiters are ',' for *stringDelimiter* and ':' for
*keyValueDelimiter* Both {{pairDelim}} and {{keyValueDelim}} are treated as
regular expressions.
*Examples:*
{code:java}
> SELECT str_to_map('a:1,b:2,c:3', ',', ':');
- {"a":"1","b":"2","c":"3"}
> SELECT str_to_map('a');
{"a":null} {code}
was:
STR_TO_MAP(string[, stringDelimiter[, keyValueDelimiter]])
- Returns a map after splitting the *string* into key/value pairs using
delimiters. Default delimiters are ',' for *stringDelimiter* and ':' for
*keyValueDelimiter* Both {{pairDelim}} and {{keyValueDelim}} are treated as
regular expressions.
*Examples:*
{{}}
{code:java}
> SELECT str_to_map('a:1,b:2,c:3', ',', ':');
- {"a":"1","b":"2","c":"3"}
> SELECT str_to_map('a');
{"a":null} {code}
{{{}{}}}{{{}{}}}
> Add MAP_FROM_ARRAYS, STR_TO_MAP for Spark dialect
> -
>
> Key: CALCITE-5744
> URL: https://issues.apache.org/jira/browse/CALCITE-5744
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.35.0
>Reporter: jackylau
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.35.0
>
>
> MAP_FROM_ARRAYS (array1, array2)
> * Returns a map created from an *array1* and *array2. Note that the lengths
> of two arrays should be the same
> {code:java}
> // code placeholder
> > SELECT map_from_arrays(array(1.0, 3.0), array('2', '4'));
> {1.0:"2",3.0:"4"} {code}
>
>
> STR_TO_MAP(string[, stringDelimiter[, keyValueDelimiter]])
> - Returns a map after splitting the *string* into key/value pairs using
> delimiters. Default delimiters are ',' for *stringDelimiter* and ':' for
> *keyValueDelimiter* Both {{pairDelim}} and {{keyValueDelim}} are treated as
> regular expressions.
> *Examples:*
> {code:java}
> > SELECT str_to_map('a:1,b:2,c:3', ',', ':');
> - {"a":"1","b":"2","c":"3"}
> > SELECT str_to_map('a');
> {"a":null} {code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-5744) Add MAP_FROM_ARRAYS, STR_TO_MAP for Spark dialect
[
https://issues.apache.org/jira/browse/CALCITE-5744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
jackylau updated CALCITE-5744:
--
Summary: Add MAP_FROM_ARRAYS, STR_TO_MAP for Spark dialect (was: Add
STR_TO_MAP for Spark dialect)
> Add MAP_FROM_ARRAYS, STR_TO_MAP for Spark dialect
> -
>
> Key: CALCITE-5744
> URL: https://issues.apache.org/jira/browse/CALCITE-5744
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.35.0
>Reporter: jackylau
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.35.0
>
>
> STR_TO_MAP(string[, stringDelimiter[, keyValueDelimiter]])
> - Returns a map after splitting the *string* into key/value pairs using
> delimiters. Default delimiters are ',' for *stringDelimiter* and ':' for
> *keyValueDelimiter* Both {{pairDelim}} and {{keyValueDelim}} are treated as
> regular expressions.
> *Examples:*
> {{}}
> {code:java}
> > SELECT str_to_map('a:1,b:2,c:3', ',', ':');
> - {"a":"1","b":"2","c":"3"}
> > SELECT str_to_map('a');
> {"a":null} {code}
> {{{}{}}}{{{}{}}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-5742) SubstitutionVisitor Causes Infinite Loop when using AggregateOnCalcToAggregateUnifyRule
[
https://issues.apache.org/jira/browse/CALCITE-5742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17729542#comment-17729542
]
junheleo commented on CALCITE-5742:
---
Hi,[~julianhyde] ,would you like to help me review this problem and PR pls?
> SubstitutionVisitor Causes Infinite Loop when using
> AggregateOnCalcToAggregateUnifyRule
> ---
>
> Key: CALCITE-5742
> URL: https://issues.apache.org/jira/browse/CALCITE-5742
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.34.0
>Reporter: junheleo
>Priority: Major
> Labels: pull-request-available
>
> Here is a simple code snippet to reproduce the issue:
> {code:java}
> // Test case in MaterializedViewSubstitutionVisitorTest
> @Test void testAggregateOnProject6() {
> sql("select count(1) from (select \"empid\", \"deptno\", \"name\", count(*)
> from \"emps\""
> + "group by \"empid\", \"deptno\", \"name\" limit 10) ",
> "select \"empid\", \"deptno\" from (select \"empid\", \"deptno\",
> \"name\", count(*) from \"emps\"\n"
> + "group by \"empid\", \"deptno\", \"name\" limit 10) group by
> \"empid\", \"deptno\"")
> .noMat();
> }{code}
> Canonicalized Query Plan:
> {code:java}
> -- Query Plan
> LogicalAggregate(group=[{0, 1}])
> LogicalCalc(expr#0..3=[{inputs}], proj#0..1=[{exprs}])
> LogicalSort(fetch=[10])
> LogicalAggregate(group=[{0, 1, 2}], EXPR$3=[COUNT()])
> LogicalCalc(expr#0..4=[{inputs}], proj#0..2=[{exprs}])
> LogicalTableScan(table=[[hr, emps]]){code}
> Canonicalized Target Plan:
> {code:java}
> -- Target Plan
> LogicalAggregate(group=[{}], EXPR$0=[COUNT()])
> LogicalSort(fetch=[10])
> LogicalAggregate(group=[{0, 1, 2}], EXPR$3=[COUNT()])
> LogicalCalc(expr#0..4=[{inputs}], proj#0..2=[{exprs}])
> LogicalTableScan(table=[[hr, emps]]){code}
> The input of Calc Under Aggregate was changed when executing permute in
> AggregateOnCalcToAggregateUnifyRule, then Visitor can not skip out because
> the condition "queryDescendant == r.after" is not met.
> Thank you for your attention to this matter
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (CALCITE-5752) Error during session reset in avatica go driver
[
https://issues.apache.org/jira/browse/CALCITE-5752?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Francis Chuang resolved CALCITE-5752.
-
Fix Version/s: avatica-go-5.3.0
Resolution: Fixed
> Error during session reset in avatica go driver
> ---
>
> Key: CALCITE-5752
> URL: https://issues.apache.org/jira/browse/CALCITE-5752
> Project: Calcite
> Issue Type: Bug
> Components: avatica-go
>Affects Versions: 1.34.0
>Reporter: Parag Jain
>Assignee: Francis Chuang
>Priority: Major
> Fix For: avatica-go-5.3.0
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> In Go sql package when an idle connection is picked from the pool,
> *ResetSession* method is called on the connection. In the drivers
> implementation of this method
> [here|https://github.com/apache/calcite-avatica-go/blob/main/connection.go#L236],
> *registerConn* method is called which actually does an
> *OpenConnectionRequest* with the existing connectionId. On the Druid side it
> actually throws an exception
> [here|https://github.com/apache/druid/blob/master/sql/src/main/java/org/apache/druid/sql/avatica/DruidMeta.java#L823]
> saying the connection is already open. I checked other driver
> implementations like
> [postgres|https://github.com/jackc/pgx/blob/master/stdlib/sql.go#L307] and
> [mysql|https://github.com/go-sql-driver/mysql/blob/master/connection.go#L638]
> for ResetSession method and they actually don't open a new connection. So not
> sure about the reason for doing this here. Any thoughts on this ? Example
> exception stack trace -
> {code:java}
> 2023-05-22T19:24:47,357 ERROR [qtp44562-140]
> org.apache.druid.sql.avatica.DruidMeta - Connection
> [fcf73260-cb72-b867-154b-e39a19569c5e] already open.
> org.apache.druid.java.util.common.ISE: Connection
> [fcf73260-cb72-b867-154b-e39a19569c5e] already open.
> at
> org.apache.druid.sql.avatica.DruidMeta.openDruidConnection(DruidMeta.java:823)
> ~[classes/:?]
> at
> org.apache.druid.sql.avatica.DruidMeta.openConnection(DruidMeta.java:208)
> ~[classes/:?]
> at
> org.apache.calcite.avatica.remote.LocalService.apply(LocalService.java:285)
> ~[avatica-core-1.17.0.jar:1.17.0]
> at
> org.apache.calcite.avatica.remote.Service$OpenConnectionRequest.accept(Service.java:1770)
> ~[avatica-core-1.17.0.jar:1.17.0]
> at
> org.apache.calcite.avatica.remote.Service$OpenConnectionRequest.accept(Service.java:1750)
> ~[avatica-core-1.17.0.jar:1.17.0]
> at
> org.apache.calcite.avatica.remote.AbstractHandler.apply(AbstractHandler.java:94)
> ~[avatica-core-1.17.0.jar:1.17.0]
> at
> org.apache.calcite.avatica.remote.ProtobufHandler.apply(ProtobufHandler.java:46)
> ~[avatica-core-1.17.0.jar:1.17.0]
> at
> org.apache.calcite.avatica.server.AvaticaProtobufHandler.handle(AvaticaProtobufHandler.java:126)
> ~[avatica-server-1.17.0.jar:1.17.0]
> at
> org.apache.druid.sql.avatica.DruidAvaticaProtobufHandler.handle(DruidAvaticaProtobufHandler.java:61)
> ~[classes/:?] {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (CALCITE-5754) Open statement leak in avatica go driver
[ https://issues.apache.org/jira/browse/CALCITE-5754?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Francis Chuang resolved CALCITE-5754. - Fix Version/s: avatica-go-5.3.0 Resolution: Fixed > Open statement leak in avatica go driver > > > Key: CALCITE-5754 > URL: https://issues.apache.org/jira/browse/CALCITE-5754 > Project: Calcite > Issue Type: Bug > Components: avatica-go >Affects Versions: 1.34.0 >Reporter: Parag Jain >Assignee: Francis Chuang >Priority: Major > Fix For: avatica-go-5.3.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > My colleague (Benjamin) found open statement leak in the code where > statement close request is not sent to the database after query is executed > in exec and query methods in connection.go -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CALCITE-5753) User and pwd not being propagated to JDBC context from go driver
[
https://issues.apache.org/jira/browse/CALCITE-5753?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Francis Chuang resolved CALCITE-5753.
-
Fix Version/s: avatica-go-5.3.0
Resolution: Fixed
> User and pwd not being propagated to JDBC context from go driver
>
>
> Key: CALCITE-5753
> URL: https://issues.apache.org/jira/browse/CALCITE-5753
> Project: Calcite
> Issue Type: Bug
> Components: avatica-go
>Affects Versions: 1.34.0
>Reporter: Parag Jain
>Assignee: Francis Chuang
>Priority: Major
> Fix For: avatica-go-5.3.0
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Username and pwd not being propagated in the JDBC context. Had to add the
> following code in the
> [Connect|https://github.com/apache/calcite-avatica-go/blob/main/driver.go#L64]
> method of driver.go to make it work
> {code:java}
> if config.avaticaUser != "" {
> c.Info["user"] = config.avaticaUser
> }
> if config.avaticaPassword != "" {
> c.Info["password"] = config.avaticaPassword
> } {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (CALCITE-5755) Add to Sarg serialization/deserialization TimestampString
[ https://issues.apache.org/jira/browse/CALCITE-5755?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oliver Lee reassigned CALCITE-5755: --- Assignee: Oliver Lee > Add to Sarg serialization/deserialization TimestampString > - > > Key: CALCITE-5755 > URL: https://issues.apache.org/jira/browse/CALCITE-5755 > Project: Calcite > Issue Type: Sub-task >Reporter: Oliver Lee >Assignee: Oliver Lee >Priority: Minor > > Currently Sarg serialization/deserialization allows for 6 types > [https://github.com/apache/calcite/blob/967bb5acc5448bc8d6ee9b9f5fa3c5f0d71405c2/core/src/main/java/org/apache/calcite/rel/externalize/RelJson.java#L113] > and doesn't include `TimestampString` > > Currently, it will not throw an error, but will deserialize incorrectly as a > `Date` set to the epoch beginning. > Desired outcome: Be able to serialize / deserialize SEARCH operators that > contain Timestamp string literals. > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-5755) Add to Sarg serialization/deserialization TimestampString
[
https://issues.apache.org/jira/browse/CALCITE-5755?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oliver Lee updated CALCITE-5755:
Description:
Currently Sarg serialization/deserialization allows for 6 types
[https://github.com/apache/calcite/blob/967bb5acc5448bc8d6ee9b9f5fa3c5f0d71405c2/core/src/main/java/org/apache/calcite/rel/externalize/RelJson.java#L113]
and doesn't include {{TimestampString}}
Currently when a timestamp string comes in, it will not throw an error, but
will deserialize incorrectly as a {{Date}} set to the epoch beginning.
Desired outcome: Be able to serialize / deserialize SEARCH operators that
contain Timestamp string literals.
was:
Currently Sarg serialization/deserialization allows for 6 types
[https://github.com/apache/calcite/blob/967bb5acc5448bc8d6ee9b9f5fa3c5f0d71405c2/core/src/main/java/org/apache/calcite/rel/externalize/RelJson.java#L113]
and doesn't include \{{TimestampString}}
Currently, it will not throw an error, but will deserialize incorrectly as a
\{{Date}} set to the epoch beginning.
Desired outcome: Be able to serialize / deserialize SEARCH operators that
contain Timestamp string literals.
> Add to Sarg serialization/deserialization TimestampString
> -
>
> Key: CALCITE-5755
> URL: https://issues.apache.org/jira/browse/CALCITE-5755
> Project: Calcite
> Issue Type: Sub-task
>Reporter: Oliver Lee
>Assignee: Oliver Lee
>Priority: Minor
>
> Currently Sarg serialization/deserialization allows for 6 types
> [https://github.com/apache/calcite/blob/967bb5acc5448bc8d6ee9b9f5fa3c5f0d71405c2/core/src/main/java/org/apache/calcite/rel/externalize/RelJson.java#L113]
> and doesn't include {{TimestampString}}
>
> Currently when a timestamp string comes in, it will not throw an error, but
> will deserialize incorrectly as a {{Date}} set to the epoch beginning.
> Desired outcome: Be able to serialize / deserialize SEARCH operators that
> contain Timestamp string literals.
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CALCITE-5755) Add to Sarg serialization/deserialization TimestampString
Oliver Lee created CALCITE-5755: --- Summary: Add to Sarg serialization/deserialization TimestampString Key: CALCITE-5755 URL: https://issues.apache.org/jira/browse/CALCITE-5755 Project: Calcite Issue Type: Sub-task Reporter: Oliver Lee Currently Sarg serialization/deserialization allows for 6 types [https://github.com/apache/calcite/blob/967bb5acc5448bc8d6ee9b9f5fa3c5f0d71405c2/core/src/main/java/org/apache/calcite/rel/externalize/RelJson.java#L113] and doesn't include `TimestampString` Currently, it will not throw an error, but will deserialize incorrectly as a `Date` set to the epoch beginning. Desired outcome: Be able to serialize / deserialize SEARCH operators that contain Timestamp string literals. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-5755) Add to Sarg serialization/deserialization TimestampString
[
https://issues.apache.org/jira/browse/CALCITE-5755?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oliver Lee updated CALCITE-5755:
Description:
Currently Sarg serialization/deserialization allows for 6 types
[https://github.com/apache/calcite/blob/967bb5acc5448bc8d6ee9b9f5fa3c5f0d71405c2/core/src/main/java/org/apache/calcite/rel/externalize/RelJson.java#L113]
and doesn't include \{{TimestampString}}
Currently, it will not throw an error, but will deserialize incorrectly as a
\{{Date}} set to the epoch beginning.
Desired outcome: Be able to serialize / deserialize SEARCH operators that
contain Timestamp string literals.
was:
Currently Sarg serialization/deserialization allows for 6 types
[https://github.com/apache/calcite/blob/967bb5acc5448bc8d6ee9b9f5fa3c5f0d71405c2/core/src/main/java/org/apache/calcite/rel/externalize/RelJson.java#L113]
and doesn't include `TimestampString`
Currently, it will not throw an error, but will deserialize incorrectly as a
`Date` set to the epoch beginning.
Desired outcome: Be able to serialize / deserialize SEARCH operators that
contain Timestamp string literals.
> Add to Sarg serialization/deserialization TimestampString
> -
>
> Key: CALCITE-5755
> URL: https://issues.apache.org/jira/browse/CALCITE-5755
> Project: Calcite
> Issue Type: Sub-task
>Reporter: Oliver Lee
>Assignee: Oliver Lee
>Priority: Minor
>
> Currently Sarg serialization/deserialization allows for 6 types
> [https://github.com/apache/calcite/blob/967bb5acc5448bc8d6ee9b9f5fa3c5f0d71405c2/core/src/main/java/org/apache/calcite/rel/externalize/RelJson.java#L113]
> and doesn't include \{{TimestampString}}
>
> Currently, it will not throw an error, but will deserialize incorrectly as a
> \{{Date}} set to the epoch beginning.
> Desired outcome: Be able to serialize / deserialize SEARCH operators that
> contain Timestamp string literals.
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (CALCITE-5738) Add SORT_ARRAY for Spark dialect
[
https://issues.apache.org/jira/browse/CALCITE-5738?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tanner Clary closed CALCITE-5738.
-
Resolution: Fixed
Merged via
[2cb7663](https://github.com/apache/calcite/commit/2cb766380a27a1f4fd3b33540c2742bfc2eaeb59).
Thanks for the PR, [~jackylau]!
> Add SORT_ARRAY for Spark dialect
>
>
> Key: CALCITE-5738
> URL: https://issues.apache.org/jira/browse/CALCITE-5738
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.35.0
>Reporter: jackylau
>Assignee: jackylau
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.35.0
>
>
> h3.
> [sort_array|https://spark.apache.org/docs/latest/api/sql/index.html#sort_array]
> sort_array(array[, ascendingOrder]) - Sorts the input array in ascending or
> descending order according to the natural ordering of the array elements.
> Null elements will be placed at the beginning of the returned array in
> ascending order or at the end of the returned array in descending order.
> *Examples:*
> {{> SELECT sort_array(array('b', 'd', null, 'c', 'a'), true);}}
> {{ [null,"a","b","c","d"]}}
>
> {{> SELECT sort_array(array('b', 'd', null, 'c', 'a'));}}
> {{ [null,"a","b","c","d"]}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-5747) Conflicting FLOOR return type between Calcite and BigQuery
[
https://issues.apache.org/jira/browse/CALCITE-5747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-5747:
Labels: pull-request-available (was: )
> Conflicting FLOOR return type between Calcite and BigQuery
> --
>
> Key: CALCITE-5747
> URL: https://issues.apache.org/jira/browse/CALCITE-5747
> Project: Calcite
> Issue Type: Bug
>Reporter: Tanner Clary
>Assignee: Tanner Clary
>Priority: Major
> Labels: pull-request-available
>
> In Calcite, the {{FLOOR}} function return type is set to
> {{ARG0_OR_EXACT_NO_SCALE}}. This means that if the result is not a decimal
> with scale 0, it falls back to whatever the type of {{ARG0}} is
> ([source|https://github.com/apache/calcite/blob/main/core/src/main/java/org/apache/calcite/sql/type/ReturnTypes.java#L628-L633]).
>
> For instance, if the {{FLOOR}} function is called with an argument of type
> {{BIGINT}}, the return type will be {{BIGINT}} because it is not a decimal
> with scale 0, so it falls back to {{ARG0}}.
> The issue lies in the fact that BigQuery has different behavior for inferring
> the return type. This inference is done according to [these
> docs|https://cloud.google.com/bigquery/docs/reference/standard-sql/mathematical_functions#floor].
>
> This conflicts with Calcite if the argument provided to the {{FLOOR}}
> function is an {{BIGINT}} , {{BigQuery}} returns an {{DOUBLE}} (FLOAT64 in BQ
> terms) while Calcite would return a {{BIGINT}}.
> A consequence of this problem may be seen in the following query:
> {{SELECT TIMESTAMP_SECONDS(CAST(FLOOR(CAST(3 AS BIGINT)) AS BIGINT)}}
> Calcite simplifies the query to {{SELECT TIMESTAMP_SECONDS(FLOOR(3)}} because
> the return type is already a {{BIGINT}} so the cast is deemed unnecessary.
> (The cast within the floor function is just to ensure the operand is of type
> {{BIGINT}} for illustrative purposes).
> When BigQuery receives this query, it throws an error because the return type
> of FLOOR(3) is a {{DOUBLE}} (FLOAT64 in BigQuery terms) and the
> {{TIMESTAMP_SECONDS}} function is expecting an integer.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (CALCITE-5529) Improve dialect tests
[
https://issues.apache.org/jira/browse/CALCITE-5529?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde reassigned CALCITE-5529:
Assignee: Julian Hyde
> Improve dialect tests
> -
>
> Key: CALCITE-5529
> URL: https://issues.apache.org/jira/browse/CALCITE-5529
> Project: Calcite
> Issue Type: Bug
>Reporter: Julian Hyde
>Assignee: Julian Hyde
>Priority: Major
>
> The current dialect tests are quick and robust but not very thorough. In
> {{RelToSqlConverterTest}} there are about 400 tests (374 SQL statements and
> 30 relational expressions) that test translation to 538 SQL strings in target
> dialects (an average of 1.34 dialects per test). To run the 371 test methods
> takes about 12 seconds elapsed, 80 CPU seconds on my MacBook Pro. None of
> those SQL strings are executed, so we don't know whether they return the
> correct results or are even valid.
> Improvements:
> * Define a list of dialects that we wish to test (the "target dialects") and
> provide a means to connect to a database for each of these (typically a
> driver on the class path, a URL, user name and password);
> * In each test, for each target dialect, generate a SQL string. The
> generation should not throw.
> * In each test, the query is first executed against Calcite to create a
> sample. (For any test, this can be overridden to use a different reference
> dialect. Calcite will use a recording, if present.)
> * In each test, for each target dialect that has an *enabled* connection,
> execute the generated SQL against that connection. If there is a reference
> result for the test, check that the result equals the reference result.
> * In each test, for each target dialect that has a *recording* connection,
> execute the generated SQL against that connection. Record the outcome (error,
> column names and types, result) in the file. Proceed as for an enabled
> connection. (Check result against reference result, etc.)
> * In each test, for each target dialect that has a *replaying* connection,
> look up the outcome of the generated SQL. If the outcome is present, proceed
> as for an enabled connection. (Check result against reference result, etc.)
> * In each test, for each target dialect that has a *replaying+recording*
> connection, look up the outcome of the generated SQL. If the outcome is
> present, proceed as for an enabled connection. (Check result against
> reference result, etc.) If the outcome is not present, proceed as for a
> recording connection. (Execute the SQL, record the outcome, check against
> reference result, etc.)
> With these improvements, the test suite:
> * Remains fast and robust (because recordings are used most of the time);
> * Can be run offline (using recordings);
> * Can be run by contributors who do not necessarily have access to all of
> the supported databases;
> * Has full coverage (runs all tests against all supported dialects);
> * Can re-generate the 'golden' references. (Must be online, have the
> required driver and connection, and takes more time.)
> Design:
> * A new {{class DialectTestConfig}} describes the dialects to be tested,
> their names, connections, the connection state (enabled, recording,
> replaying, replaying+recording), and recording file name.
> * A mock JDBC driver mediates recording/replay.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-5568) Decorrelate will fail. If the RelNode tree has LogicalValues
[
https://issues.apache.org/jira/browse/CALCITE-5568?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17729350#comment-17729350
]
libopeng commented on CALCITE-5568:
---
I don't know how to ignore this test case, so I removed it for now. If I fix
CALCITE-5743, I will add it
back.[PR|https://github.com/apache/calcite/pull/3244]
> Decorrelate will fail. If the RelNode tree has LogicalValues
>
>
> Key: CALCITE-5568
> URL: https://issues.apache.org/jira/browse/CALCITE-5568
> Project: Calcite
> Issue Type: Bug
>Reporter: libopeng
>Assignee: libopeng
>Priority: Major
> Labels: pull-request-available
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Decorrelate will fail. If the RelNode tree has LogicalValues
> case:
> {code:java}
> SELECT *
> FROM emp AS e
> CROSS JOIN (VALUES 1) AS t (x)
> WHERE EXISTS (SELECT * FROM dept WHERE deptno = e.deptno){code}
> after decorrelate
> (org.apache.calcite.sql2rel.RelDecorrelator#decorrelateQuery(org.apache.calcite.rel.RelNode,
> org.apache.calcite.tools.RelBuilder))
> {code:java}
> LogicalProject(EMPNO=[$0], ENAME=[$1], JOB=[$2], MGR=[$3], HIREDATE=[$4],
> SAL=[$5], COMM=[$6], DEPTNO=[$7], SLACKER=[$8], X=[$9])
> LogicalProject(EMPNO=[$0], ENAME=[$1], JOB=[$2], MGR=[$3], HIREDATE=[$4],
> SAL=[$5], COMM=[$6], DEPTNO=[$7], SLACKER=[$8], X=[$9], $f0=[$10])
> LogicalFilter(condition=[IS NOT NULL($10)])
> LogicalCorrelate(correlation=[$cor0], joinType=[left],
> requiredColumns=[{7}])
> LogicalJoin(condition=[true], joinType=[inner])
> LogicalTableScan(table=[[CATALOG, SALES, EMP]])
> LogicalValues(tuples=[[{ 1 }]])
> LogicalAggregate(group=[{}], agg#0=[MIN($0)])
> LogicalProject($f0=[true])
> LogicalFilter(condition=[=($0, $cor0.DEPTNO)])
> LogicalTableScan(table=[[CATALOG, SALES, DEPT]])
> {code}
> LogicalCorrelate will not be processed when the RelNode tree has
> LogicalValues
> [https://github.com/apache/calcite/blob/main/core/src/main/java/org/apache/calcite/sql2rel/RelDecorrelator.java#L491]
>
> Is this as expected？
>
>
>
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-5719) Issues with connection and authentication with Apache Druid
[
https://issues.apache.org/jira/browse/CALCITE-5719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17729334#comment-17729334
]
Parag Jain commented on CALCITE-5719:
-
Thanks raised issues and respective PRs here -
https://issues.apache.org/jira/browse/CALCITE-5752,
https://issues.apache.org/jira/browse/CALCITE-5753,
https://issues.apache.org/jira/browse/CALCITE-5754
> Issues with connection and authentication with Apache Druid
> ---
>
> Key: CALCITE-5719
> URL: https://issues.apache.org/jira/browse/CALCITE-5719
> Project: Calcite
> Issue Type: Bug
> Components: avatica-go
>Reporter: Parag Jain
>Assignee: Francis Chuang
>Priority: Major
> Labels: avatica
>
> We are using calcite-avatica-go driver to connect to Apache Druid and facing
> few issues -
> # In Go sql package when an idle connection is picked from the pool,
> *ResetSession* method is called on the connection. In the drivers
> implementation of this method
> [here|https://github.com/apache/calcite-avatica-go/blob/main/connection.go#L236],
> *registerConn* method is called which actually does an
> *OpenConnectionRequest* with the existing connectionId. On the Druid side it
> actually throws an exception
> [here|https://github.com/apache/druid/blob/master/sql/src/main/java/org/apache/druid/sql/avatica/DruidMeta.java#L823]
> saying the connection is already open. I checked other driver
> implementations like
> [postgres|https://github.com/jackc/pgx/blob/master/stdlib/sql.go#L307] and
> [mysql|https://github.com/go-sql-driver/mysql/blob/master/connection.go#L638]
> for ResetSession method and they actually don't open a new connection. So not
> sure about the reason for doing this here. Any thoughts on this ? Example
> exception stack trace -
> {code:java}
> 2023-05-22T19:24:47,357 ERROR [qtp44562-140]
> org.apache.druid.sql.avatica.DruidMeta - Connection
> [fcf73260-cb72-b867-154b-e39a19569c5e] already open.
> org.apache.druid.java.util.common.ISE: Connection
> [fcf73260-cb72-b867-154b-e39a19569c5e] already open.
> at
> org.apache.druid.sql.avatica.DruidMeta.openDruidConnection(DruidMeta.java:823)
> ~[classes/:?]
> at
> org.apache.druid.sql.avatica.DruidMeta.openConnection(DruidMeta.java:208)
> ~[classes/:?]
> at
> org.apache.calcite.avatica.remote.LocalService.apply(LocalService.java:285)
> ~[avatica-core-1.17.0.jar:1.17.0]
> at
> org.apache.calcite.avatica.remote.Service$OpenConnectionRequest.accept(Service.java:1770)
> ~[avatica-core-1.17.0.jar:1.17.0]
> at
> org.apache.calcite.avatica.remote.Service$OpenConnectionRequest.accept(Service.java:1750)
> ~[avatica-core-1.17.0.jar:1.17.0]
> at
> org.apache.calcite.avatica.remote.AbstractHandler.apply(AbstractHandler.java:94)
> ~[avatica-core-1.17.0.jar:1.17.0]
> at
> org.apache.calcite.avatica.remote.ProtobufHandler.apply(ProtobufHandler.java:46)
> ~[avatica-core-1.17.0.jar:1.17.0]
> at
> org.apache.calcite.avatica.server.AvaticaProtobufHandler.handle(AvaticaProtobufHandler.java:126)
> ~[avatica-server-1.17.0.jar:1.17.0]
> at
> org.apache.druid.sql.avatica.DruidAvaticaProtobufHandler.handle(DruidAvaticaProtobufHandler.java:61)
> ~[classes/:?] {code}
> 2. Username and pwd not being propagated in the JDBC context. Had to add
> the following code in the
> [Connect|https://github.com/apache/calcite-avatica-go/blob/main/driver.go#L64]
> method of driver.go to make it work
> {code:java}
> if config.avaticaUser != "" {
> c.Info["user"] = config.avaticaUser
> }
> if config.avaticaPassword != "" {
> c.Info["password"] = config.avaticaPassword
> } {code}
> 3. My colleague (Benjamin) found open statement leak as well, fixed
> [here|https://github.com/apache/calcite-avatica-go/commit/9c0eba2fbe15b3f877ee276b889cbd39e1a8ce2d]
> We plan to contribute all back once the issues are fixed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-5754) Open statement leak in avatica go driver
[ https://issues.apache.org/jira/browse/CALCITE-5754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17729333#comment-17729333 ] Parag Jain commented on CALCITE-5754: - Fixed here - https://github.com/apache/calcite-avatica-go/pull/66 > Open statement leak in avatica go driver > > > Key: CALCITE-5754 > URL: https://issues.apache.org/jira/browse/CALCITE-5754 > Project: Calcite > Issue Type: Bug > Components: avatica-go >Affects Versions: 1.34.0 >Reporter: Parag Jain >Assignee: Francis Chuang >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > My colleague (Benjamin) found open statement leak in the code where > statement close request is not sent to the database after query is executed > in exec and query methods in connection.go -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CALCITE-5754) Open statement leak in avatica go driver
Parag Jain created CALCITE-5754: --- Summary: Open statement leak in avatica go driver Key: CALCITE-5754 URL: https://issues.apache.org/jira/browse/CALCITE-5754 Project: Calcite Issue Type: Bug Components: avatica-go Affects Versions: 1.34.0 Reporter: Parag Jain Assignee: Francis Chuang My colleague (Benjamin) found open statement leak in the code where statement close request is not sent to the database after query is executed in exec and query methods in connection.go -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CALCITE-5753) User and pwd not being propagated to JDBC context from go driver
[
https://issues.apache.org/jira/browse/CALCITE-5753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17729330#comment-17729330
]
Parag Jain commented on CALCITE-5753:
-
PR - https://github.com/apache/calcite-avatica-go/pull/65
> User and pwd not being propagated to JDBC context from go driver
>
>
> Key: CALCITE-5753
> URL: https://issues.apache.org/jira/browse/CALCITE-5753
> Project: Calcite
> Issue Type: Bug
> Components: avatica-go
>Affects Versions: 1.34.0
>Reporter: Parag Jain
>Assignee: Francis Chuang
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Username and pwd not being propagated in the JDBC context. Had to add the
> following code in the
> [Connect|https://github.com/apache/calcite-avatica-go/blob/main/driver.go#L64]
> method of driver.go to make it work
> {code:java}
> if config.avaticaUser != "" {
> c.Info["user"] = config.avaticaUser
> }
> if config.avaticaPassword != "" {
> c.Info["password"] = config.avaticaPassword
> } {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CALCITE-5753) User and pwd not being propagated to JDBC context from go driver
Parag Jain created CALCITE-5753:
---
Summary: User and pwd not being propagated to JDBC context from go
driver
Key: CALCITE-5753
URL: https://issues.apache.org/jira/browse/CALCITE-5753
Project: Calcite
Issue Type: Bug
Components: avatica-go
Affects Versions: 1.34.0
Reporter: Parag Jain
Assignee: Francis Chuang
Username and pwd not being propagated in the JDBC context. Had to add the
following code in the
[Connect|https://github.com/apache/calcite-avatica-go/blob/main/driver.go#L64]
method of driver.go to make it work
{code:java}
if config.avaticaUser != "" {
c.Info["user"] = config.avaticaUser
}
if config.avaticaPassword != "" {
c.Info["password"] = config.avaticaPassword
} {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-5568) Decorrelate will fail. If the RelNode tree has LogicalValues
[
https://issues.apache.org/jira/browse/CALCITE-5568?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17729329#comment-17729329
]
Stamatis Zampetakis commented on CALCITE-5568:
--
The changed in decorrelator triggered/revealed the bug under CALCITE-5743 so I
am not sure if we can simply ignore/defer it. The same side-effect (wrong
results) may appear in other projects if we just fix this issue without fixing
CALCITE-5743. It's not clear to me at this point if we should fix CALCITE-5743
first or not.
> Decorrelate will fail. If the RelNode tree has LogicalValues
>
>
> Key: CALCITE-5568
> URL: https://issues.apache.org/jira/browse/CALCITE-5568
> Project: Calcite
> Issue Type: Bug
>Reporter: libopeng
>Assignee: libopeng
>Priority: Major
> Labels: pull-request-available
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Decorrelate will fail. If the RelNode tree has LogicalValues
> case:
> {code:java}
> SELECT *
> FROM emp AS e
> CROSS JOIN (VALUES 1) AS t (x)
> WHERE EXISTS (SELECT * FROM dept WHERE deptno = e.deptno){code}
> after decorrelate
> (org.apache.calcite.sql2rel.RelDecorrelator#decorrelateQuery(org.apache.calcite.rel.RelNode,
> org.apache.calcite.tools.RelBuilder))
> {code:java}
> LogicalProject(EMPNO=[$0], ENAME=[$1], JOB=[$2], MGR=[$3], HIREDATE=[$4],
> SAL=[$5], COMM=[$6], DEPTNO=[$7], SLACKER=[$8], X=[$9])
> LogicalProject(EMPNO=[$0], ENAME=[$1], JOB=[$2], MGR=[$3], HIREDATE=[$4],
> SAL=[$5], COMM=[$6], DEPTNO=[$7], SLACKER=[$8], X=[$9], $f0=[$10])
> LogicalFilter(condition=[IS NOT NULL($10)])
> LogicalCorrelate(correlation=[$cor0], joinType=[left],
> requiredColumns=[{7}])
> LogicalJoin(condition=[true], joinType=[inner])
> LogicalTableScan(table=[[CATALOG, SALES, EMP]])
> LogicalValues(tuples=[[{ 1 }]])
> LogicalAggregate(group=[{}], agg#0=[MIN($0)])
> LogicalProject($f0=[true])
> LogicalFilter(condition=[=($0, $cor0.DEPTNO)])
> LogicalTableScan(table=[[CATALOG, SALES, DEPT]])
> {code}
> LogicalCorrelate will not be processed when the RelNode tree has
> LogicalValues
> [https://github.com/apache/calcite/blob/main/core/src/main/java/org/apache/calcite/sql2rel/RelDecorrelator.java#L491]
>
> Is this as expected？
>
>
>
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-5752) Error during session reset in avatica go driver
[
https://issues.apache.org/jira/browse/CALCITE-5752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17729328#comment-17729328
]
Parag Jain commented on CALCITE-5752:
-
Fix here - https://github.com/apache/calcite-avatica-go/pull/64
> Error during session reset in avatica go driver
> ---
>
> Key: CALCITE-5752
> URL: https://issues.apache.org/jira/browse/CALCITE-5752
> Project: Calcite
> Issue Type: Bug
> Components: avatica-go
>Affects Versions: 1.34.0
>Reporter: Parag Jain
>Assignee: Francis Chuang
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> In Go sql package when an idle connection is picked from the pool,
> *ResetSession* method is called on the connection. In the drivers
> implementation of this method
> [here|https://github.com/apache/calcite-avatica-go/blob/main/connection.go#L236],
> *registerConn* method is called which actually does an
> *OpenConnectionRequest* with the existing connectionId. On the Druid side it
> actually throws an exception
> [here|https://github.com/apache/druid/blob/master/sql/src/main/java/org/apache/druid/sql/avatica/DruidMeta.java#L823]
> saying the connection is already open. I checked other driver
> implementations like
> [postgres|https://github.com/jackc/pgx/blob/master/stdlib/sql.go#L307] and
> [mysql|https://github.com/go-sql-driver/mysql/blob/master/connection.go#L638]
> for ResetSession method and they actually don't open a new connection. So not
> sure about the reason for doing this here. Any thoughts on this ? Example
> exception stack trace -
> {code:java}
> 2023-05-22T19:24:47,357 ERROR [qtp44562-140]
> org.apache.druid.sql.avatica.DruidMeta - Connection
> [fcf73260-cb72-b867-154b-e39a19569c5e] already open.
> org.apache.druid.java.util.common.ISE: Connection
> [fcf73260-cb72-b867-154b-e39a19569c5e] already open.
> at
> org.apache.druid.sql.avatica.DruidMeta.openDruidConnection(DruidMeta.java:823)
> ~[classes/:?]
> at
> org.apache.druid.sql.avatica.DruidMeta.openConnection(DruidMeta.java:208)
> ~[classes/:?]
> at
> org.apache.calcite.avatica.remote.LocalService.apply(LocalService.java:285)
> ~[avatica-core-1.17.0.jar:1.17.0]
> at
> org.apache.calcite.avatica.remote.Service$OpenConnectionRequest.accept(Service.java:1770)
> ~[avatica-core-1.17.0.jar:1.17.0]
> at
> org.apache.calcite.avatica.remote.Service$OpenConnectionRequest.accept(Service.java:1750)
> ~[avatica-core-1.17.0.jar:1.17.0]
> at
> org.apache.calcite.avatica.remote.AbstractHandler.apply(AbstractHandler.java:94)
> ~[avatica-core-1.17.0.jar:1.17.0]
> at
> org.apache.calcite.avatica.remote.ProtobufHandler.apply(ProtobufHandler.java:46)
> ~[avatica-core-1.17.0.jar:1.17.0]
> at
> org.apache.calcite.avatica.server.AvaticaProtobufHandler.handle(AvaticaProtobufHandler.java:126)
> ~[avatica-server-1.17.0.jar:1.17.0]
> at
> org.apache.druid.sql.avatica.DruidAvaticaProtobufHandler.handle(DruidAvaticaProtobufHandler.java:61)
> ~[classes/:?] {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CALCITE-5752) Error during session reset in avatica go driver
Parag Jain created CALCITE-5752:
---
Summary: Error during session reset in avatica go driver
Key: CALCITE-5752
URL: https://issues.apache.org/jira/browse/CALCITE-5752
Project: Calcite
Issue Type: Bug
Components: avatica-go
Affects Versions: 1.34.0
Reporter: Parag Jain
Assignee: Francis Chuang
In Go sql package when an idle connection is picked from the pool,
*ResetSession* method is called on the connection. In the drivers
implementation of this method
[here|https://github.com/apache/calcite-avatica-go/blob/main/connection.go#L236],
*registerConn* method is called which actually does an *OpenConnectionRequest*
with the existing connectionId. On the Druid side it actually throws an
exception
[here|https://github.com/apache/druid/blob/master/sql/src/main/java/org/apache/druid/sql/avatica/DruidMeta.java#L823]
saying the connection is already open. I checked other driver implementations
like [postgres|https://github.com/jackc/pgx/blob/master/stdlib/sql.go#L307] and
[mysql|https://github.com/go-sql-driver/mysql/blob/master/connection.go#L638]
for ResetSession method and they actually don't open a new connection. So not
sure about the reason for doing this here. Any thoughts on this ? Example
exception stack trace -
{code:java}
2023-05-22T19:24:47,357 ERROR [qtp44562-140]
org.apache.druid.sql.avatica.DruidMeta - Connection
[fcf73260-cb72-b867-154b-e39a19569c5e] already open.
org.apache.druid.java.util.common.ISE: Connection
[fcf73260-cb72-b867-154b-e39a19569c5e] already open.
at
org.apache.druid.sql.avatica.DruidMeta.openDruidConnection(DruidMeta.java:823)
~[classes/:?]
at
org.apache.druid.sql.avatica.DruidMeta.openConnection(DruidMeta.java:208)
~[classes/:?]
at
org.apache.calcite.avatica.remote.LocalService.apply(LocalService.java:285)
~[avatica-core-1.17.0.jar:1.17.0]
at
org.apache.calcite.avatica.remote.Service$OpenConnectionRequest.accept(Service.java:1770)
~[avatica-core-1.17.0.jar:1.17.0]
at
org.apache.calcite.avatica.remote.Service$OpenConnectionRequest.accept(Service.java:1750)
~[avatica-core-1.17.0.jar:1.17.0]
at
org.apache.calcite.avatica.remote.AbstractHandler.apply(AbstractHandler.java:94)
~[avatica-core-1.17.0.jar:1.17.0]
at
org.apache.calcite.avatica.remote.ProtobufHandler.apply(ProtobufHandler.java:46)
~[avatica-core-1.17.0.jar:1.17.0]
at
org.apache.calcite.avatica.server.AvaticaProtobufHandler.handle(AvaticaProtobufHandler.java:126)
~[avatica-server-1.17.0.jar:1.17.0]
at
org.apache.druid.sql.avatica.DruidAvaticaProtobufHandler.handle(DruidAvaticaProtobufHandler.java:61)
~[classes/:?] {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (CALCITE-5568) Decorrelate will fail. If the RelNode tree has LogicalValues
[
https://issues.apache.org/jira/browse/CALCITE-5568?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
libopeng reassigned CALCITE-5568:
-
Assignee: libopeng
> Decorrelate will fail. If the RelNode tree has LogicalValues
>
>
> Key: CALCITE-5568
> URL: https://issues.apache.org/jira/browse/CALCITE-5568
> Project: Calcite
> Issue Type: Bug
>Reporter: libopeng
>Assignee: libopeng
>Priority: Major
> Labels: pull-request-available
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Decorrelate will fail. If the RelNode tree has LogicalValues
> case:
> {code:java}
> SELECT *
> FROM emp AS e
> CROSS JOIN (VALUES 1) AS t (x)
> WHERE EXISTS (SELECT * FROM dept WHERE deptno = e.deptno){code}
> after decorrelate
> (org.apache.calcite.sql2rel.RelDecorrelator#decorrelateQuery(org.apache.calcite.rel.RelNode,
> org.apache.calcite.tools.RelBuilder))
> {code:java}
> LogicalProject(EMPNO=[$0], ENAME=[$1], JOB=[$2], MGR=[$3], HIREDATE=[$4],
> SAL=[$5], COMM=[$6], DEPTNO=[$7], SLACKER=[$8], X=[$9])
> LogicalProject(EMPNO=[$0], ENAME=[$1], JOB=[$2], MGR=[$3], HIREDATE=[$4],
> SAL=[$5], COMM=[$6], DEPTNO=[$7], SLACKER=[$8], X=[$9], $f0=[$10])
> LogicalFilter(condition=[IS NOT NULL($10)])
> LogicalCorrelate(correlation=[$cor0], joinType=[left],
> requiredColumns=[{7}])
> LogicalJoin(condition=[true], joinType=[inner])
> LogicalTableScan(table=[[CATALOG, SALES, EMP]])
> LogicalValues(tuples=[[{ 1 }]])
> LogicalAggregate(group=[{}], agg#0=[MIN($0)])
> LogicalProject($f0=[true])
> LogicalFilter(condition=[=($0, $cor0.DEPTNO)])
> LogicalTableScan(table=[[CATALOG, SALES, DEPT]])
> {code}
> LogicalCorrelate will not be processed when the RelNode tree has
> LogicalValues
> [https://github.com/apache/calcite/blob/main/core/src/main/java/org/apache/calcite/sql2rel/RelDecorrelator.java#L491]
>
> Is this as expected？
>
>
>
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CALCITE-5751) Add ARRAY_APPEND, ARRAY_POSITION, ARRAY_REMOVE ARRAY_PREPEND for Spark dialect
jackylau created CALCITE-5751: - Summary: Add ARRAY_APPEND, ARRAY_POSITION, ARRAY_REMOVE ARRAY_PREPEND for Spark dialect Key: CALCITE-5751 URL: https://issues.apache.org/jira/browse/CALCITE-5751 Project: Calcite Issue Type: Improvement Components: core Affects Versions: 1.35.0 Reporter: jackylau Fix For: 1.35.0 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CALCITE-5737) Support JDK 20
[ https://issues.apache.org/jira/browse/CALCITE-5737?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17729310#comment-17729310 ] Sergey Nuyanzin commented on CALCITE-5737: -- After looking a bit more it seems like Gradle itself doesn't have full support of JDK 20 especially for cases when Kotlin is used https://github.com/gradle/gradle/issues/23488 (in the issue itself there an estimation not earlier than July) Another way to do it (mentioned in comments) is usage of toolchains. > Support JDK 20 > -- > > Key: CALCITE-5737 > URL: https://issues.apache.org/jira/browse/CALCITE-5737 > Project: Calcite > Issue Type: Bug >Reporter: Julian Hyde >Priority: Major > Fix For: 1.35.0 > > > Support JDK 20. > We currently support JDK (and OpenJDK) versions up to 18. (CALCITE-5747 will > add support for JDK 19.) JDK 20 is the latest. We should support JDK 20 in > Calcite 1.35 if possible, or soon after. > This change would modify history.md (for the upcoming release), add JDK 20 to > the GitHub CI, and fix the build. There are deprecation warnings (which we > treat as errors) regarding the java.net.URL constructor. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CALCITE-5676) In JDBC DatabaseMetaData.getColumns, appropriately set JDBC DATA_TYPE and TYPE_NAME metadata values for MEASURE types
[
https://issues.apache.org/jira/browse/CALCITE-5676?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde resolved CALCITE-5676.
--
Fix Version/s: 1.35.0
Resolution: Fixed
Fixed in
[967bb5ac|https://github.com/apache/calcite/commit/967bb5acc5448bc8d6ee9b9f5fa3c5f0d71405c2];
thanks for the PR, [~tjbanghart]!
> In JDBC DatabaseMetaData.getColumns, appropriately set JDBC DATA_TYPE and
> TYPE_NAME metadata values for MEASURE types
> -
>
> Key: CALCITE-5676
> URL: https://issues.apache.org/jira/browse/CALCITE-5676
> Project: Calcite
> Issue Type: Sub-task
> Components: core
>Reporter: TJ Banghart
>Assignee: TJ Banghart
>Priority: Minor
> Labels: pull-request-available
> Fix For: 1.35.0
>
>
> Subtask of CALCITE-5549 to focus on the metadata we can control in
> calcite-core. Ensure that JDBC schema metadata and result set metadata agree
> on {{DATA_TYPE}} and {{TYPE_NAME}} for a {{MEASURE}}.
> The challenging part will be writing tests for this.
> [{{CalciteRemoteDriverTest.java}}|https://github.com/apache/calcite/blob/03050674594152ea785af69517f33960d7e27dd5/core/src/test/java/org/apache/calcite/jdbc/CalciteRemoteDriverTest.java#L99]
> has some that might be useful but use {{class Employee}} for a schema. We'll
> need a way to set some test {{MEASURE}} types as well.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-5676) In JDBC DatabaseMetaData.getColumns, appropriately set JDBC DATA_TYPE and TYPE_NAME metadata values for MEASURE types
[
https://issues.apache.org/jira/browse/CALCITE-5676?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde updated CALCITE-5676:
-
Summary: In JDBC DatabaseMetaData.getColumns, appropriately set JDBC
DATA_TYPE and TYPE_NAME metadata values for MEASURE types (was: Appropriately
set JDBC `DATA_TYPE` and `TYPE_NAME` metadata values for `MEASURE` types)
> In JDBC DatabaseMetaData.getColumns, appropriately set JDBC DATA_TYPE and
> TYPE_NAME metadata values for MEASURE types
> -
>
> Key: CALCITE-5676
> URL: https://issues.apache.org/jira/browse/CALCITE-5676
> Project: Calcite
> Issue Type: Sub-task
> Components: core
>Reporter: TJ Banghart
>Assignee: TJ Banghart
>Priority: Minor
> Labels: pull-request-available
>
> Subtask of CALCITE-5549 to focus on the metadata we can control in
> calcite-core. Ensure that JDBC schema metadata and result set metadata agree
> on {{DATA_TYPE}} and {{TYPE_NAME}} for a {{MEASURE}}.
> The challenging part will be writing tests for this.
> [{{CalciteRemoteDriverTest.java}}|https://github.com/apache/calcite/blob/03050674594152ea785af69517f33960d7e27dd5/core/src/test/java/org/apache/calcite/jdbc/CalciteRemoteDriverTest.java#L99]
> has some that might be useful but use {{class Employee}} for a schema. We'll
> need a way to set some test {{MEASURE}} types as well.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CALCITE-5750) SQL throws exception when the Filter include id = ARRAY [1,2,3]
xiong duan created CALCITE-5750:
---
Summary: SQL throws exception when the Filter include id = ARRAY
[1,2,3]
Key: CALCITE-5750
URL: https://issues.apache.org/jira/browse/CALCITE-5750
Project: Calcite
Issue Type: Bug
Components: core
Affects Versions: 1.34.0
Reporter: xiong duan
Assignee: xiong duan
When we create a PostgreSQL table as:
{code:java}
create table "arrayTest"
(
id integer[]
); {code}
Execute the SQL :
{code:java}
select * from arrayTest where id = array [1,2,3] and id = array [2] {code}
Will throws the exception:
{code:java}
java.lang.UnsupportedOperationException: Unsupported type when
convertTypeToSpec: ANY
Suppressed: java.lang.Throwable: Error while converting RelNode to SqlNode:
JdbcFilter(condition=[AND(=($0, ARRAY(CAST(1:BIGINT):ANY, CAST(2:BIGINT):ANY,
CAST(3:BIGINT):ANY)), =($0, ARRAY(CAST(2:BIGINT):ANY)))])
JdbcTableScan(table=[[FOODMART, arrayTest]]){code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
