[jira] [Resolved] (CALCITE-5096) Release Calcite 1.31.0
[ https://issues.apache.org/jira/browse/CALCITE-5096?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Sereda resolved CALCITE-5096. Resolution: Fixed > Release Calcite 1.31.0 > -- > > Key: CALCITE-5096 > URL: https://issues.apache.org/jira/browse/CALCITE-5096 > Project: Calcite > Issue Type: Bug >Reporter: Julian Hyde >Assignee: Andrei Sereda >Priority: Major > Fix For: 1.31.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-4512) GROUP BY expression with argument name same with SELECT field and alias causes validation error
[ https://issues.apache.org/jira/browse/CALCITE-4512?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Sereda updated CALCITE-4512: --- Fix Version/s: 1.32.0 (was: 1.31.0) > GROUP BY expression with argument name same with SELECT field and alias > causes validation error > --- > > Key: CALCITE-4512 > URL: https://issues.apache.org/jira/browse/CALCITE-4512 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.26.0 > Environment: jvm: open-jdk8 >Reporter: yanjing.wang >Assignee: yanjing.wang >Priority: Major > Labels: pull-request-available > Fix For: 1.32.0 > > Time Spent: 2.5h > Remaining Estimate: 0h > > String sql = "select replace(name, 'a', 'b') as name from users group by > replace(name, 'a', 'b')"; > > when group by expression has argument name same with select list item alias, > the group by argument will be expanded to select list item when sql > conformance supports 'groupByAlias', so the above sql will be expanded to > String sql = "select replace(name, 'a', 'b') as name from users group by > replace(replace(name, 'a', 'b'), 'a', 'b')"; > > this is unexpected. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-4987) JDBC adapter generates incorrect query when ORDER BY alias collides with field in SELECT ITEM
[
https://issues.apache.org/jira/browse/CALCITE-4987?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrei Sereda updated CALCITE-4987:
---
Fix Version/s: 1.32.0
(was: 1.31.0)
> JDBC adapter generates incorrect query when ORDER BY alias collides with
> field in SELECT ITEM
> -
>
> Key: CALCITE-4987
> URL: https://issues.apache.org/jira/browse/CALCITE-4987
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.29.0
> Environment: jdk8
>Reporter: yanjing.wang
>Assignee: yanjing.wang
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.32.0
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> I reproduce with the following query.
>
> {code:java}
> SELECT sum(shelf_width) as shelf_width FROM product ORDER BY shelf_width{code}
> you must have noticed that the shelf_width alias is same with field
> 'shelf_width' in sum.
> I expected the query hasn't changed when I test in RelToSqlConverterTest. But
> I get unexpected query is
> {code:java}
> SELECT sum(shelf_width) as shelf_width FROM product ORDER BY sum(shelf_width)
> {code}
> the unexpected query is not valid in the dialect which support order by
> alias conformance.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-5043) GROUP BY alias or SELECT field should be determined by using sql dialect when alias and field are same
[
https://issues.apache.org/jira/browse/CALCITE-5043?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrei Sereda updated CALCITE-5043:
---
Fix Version/s: 1.32.0
(was: 1.31.0)
> GROUP BY alias or SELECT field should be determined by using sql dialect when
> alias and field are same
> --
>
> Key: CALCITE-5043
> URL: https://issues.apache.org/jira/browse/CALCITE-5043
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.29.0
> Environment: jdk8
>Reporter: yanjing.wang
>Assignee: yanjing.wang
>Priority: Major
> Fix For: 1.32.0
>
>
> {noformat}
> select length(ename) as ename from emp group by ename{noformat}
> PostgreSQL: group by empno will be expanded to group by emp.empno.
> BigQuery: group by empno will be expanded to group by length(ename).
> MySQL ONLY_FULL_GROUP_BY mode(default mode): as PostgreSQL.
> MySQL extension: as PostgreSQL.
> {noformat}
> select empno + deptno as empno from emp group by empno{noformat}
> PostgreSQL: throws column "emp.empno" must appear in the GROUP BY clause or
> be used in an aggregate function.
> BigQuery: group by empno will be expanded to group by empno + deptno.
> MySQL ONLY_FULL_GROUP_BY mode(default mode): throws as PostgreSQL.
> MySQL extension: group by empno will be expanded to group by emp.empno.
> {noformat}
> select a.deptno + b.deptno as deptno from emp a , dept b group by deptno
> {noformat}
> PostgreSQL: throws column reference "deptno" is ambiguous.
> BigQuery: group by deptno will be expanded to group by a.deptno + b.deptno.
> MySQL ONLY_FULL_GROUP_BY mode(default mode): throws as PostgreSQL.
> MySQL extension: as BigQuery.
> We need support expanding GROUP BY alias or SELECT field according to the sql
> dialect.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-5126) Implicit column alias for single-column UNNEST should work with any single-column UNNEST’s input
[
https://issues.apache.org/jira/browse/CALCITE-5126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrei Sereda updated CALCITE-5126:
---
Fix Version/s: 1.32.0
(was: 1.31.0)
> Implicit column alias for single-column UNNEST should work with any
> single-column UNNEST’s input
>
>
> Key: CALCITE-5126
> URL: https://issues.apache.org/jira/browse/CALCITE-5126
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Dmitry Sysolyatin
>Assignee: Dmitry Sysolyatin
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.32.0
>
>
> Implicit column alias works only in case with scalar array, but it should
> work with any single-column UNNEST’s input
> There are the following lines in PostgresSQL documentation(
> [https://www.postgresql.org/docs/current/queries-table-expressions.html])
> regarding table functions like “UNNEST”:
> {quote}If column aliases are not supplied, then for a function returning a
> base data type, the column name is also the same as the function name.
> {quote}
> From BigQuery documentation
> ([https://cloud.google.com/bigquery/docs/reference/standard-sql/query-syntax#implicit_aliases):]
> {quote}For input ARRAYs of most element types, the output of UNNEST generally
> has one column. This single column has an optional alias, which you can use
> to refer to the column elsewhere in the query
> {quote}
> Examples:
> {code:java}
> psql => SELECT * FROM UNNEST(array(select 1 as x)) y;
> y
> ---
> 1
> (1 row)
> {code}
> {code:java}
> CREATE TABLE testtable (
> strings text[]
> );
> INSERT INTO testtable VALUES(ARRAY['1', '2', '3'])
> SELECT array(SELECT 'toast' || x FROM unnest(tt.strings) x) FROM testtable as
> tt;
> array
>
> {toast1,toast2,toast3}
> (1 row)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-5052) Calcite testkit issue loading resources from jar in DiffRepository (bazel)
[
https://issues.apache.org/jira/browse/CALCITE-5052?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrei Sereda updated CALCITE-5052:
---
Fix Version/s: 1.32.0
(was: 1.31.0)
> Calcite testkit issue loading resources from jar in DiffRepository (bazel)
> --
>
> Key: CALCITE-5052
> URL: https://issues.apache.org/jira/browse/CALCITE-5052
> Project: Calcite
> Issue Type: Bug
>Reporter: Marieke Gueye
>Assignee: Marieke Gueye
>Priority: Blocker
> Labels: pull-request-available
> Fix For: 1.32.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Calcite testkit assumes resources are packaged/available with the {{file:}}
> protocol, however jar resources have {{jar:}} as the protocol to indicate the
> resource is within the internal jar file system.
> Here is where calcite requires a {{file:}} protocol:
> [Sources.java|https://github.com/apache/calcite/blob/4bc916619fd286b2c0cc4d5c653c96a68801d74e/core/src/main/java/org/apache/calcite/util/Sources.java#L186]
> Here is where the resource is loaded and returns the URL to the file:
> [DiffRepository.java|https://github.com/apache/calcite/blob/4bc916619fd286b2c0cc4d5c653c96a68801d74e/core/src/test/java/org/apache/calcite/test/DiffRepository.java#L231]
> In bazel builds this URL results in a {{jar:}} protocol.
> Here is an example of test that would fail: {{ExampleTest.kt}}:
>
> {code}
> package com.looker.bazeltest
> import org.apache.calcite.test.DiffRepository
> import org.junit.jupiter.api.Test
> class ExampleTest {
> @Test
> fun testFixtureJarResource() {
> DiffRepository.lookup(ExampleTest::class.java)
> }
> }
> {code}
>
> resource {{ExampleTest.xml}}:
> {code}
>
>
>
> {code}
> Built with Bazel {{BUILD.bazel}}:
> {code}
> kt_jvm_test(
> name = "ExampleTest",
> srcs = glob(["src/test/kotlin/com/bazeltest/ExampleTest.kt"]),
> main_class = "org.junit.platform.console.ConsoleLauncher",
> resources = ["src/test/resources/com/bazeltest/ExampleTest.xml"],
> deps = [
> "@maven//:com_google_truth_truth",
> "@maven//:junit_junit",
> "@maven//:org_apache_calcite_calcite_testkit",
> "@maven//:org_junit_jupiter_junit_jupiter_api",
> "@maven//:org_junit_jupiter_junit_jupiter_engine",
> "@maven//:org_junit_platform_junit_platform_console",
> ],
> )
> {code}
> output:
> {noformat}{{'-- JUnit Jupiter [OK]
> '-- ExampleTest [OK]
> '-- testFixtureJarResource() [X] java.lang.UnsupportedOperationException
> Failures (1):
> JUnit Jupiter:ExampleTest:testFixtureJarResource()
> MethodSource [className = 'com.looker.bazeltest.ExampleTest', methodName =
> 'testFixtureJarResource', methodParameterTypes = '']
> => com.google.common.util.concurrent.UncheckedExecutionException:
> java.lang.UnsupportedOperationException
> com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2051)
> com.google.common.cache.LocalCache.get(LocalCache.java:3962)
> com.google.common.cache.LocalCache.getOrLoad(LocalCache.java:3985)
> com.google.common.cache.LocalCache$LocalLoadingCache.get(LocalCache.java:4946)
> com.google.common.cache.LocalCache$LocalLoadingCache.getUnchecked(LocalCache.java:4952)
> [...]
> Caused by: java.lang.UnsupportedOperationException
> org.apache.calcite.util.Sources$FileSource.file(Sources.java:245)
> org.apache.calcite.test.DiffRepository$Key.toRepo(DiffRepository.java:897)
> com.google.common.cache.CacheLoader$FunctionToCacheLoader.load(CacheLoader.java:168)
> com.google.common.cache.LocalCache$LoadingValueReference.loadFuture(LocalCache.java:3529)
> com.google.common.cache.LocalCache$Segment.loadSync(LocalCache.java:2278)
> [...]
> Test run finished after 122 ms
> [ 2 containers found ]
> [ 0 containers skipped ]
> [ 2 containers started ]
> [ 0 containers aborted ]
> [ 2 containers successful ]
> [ 0 containers failed ]
> [ 1 tests found ]
> [ 0 tests skipped ]
> [ 1 tests started ]
> [ 0 tests aborted ]
> [ 0 tests successful ] [ 1 tests failed ]}}
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-1776) Implement CORR and REGR_* aggregate functions
[ https://issues.apache.org/jira/browse/CALCITE-1776?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Sereda updated CALCITE-1776: --- Fix Version/s: 1.32.0 (was: 1.31.0) > Implement CORR and REGR_* aggregate functions > - > > Key: CALCITE-1776 > URL: https://issues.apache.org/jira/browse/CALCITE-1776 > Project: Calcite > Issue Type: New Feature >Reporter: Dmitri Shtilman >Assignee: Sergey Nuyanzin >Priority: Minor > Labels: pull-request-available > Fix For: 1.32.0 > > > Implement correlation coefficient aggregate: CORR > As well as the missing regression aggregates: > REGR_SLOPE, REGR_INTERCEPT, REGR_COUNT, REGR_R2, REGR_AVGX, REGR_AVGY, > REGR_SXY > For reference, REGR_SXX and REGR_SYY have been added in [CALCITE-422] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-4887) Filter subQuery remove not fully optimized
[
https://issues.apache.org/jira/browse/CALCITE-4887?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrei Sereda updated CALCITE-4887:
---
Fix Version/s: 1.32.0
(was: 1.31.0)
> Filter subQuery remove not fully optimized
> --
>
> Key: CALCITE-4887
> URL: https://issues.apache.org/jira/browse/CALCITE-4887
> Project: Calcite
> Issue Type: Improvement
>Affects Versions: 1.28.0
>Reporter: bingfeng.guo
>Assignee: bingfeng.guo
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.32.0
>
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
> for example:
> {quote}SELECT
> count(1)
> FROM
> SSB.P_LINEORDER as P_LINEORDER
> LEFT JOIN SSB.PART as PART ON P_LINEORDER.LO_PARTKEY = PART.P_PARTKEY
> LEFT JOIN SSB.DATES as DATES ON P_LINEORDER.LO_ORDERDATE = DATES.D_DATEKEY
> LEFT JOIN SSB.CUSTOMER as CUSTOMER ON P_LINEORDER.LO_CUSTKEY =
> CUSTOMER.C_CUSTKEY
> LEFT JOIN SSB.SUPPLIER as SUPPLIER ON P_LINEORDER.LO_SUPPKEY =
> SUPPLIER.S_SUPPKEY
> WHERE
> P_LINEORDER.LO_ORDERDATE = '1992-01-01'
> or (
> P_LINEORDER.LO_ORDERDATE in (
> select
> D_DATEKEY
> from
> SSB.DATES
> where
> DATES.D_DATEKEY = '1992-01-01'
> )
> )
> LIMIT
> 500
> {quote}
>
> plan is
>
> {quote}LimitRel(ctx=[], fetch=[500])
> AggregateRel(group-set=[[]], groups=[null], EXPR$0=[COUNT()])
> ProjectRel(ctx=[])
> FilterRel(condition=[OR(=($5, 1992-01-01), CAST(AND(IS NOT NULL($65),
> <>($62, 0))):BOOLEAN)])
> JoinRel(condition=[=($5, $64)], joinType=[left])
> JoinRel(condition=[true], joinType=[inner])
> JoinRel(condition=[=($4, $55)], joinType=[left])
> JoinRel(condition=[=($2, $47)], joinType=[left])
> JoinRel(condition=[=($5, $30)], joinType=[left])
> JoinRel(condition=[=($3, $21)], joinType=[left])
> TableScan(table=[[SSB, P_LINEORDER]], fields=[[0, 1, 2,
> 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20]])
> TableScan(table=[[SSB, PART]], fields=[[0, 1, 2, 3, 4,
> 5, 6, 7, 8]])
> TableScan(table=[[SSB, DATES]], fields=[[0, 1, 2, 3, 4,
> 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16]])
> TableScan(table=[[SSB, CUSTOMER]], fields=[[0, 1, 2, 3, 4,
> 5, 6, 7]])
> TableScan(table=[[SSB, SUPPLIER]], fields=[[0, 1, 2, 3, 4, 5,
> 6]])
> AggregateRel(group-set=[[]], groups=[null], c=[COUNT()],
> ck=[COUNT($0)])
> ProjectRel(D_DATEKEY=[$0])
> FilterRel(condition=[=($0, 1992-01-01)])
> TableScan(table=[[SSB, DATES]], fields=[[0, 1, 2, 3, 4,
> 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16]])
> AggregateRel(group-set=[[0, 1]], groups=[null])
> ProjectRel(D_DATEKEY=[$0], i=[true])
> FilterRel(condition=[=($0, 1992-01-01)])
> TableScan(table=[[SSB, DATES]], fields=[[0, 1, 2, 3, 4, 5,
> 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16]])
> {quote}
>
>
> But the optimal plan should be
> {quote}
> LimitRel(fetch=[500])
> AggregateRel(group-set=[[]], groups=[null], EXPR$0=[COUNT()])
> ProjectRel(ctx=[])
> FilterRel(condition=[=($5, 1992-01-01)])
> JoinRel(condition=[=($5, $62)], joinType=[inner])
> JoinRel(condition=[=($4, $55)], joinType=[left])
> JoinRel(condition=[=($2, $47)], joinType=[left])
> JoinRel(condition=[=($5, $30)], joinType=[left])
> JoinRel(condition=[=($3, $21)], joinType=[left])
> TableScan(table=[[SSB, P_LINEORDER]], fields=[[0, 1, 2,
> 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20]])
> TableScan(table=[[SSB, PART]], fields=[[0, 1, 2, 3, 4, 5,
> 6, 7, 8]])
> TableScan(table=[[SSB, DATES]], fields=[[0, 1, 2, 3, 4, 5,
> 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16]])
> TableScan(table=[[SSB, CUSTOMER]], fields=[[0, 1, 2, 3, 4, 5,
> 6, 7]])
> TableScan(table=[[SSB, SUPPLIER]], fields=[[0, 1, 2, 3, 4, 5,
> 6]])
> AggregateRel(group-set=[[0]], groups=[null])
> ProjectRel(D_DATEKEY=[$0])
> FilterRel(condition=[=($0, 1992-01-01)])
> TableScan(table=[[SSB, DATES]], fields=[[0, 1, 2, 3, 4, 5,
> 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16]])
>
> {quote}
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-4908) Support classpath resource name as model resource path
[ https://issues.apache.org/jira/browse/CALCITE-4908?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Sereda updated CALCITE-4908: --- Fix Version/s: 1.32.0 (was: 1.31.0) > Support classpath resource name as model resource path > -- > > Key: CALCITE-4908 > URL: https://issues.apache.org/jira/browse/CALCITE-4908 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: Woonsan Ko >Priority: Minor > Labels: pull-request-available > Fix For: 1.32.0 > > Time Spent: 1h > Remaining Estimate: 0h > > In JDBC uri with a model file reference like > 'jdbc:calcite:model=/a/b/c/model.json', it would be nice if we support a > classpath resource name (path) too like > 'jdbc:calcite:model=classpath:/a/b/c/model.json'. > It would be very helpful to my web application envs. A classpath resource > cannot be always converted to a File object if the resource is in a jar or > war, etc. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CALCITE-1776) Implement CORR and REGR_* aggregate functions
[ https://issues.apache.org/jira/browse/CALCITE-1776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17549506#comment-17549506 ] Andrei Sereda commented on CALCITE-1776: Hello, Please let me know if you want this issue to be included in the next Calcite release 1.31. If so, do you think it can be resolved in 1-2 weeks ? Our goal is to create an RC mid-June. Thanks. > Implement CORR and REGR_* aggregate functions > - > > Key: CALCITE-1776 > URL: https://issues.apache.org/jira/browse/CALCITE-1776 > Project: Calcite > Issue Type: New Feature >Reporter: Dmitri Shtilman >Assignee: Sergey Nuyanzin >Priority: Minor > Labels: pull-request-available > Fix For: 1.31.0 > > > Implement correlation coefficient aggregate: CORR > As well as the missing regression aggregates: > REGR_SLOPE, REGR_INTERCEPT, REGR_COUNT, REGR_R2, REGR_AVGX, REGR_AVGY, > REGR_SXY > For reference, REGR_SXX and REGR_SYY have been added in [CALCITE-422] -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (CALCITE-4887) Filter subQuery remove not fully optimized
[
https://issues.apache.org/jira/browse/CALCITE-4887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17549502#comment-17549502
]
Andrei Sereda commented on CALCITE-4887:
Hello,
Please let me know if you want this issue to be included in the next Calcite
release 1.31.
If so, do you think it can be resolved in 1-2 weeks ?
Our goal is to create an RC mid-June.
Thanks.
> Filter subQuery remove not fully optimized
> --
>
> Key: CALCITE-4887
> URL: https://issues.apache.org/jira/browse/CALCITE-4887
> Project: Calcite
> Issue Type: Improvement
>Affects Versions: 1.28.0
>Reporter: bingfeng.guo
>Assignee: bingfeng.guo
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.31.0
>
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
> for example:
> {quote}SELECT
> count(1)
> FROM
> SSB.P_LINEORDER as P_LINEORDER
> LEFT JOIN SSB.PART as PART ON P_LINEORDER.LO_PARTKEY = PART.P_PARTKEY
> LEFT JOIN SSB.DATES as DATES ON P_LINEORDER.LO_ORDERDATE = DATES.D_DATEKEY
> LEFT JOIN SSB.CUSTOMER as CUSTOMER ON P_LINEORDER.LO_CUSTKEY =
> CUSTOMER.C_CUSTKEY
> LEFT JOIN SSB.SUPPLIER as SUPPLIER ON P_LINEORDER.LO_SUPPKEY =
> SUPPLIER.S_SUPPKEY
> WHERE
> P_LINEORDER.LO_ORDERDATE = '1992-01-01'
> or (
> P_LINEORDER.LO_ORDERDATE in (
> select
> D_DATEKEY
> from
> SSB.DATES
> where
> DATES.D_DATEKEY = '1992-01-01'
> )
> )
> LIMIT
> 500
> {quote}
>
> plan is
>
> {quote}LimitRel(ctx=[], fetch=[500])
> AggregateRel(group-set=[[]], groups=[null], EXPR$0=[COUNT()])
> ProjectRel(ctx=[])
> FilterRel(condition=[OR(=($5, 1992-01-01), CAST(AND(IS NOT NULL($65),
> <>($62, 0))):BOOLEAN)])
> JoinRel(condition=[=($5, $64)], joinType=[left])
> JoinRel(condition=[true], joinType=[inner])
> JoinRel(condition=[=($4, $55)], joinType=[left])
> JoinRel(condition=[=($2, $47)], joinType=[left])
> JoinRel(condition=[=($5, $30)], joinType=[left])
> JoinRel(condition=[=($3, $21)], joinType=[left])
> TableScan(table=[[SSB, P_LINEORDER]], fields=[[0, 1, 2,
> 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20]])
> TableScan(table=[[SSB, PART]], fields=[[0, 1, 2, 3, 4,
> 5, 6, 7, 8]])
> TableScan(table=[[SSB, DATES]], fields=[[0, 1, 2, 3, 4,
> 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16]])
> TableScan(table=[[SSB, CUSTOMER]], fields=[[0, 1, 2, 3, 4,
> 5, 6, 7]])
> TableScan(table=[[SSB, SUPPLIER]], fields=[[0, 1, 2, 3, 4, 5,
> 6]])
> AggregateRel(group-set=[[]], groups=[null], c=[COUNT()],
> ck=[COUNT($0)])
> ProjectRel(D_DATEKEY=[$0])
> FilterRel(condition=[=($0, 1992-01-01)])
> TableScan(table=[[SSB, DATES]], fields=[[0, 1, 2, 3, 4,
> 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16]])
> AggregateRel(group-set=[[0, 1]], groups=[null])
> ProjectRel(D_DATEKEY=[$0], i=[true])
> FilterRel(condition=[=($0, 1992-01-01)])
> TableScan(table=[[SSB, DATES]], fields=[[0, 1, 2, 3, 4, 5,
> 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16]])
> {quote}
>
>
> But the optimal plan should be
> {quote}
> LimitRel(fetch=[500])
> AggregateRel(group-set=[[]], groups=[null], EXPR$0=[COUNT()])
> ProjectRel(ctx=[])
> FilterRel(condition=[=($5, 1992-01-01)])
> JoinRel(condition=[=($5, $62)], joinType=[inner])
> JoinRel(condition=[=($4, $55)], joinType=[left])
> JoinRel(condition=[=($2, $47)], joinType=[left])
> JoinRel(condition=[=($5, $30)], joinType=[left])
> JoinRel(condition=[=($3, $21)], joinType=[left])
> TableScan(table=[[SSB, P_LINEORDER]], fields=[[0, 1, 2,
> 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20]])
> TableScan(table=[[SSB, PART]], fields=[[0, 1, 2, 3, 4, 5,
> 6, 7, 8]])
> TableScan(table=[[SSB, DATES]], fields=[[0, 1, 2, 3, 4, 5,
> 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16]])
> TableScan(table=[[SSB, CUSTOMER]], fields=[[0, 1, 2, 3, 4, 5,
> 6, 7]])
> TableScan(table=[[SSB, SUPPLIER]], fields=[[0, 1, 2, 3, 4, 5,
> 6]])
> AggregateRel(group-set=[[0]], groups=[null])
> ProjectRel(D_DATEKEY=[$0])
> FilterRel(condition=[=($0, 1992-01-01)])
> TableScan(table=[[SSB, DATES]], fields=[[0, 1, 2, 3, 4, 5,
> 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16]])
>
> {quote}
>
>
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (CALCITE-2552) JDBC adapter generates Non-Dialect Specific Order By Field Identifier
[
https://issues.apache.org/jira/browse/CALCITE-2552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17549505#comment-17549505
]
Andrei Sereda commented on CALCITE-2552:
Hello,
Please let me know if you want this issue to be included in the next Calcite
release 1.31.
If so, do you think it can be resolved in 1-2 weeks ?
Our goal is to create an RC mid-June.
Thanks.
> JDBC adapter generates Non-Dialect Specific Order By Field Identifier
> -
>
> Key: CALCITE-2552
> URL: https://issues.apache.org/jira/browse/CALCITE-2552
> Project: Calcite
> Issue Type: Bug
> Components: jdbc-adapter
>Reporter: KrishnaKant Agrawal
>Assignee: yanjing.wang
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.31.0
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> The Order By Keys when resolved during RelToSql Conversion is hardcoded to
> fallback to Original Expression instead of an alias(if present)
>
> This should be based on the Dialect set in RelToSqlConverter.
>
> If the Order By Key is a Projection which was Aliased, the Output query
> contains the original column name instead of the Alias, which is not allowed
> in HIVE as valid Order By keys are to be selected from Select List
> Identifiers only.
>
> Generated SQL(Failing in hive!),
> {code:java}
> Select first_name as n1 from emp order by first_name;{code}
> Expected SQL,
> {code:java}
> Select first_name as n1 from emp order by n1;{code}
> The Code Excerpt Responsible for this particular use case:-
> (SqlImplementor.java:952)
> {code:java}
> public SqlNode field(int ordinal) {
> final SqlNode selectItem = selectList.get(ordinal);
> switch (selectItem.getKind()) {
> case AS:
> return ((SqlCall) selectItem).operand(0);
> }
> return selectItem;
> }{code}
>
> I create the TableScan, Projection(with the alias) & Sort in the mentioned
> order.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (CALCITE-4512) GROUP BY expression with argument name same with SELECT field and alias causes validation error
[ https://issues.apache.org/jira/browse/CALCITE-4512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17549503#comment-17549503 ] Andrei Sereda commented on CALCITE-4512: Hello, Please let me know if you want this issue to be included in the next Calcite release 1.31. If so, do you think it can be resolved in 1-2 weeks ? Our goal is to create an RC mid-June. Thanks. > GROUP BY expression with argument name same with SELECT field and alias > causes validation error > --- > > Key: CALCITE-4512 > URL: https://issues.apache.org/jira/browse/CALCITE-4512 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.26.0 > Environment: jvm: open-jdk8 >Reporter: yanjing.wang >Assignee: yanjing.wang >Priority: Major > Labels: pull-request-available > Fix For: 1.31.0 > > Time Spent: 2.5h > Remaining Estimate: 0h > > String sql = "select replace(name, 'a', 'b') as name from users group by > replace(name, 'a', 'b')"; > > when group by expression has argument name same with select list item alias, > the group by argument will be expanded to select list item when sql > conformance supports 'groupByAlias', so the above sql will be expanded to > String sql = "select replace(name, 'a', 'b') as name from users group by > replace(replace(name, 'a', 'b'), 'a', 'b')"; > > this is unexpected. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (CALCITE-4907) JDBC adapter cannot push down join ON TRUE (cartesian product) or ON FALSE
[ https://issues.apache.org/jira/browse/CALCITE-4907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17549501#comment-17549501 ] Andrei Sereda commented on CALCITE-4907: Hello, Please let me know if you want this issue to be included in the next Calcite release 1.31. If so, do you think it can be resolved in 1-2 weeks ? Our goal is to create an RC mid-June. Thanks. > JDBC adapter cannot push down join ON TRUE (cartesian product) or ON FALSE > --- > > Key: CALCITE-4907 > URL: https://issues.apache.org/jira/browse/CALCITE-4907 > Project: Calcite > Issue Type: Bug > Components: jdbc-adapter >Affects Versions: 1.28.0 >Reporter: Francesco Gini >Assignee: Francesco Gini >Priority: Major > Labels: pull-request-available > Fix For: 1.31.0 > > Time Spent: 2h 40m > Remaining Estimate: 0h > > JDBC adapter (in JdbcJoinRule) cannot push down join ON TRUE (cartesian > product) or ON FALSE. This results in implementing the join in memory via > _EnumerableNestedLoopJoin_ which is a less efficient implementation. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (CALCITE-4913) Correlated variables in a select list are not deduplicated
[
https://issues.apache.org/jira/browse/CALCITE-4913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17549500#comment-17549500
]
Andrei Sereda commented on CALCITE-4913:
Hello,
Please let me know if you want this issue to be included in the next Calcite
release 1.31.
If so, do you think it can be resolved in 1-2 weeks ?
Our goal is to create an RC mid-June.
Thanks.
> Correlated variables in a select list are not deduplicated
> --
>
> Key: CALCITE-4913
> URL: https://issues.apache.org/jira/browse/CALCITE-4913
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.28.0
>Reporter: Konstantin Orlov
>Assignee: Konstantin Orlov
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.31.0
>
> Time Spent: 12h 10m
> Remaining Estimate: 0h
>
> Currently, the deduplication of correlated variables ain't done for
> correlates in select list. Looks like the root cause here is same as for
> CALCITE-4673, but, unfortunately, suggested patch has addressed only the
> particular problem with a table function. It would be great to provide a more
> gereric fix.
> Besides, the project rel doesn't expose any correlated variables that should
> be set by this node.
> The problematic query is follow:
> {code:java}
> select e.deptno,
>(select count(*) from emp where e.deptno > 0) as c1,
>(select count(*) from emp where e.deptno > 0 and e.deptno < 10) as c2
> from emp e;
> {code}
> Currently after conversion to relational nodes it looks like:
> {code:java}
> LogicalProject(DEPTNO=[$7], EXPR$1=[$SCALAR_QUERY({
> LogicalAggregate(group=[{}], EXPR$0=[COUNT()])
> LogicalProject($f0=[0])
> LogicalFilter(condition=[>($cor0.DEPTNO, 0)])
> LogicalTableScan(table=[[CATALOG, SALES, EMP]])
> })], EXPR$2=[$SCALAR_QUERY({
> LogicalAggregate(group=[{}], EXPR$0=[COUNT()])
> LogicalProject($f0=[0])
> LogicalFilter(condition=[AND(>($cor1.DEPTNO, 0), <($cor2.DEPTNO, 10))])
> LogicalTableScan(table=[[CATALOG, SALES, EMP]])
> })])
> LogicalTableScan(table=[[CATALOG, SALES, EMP]])
> {code}
> All the correlates are set by the very top project node and could be
> represented by only one variable.
> Moreover, I've tried to add the query above to _sub-query.iq_ and got the
> follow error:
> {code:java}
> > java.sql.SQLException: Error while executing SQL "select e.deptno,
> >(select count(*) from emp where e.deptno > 0) as c1,
> >(select count(*) from emp where e.deptno > 0 and e.deptno < 10) as c2
> > from emp e": cm.mapCorToCorRel.get($cor1)
> > at org.apache.calcite.avatica.Helper.createException(Helper.java:56)
> > at org.apache.calcite.avatica.Helper.createException(Helper.java:41)
> > at
> > org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:163)
> > at
> > org.apache.calcite.avatica.AvaticaStatement.executeQuery(AvaticaStatement.java:227)
> > at net.hydromatic.quidem.Quidem.checkResult(Quidem.java:325)
> > at net.hydromatic.quidem.Quidem.access$2800(Quidem.java:54)
> > at
> > net.hydromatic.quidem.Quidem$ContextImpl.checkResult(Quidem.java:1748)
> > at
> > net.hydromatic.quidem.Quidem$CheckResultCommand.execute(Quidem.java:1079)
> > at
> > net.hydromatic.quidem.Quidem$CompositeCommand.execute(Quidem.java:1549)
> > at net.hydromatic.quidem.Quidem.execute(Quidem.java:216)
> > at org.apache.calcite.test.QuidemTest.checkRun(QuidemTest.java:173)
> > at org.apache.calcite.test.QuidemTest.test(QuidemTest.java:224)
> > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> > at
> > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> > at
> > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> > at java.lang.reflect.Method.invoke(Method.java:498)
> > at
> > org.junit.platform.commons.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:725)
> > at
> > org.junit.jupiter.engine.execution.MethodInvocation.proceed(MethodInvocation.java:60)
> > at
> > org.junit.jupiter.engine.execution.InvocationInterceptorChain$ValidatingInvocation.proceed(InvocationInterceptorChain.java:131)
> > at
> > org.junit.jupiter.engine.extension.TimeoutInvocation.proceed(TimeoutInvocation.java:46)
> > at
> > org.junit.jupiter.engine.extension.TimeoutExtension.intercept(TimeoutExtension.java:149)
> > at
> > org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestableMethod(TimeoutExtension.java:140)
> > at
> > org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestTemplateMethod(TimeoutExtension.java:92)
> > at
> >
[jira] [Commented] (CALCITE-5169) 'xx < 1 OR xx > 1' cannot be simplified to 'xx <> 1'
[
https://issues.apache.org/jira/browse/CALCITE-5169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17549499#comment-17549499
]
Andrei Sereda commented on CALCITE-5169:
Hello,
Please let me know if you want this issue to be included in the next Calcite
release 1.31.
If so, do you think it can be resolved in 1-2 weeks ?
Our goal is to create an RC mid-June.
Thanks.
> 'xx < 1 OR xx > 1' cannot be simplified to 'xx <> 1'
>
>
> Key: CALCITE-5169
> URL: https://issues.apache.org/jira/browse/CALCITE-5169
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.30.0
>Reporter: Benchao Li
>Assignee: Benchao Li
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.31.0
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> As described in the title, {{xx < 1 OR xx > 1}} should be simplified to {{xx
> <> 1}}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (CALCITE-4987) JDBC adapter generates incorrect query when ORDER BY alias collides with field in SELECT ITEM
[
https://issues.apache.org/jira/browse/CALCITE-4987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17549498#comment-17549498
]
Andrei Sereda commented on CALCITE-4987:
Hello,
Please let me know if you want this issue to be included in the next Calcite
release 1.31.
If so, do you think it can be resolved in 1-2 weeks ?
Our goal is to create an RC mid-June.
Thanks.
> JDBC adapter generates incorrect query when ORDER BY alias collides with
> field in SELECT ITEM
> -
>
> Key: CALCITE-4987
> URL: https://issues.apache.org/jira/browse/CALCITE-4987
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.29.0
> Environment: jdk8
>Reporter: yanjing.wang
>Assignee: yanjing.wang
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.31.0
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> I reproduce with the following query.
>
> {code:java}
> SELECT sum(shelf_width) as shelf_width FROM product ORDER BY shelf_width{code}
> you must have noticed that the shelf_width alias is same with field
> 'shelf_width' in sum.
> I expected the query hasn't changed when I test in RelToSqlConverterTest. But
> I get unexpected query is
> {code:java}
> SELECT sum(shelf_width) as shelf_width FROM product ORDER BY sum(shelf_width)
> {code}
> the unexpected query is not valid in the dialect which support order by
> alias conformance.
>
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (CALCITE-5043) GROUP BY alias or SELECT field should be determined by using sql dialect when alias and field are same
[
https://issues.apache.org/jira/browse/CALCITE-5043?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17549497#comment-17549497
]
Andrei Sereda commented on CALCITE-5043:
Hello,
Please let me know if you want this issue to be included in the next Calcite
release 1.31.
If so, do you think it can be resolved in 1-2 weeks ?
Our goal is to create an RC mid-June.
Thanks.
> GROUP BY alias or SELECT field should be determined by using sql dialect when
> alias and field are same
> --
>
> Key: CALCITE-5043
> URL: https://issues.apache.org/jira/browse/CALCITE-5043
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.29.0
> Environment: jdk8
>Reporter: yanjing.wang
>Assignee: yanjing.wang
>Priority: Major
> Fix For: 1.31.0
>
>
> {noformat}
> select length(ename) as ename from emp group by ename{noformat}
> PostgreSQL: group by empno will be expanded to group by emp.empno.
> BigQuery: group by empno will be expanded to group by length(ename).
> MySQL ONLY_FULL_GROUP_BY mode(default mode): as PostgreSQL.
> MySQL extension: as PostgreSQL.
> {noformat}
> select empno + deptno as empno from emp group by empno{noformat}
> PostgreSQL: throws column "emp.empno" must appear in the GROUP BY clause or
> be used in an aggregate function.
> BigQuery: group by empno will be expanded to group by empno + deptno.
> MySQL ONLY_FULL_GROUP_BY mode(default mode): throws as PostgreSQL.
> MySQL extension: group by empno will be expanded to group by emp.empno.
> {noformat}
> select a.deptno + b.deptno as deptno from emp a , dept b group by deptno
> {noformat}
> PostgreSQL: throws column reference "deptno" is ambiguous.
> BigQuery: group by deptno will be expanded to group by a.deptno + b.deptno.
> MySQL ONLY_FULL_GROUP_BY mode(default mode): throws as PostgreSQL.
> MySQL extension: as BigQuery.
> We need support expanding GROUP BY alias or SELECT field according to the sql
> dialect.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (CALCITE-5045) Alias within GroupingSets throws type mis-match exception
[
https://issues.apache.org/jira/browse/CALCITE-5045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17549486#comment-17549486
]
Andrei Sereda commented on CALCITE-5045:
Hello,
Please let me know if you want this issue to be included in the next Calcite
release 1.31.
If so, do you think it can be resolved in 1-2 weeks ?
Our goal is to create an RC mid-June.
Thanks.
> Alias within GroupingSets throws type mis-match exception
> -
>
> Key: CALCITE-5045
> URL: https://issues.apache.org/jira/browse/CALCITE-5045
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.29.0
> Environment: jdk8
>Reporter: yanjing.wang
>Assignee: yanjing.wang
>Priority: Major
> Fix For: 1.31.0
>
>
> {noformat}
> @Test void testAliasWithinGroupingSets() {
> final String sql = "SELECT empno / 2 AS x\n"
> + "FROM emp\n"
> + "GROUP BY ROLLUP(x)";
> sql(sql)
> .withConformance(SqlConformanceEnum.LENIENT)
> .ok();
> }{noformat}
> the above test throws
> {noformat}
> Conversion to relational algebra failed to preserve datatypes:
> validated type:
> RecordType(INTEGER NOT NULL X) NOT NULL
> converted type:
> RecordType(INTEGER X) NOT NULL{noformat}
> The X has lost its NOT NULL constraints.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (CALCITE-5086) Core parser should allow "OFFSET" to occur before "LIMIT"
[ https://issues.apache.org/jira/browse/CALCITE-5086?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17549484#comment-17549484 ] Andrei Sereda commented on CALCITE-5086: Hello, Please let me know if you want this issue to be included in the next Calcite release 1.31. If so, do you think it can be resolved in 1-2 weeks ? Our goal is to create an RC mid-June. Thanks. > Core parser should allow "OFFSET" to occur before "LIMIT" > - > > Key: CALCITE-5086 > URL: https://issues.apache.org/jira/browse/CALCITE-5086 > Project: Calcite > Issue Type: Improvement > Components: core >Affects Versions: 1.30.0 > Environment: jdk8 >Reporter: yanjing.wang >Assignee: yanjing.wang >Priority: Minor > Labels: pull-request-available > Fix For: 1.31.0 > > Time Spent: 40m > Remaining Estimate: 0h > > The core parser supports 'LIMIT count OFFSET start' now, otherwise trino > supports 'OFFSET start LIMIT count', we can make an improvement to support > both. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (CALCITE-5060) SqlTypeUtil#canAssignFrom cover Map/Row/Multiset
[ https://issues.apache.org/jira/browse/CALCITE-5060?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17549485#comment-17549485 ] Andrei Sereda commented on CALCITE-5060: Hello, Please let me know if you want this issue to be included in the next Calcite release 1.31. If so, do you think it can be resolved in 1-2 weeks ? Our goal is to create an RC mid-June. Thanks. > SqlTypeUtil#canAssignFrom cover Map/Row/Multiset > > > Key: CALCITE-5060 > URL: https://issues.apache.org/jira/browse/CALCITE-5060 > Project: Calcite > Issue Type: Bug > Components: core >Reporter: Jianhui Dong >Priority: Major > Fix For: 1.31.0 > > -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (CALCITE-5134) Queries with subquery inside select list does not work if subquery uses table from left join
[
https://issues.apache.org/jira/browse/CALCITE-5134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17549462#comment-17549462
]
Andrei Sereda commented on CALCITE-5134:
Hello,
Please let me know if you want this issue to be included in the next Calcite
release 1.31.
If so, do you think it can be resolved in 1-2 weeks ?
Our goal is to create an RC mid-June.
Thanks.
> Queries with subquery inside select list does not work if subquery uses table
> from left join
>
>
> Key: CALCITE-5134
> URL: https://issues.apache.org/jira/browse/CALCITE-5134
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Dmitry Sysolyatin
>Assignee: Benchao Li
>Priority: Major
> Fix For: 1.31.0
>
>
> {code:java}
> !use bookstore
> SELECT array(SELECT lau."books")
> FROM "bookstore"."authors" au
> LEFT JOIN "bookstore"."authors" lau ON (lau."name" = au."name");
> {code}
> Exception:
> {code:java}
> > java.lang.AssertionError: Conversion to relational algebra failed to
> > preserve datatypes:
> > validated type:
> > RecordType(RecordType(RecordType(JavaType(class java.lang.String) title,
> > JavaType(int) NOT NULL publishYear, RecordType(JavaType(int) NOT NULL
> > pageNo, JavaType(class java.lang.String) contentType) NOT NULL ARRAY NOT
> > NULL pages) NOT NULL ARRAY books) NOT NULL ARRAY NOT NULL EXPR$0) NOT NULL
> > converted type:
> > RecordType(RecordType(RecordType(JavaType(class java.lang.String) title,
> > JavaType(int) NOT NULL publishYear, RecordType(JavaType(int) NOT NULL
> > pageNo, JavaType(class java.lang.String) contentType) NOT NULL ARRAY NOT
> > NULL pages) NOT NULL ARRAY NOT NULL books) NOT NULL ARRAY NOT NULL EXPR$0)
> > NOT NULL
> > rel:
> > LogicalProject(EXPR$0=[ARRAY({
> > LogicalProject(books=[$cor0.books0])
> > LogicalValues(tuples=[[{ 0 }]])
> > })])
> > LogicalJoin(condition=[=($9, $4)], joinType=[left])
> > LogicalProject(aid=[$0], name=[$1], birthPlace=[$2], books=[$3],
> > name0=[CAST($1):VARCHAR])
> > LogicalTableScan(table=[[bookstore, authors]])
> > LogicalProject(aid=[$0], name=[$1], birthPlace=[$2], books=[$3],
> > name0=[CAST($1):VARCHAR])
> > LogicalTableScan(table=[[bookstore, authors]])
> >
> {code}
> {code:java}
> !use bookstore
> SELECT array(SELECT lau."name" || 'test')
> FROM "bookstore"."authors" au
> LEFT JOIN "bookstore"."authors" lau ON (lau."name" = au."name");
> {code}
> Exception:
> {code:java}
> > java.sql.SQLException: Error while executing SQL "SELECT array(SELECT
> > lau."name" || 'test')
> > FROM "bookstore"."authors" au
> > LEFT JOIN "bookstore"."authors" lau ON (lau."name" = au."name")": field
> > ordinal [5] out of range; input fields are: [name0, name00]
> {code}
> {code:java}
> SELECT array(SELECT * FROM UNNEST(lau."books"))
> FROM "bookstore"."authors" au
> LEFT JOIN "bookstore"."authors" lau ON (lau."name" = au."name");
> {code}
> Exception:
> {code:java}
> Suppressed: java.lang.IndexOutOfBoundsException: Index 7 out of bounds for
> length 2
> {code}
> Initially, I faced this issue when tried to execute the following query and
> got NPE exception:
> {code:java}
> SELECT c.relchecks, c.relkind, c.relhasindex, c.relhasrules,
> c.relhastriggers, c.relrowsecurity, c.relforcerowsecurity, c.relhasoids,
> c.relispartition,
> pg_catalog.array_to_string(c.reloptions || array(select 'toast.' || x from
> pg_catalog.unnest(tc.reloptions) x), ', '), c.reltablespace, CASE WHEN
> c.reloftype = 0 THEN '' ELSE c.reloftype::pg_catalog.regtype::pg_catalog.text
> END, c.relpersistence, c.relreplident
> FROM pg_catalog.pg_class c
> LEFT JOIN pg_catalog.pg_class tc ON (c.reltoastrelid =
> tc.oid)
> WHERE c.oid = '1';
> {code}
> I started to break down this query into pieces and managed to reduce it to
> queries described above.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (CALCITE-5147) Parser configured with BigQuery dialect cannot parse timestamp literal
[
https://issues.apache.org/jira/browse/CALCITE-5147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17549461#comment-17549461
]
Andrei Sereda commented on CALCITE-5147:
Hello,
Please let me know if you want this issue to be included in the next Calcite
release 1.31.
If so, do you think it can be resolved in 1-2 weeks ?
Our goal is to create an RC mid-June.
Thanks.
> Parser configured with BigQuery dialect cannot parse timestamp literal
> --
>
> Key: CALCITE-5147
> URL: https://issues.apache.org/jira/browse/CALCITE-5147
> Project: Calcite
> Issue Type: Bug
>Reporter: Steven Talbot
>Assignee: Wenrui Meng
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.31.0
>
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> It looks like
> [CALCITE-4247|https://github.com/apache/calcite/commit/c1052b343724c4a95bcf25419b70bc6032e0846b#diff-e873041549333502af52ece8a1b34301ae5a059ff4719e9bddbaef48929e7047R7796]
> creates a special string literal token for BigQuery. But that means that
> (AFAICT)
> [Parser.jj|https://github.com/apache/calcite/blob/b9c2099ea92a575084b55a206efc5dd341c0df62/core/src/main/codegen/templates/Parser.jj#L4529]
> then does not find the expected token type after a TIMESTAMP to make a
> timestamp literal, so something as simple as
> {code:java}
> SqlParser.create("SELECT TIMESTAMP '2018-02-17 13:22:04'",
> BigQuerySqlDialect.DEFAULT.configureParser(SqlParser.config())).parseQuery()
> {code}
> fails.
> Probably most other places in Parser.jj that use the "" token
> suffer from the same issue.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (CALCITE-5127) Error when executing query with subquery in select list that uses outer column of array type
[
https://issues.apache.org/jira/browse/CALCITE-5127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17549463#comment-17549463
]
Andrei Sereda commented on CALCITE-5127:
Hello,
Please let me know if you want this issue to be included in the next Calcite
release 1.31.
If so, do you think it can be resolved in 1-2 weeks ?
Our goal is to create an RC mid-June.
Thanks.
> Error when executing query with subquery in select list that uses outer
> column of array type
>
>
> Key: CALCITE-5127
> URL: https://issues.apache.org/jira/browse/CALCITE-5127
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Dmitry Sysolyatin
>Assignee: Benchao Li
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.31.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The following queries fail:
> {code}
> SELECT ARRAY(SELECT s.x) FROM (SELECT ARRAY[1,2,3] as x) s;
> SELECT ARRAY(SELECT * FROM UNNEST(s.x) y) FROM (SELECT ARRAY[1,2,3] as x) s;
> SELECT (SELECT CARDINALITY(s.x) LIMIT 1) FROM (SELECT ARRAY[1,2,3] as x) s;
>
> {code}
> With exception:
> {code}
> Caused by: java.lang.ClassCastException: java.lang.Integer cannot be cast to
> java.util.List
> {code}
> You can find test cases for this task in
> https://github.com/apache/calcite/commit/27e68ded2c3bea7d7af73dd1dc156e46fb3591a8
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (CALCITE-4908) Support classpath resource name as model resource path
[ https://issues.apache.org/jira/browse/CALCITE-4908?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17549418#comment-17549418 ] Andrei Sereda commented on CALCITE-4908: Hello, Please let me know if you want this issue to be included in the next Calcite release 1.31. If so, do you think it can be resolved in 1-2 weeks ? Our goal is to create an RC mid-June. Thanks. > Support classpath resource name as model resource path > -- > > Key: CALCITE-4908 > URL: https://issues.apache.org/jira/browse/CALCITE-4908 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: Woonsan Ko >Priority: Minor > Labels: pull-request-available > Fix For: 1.31.0 > > Time Spent: 1h > Remaining Estimate: 0h > > In JDBC uri with a model file reference like > 'jdbc:calcite:model=/a/b/c/model.json', it would be nice if we support a > classpath resource name (path) too like > 'jdbc:calcite:model=classpath:/a/b/c/model.json'. > It would be very helpful to my web application envs. A classpath resource > cannot be always converted to a File object if the resource is in a jar or > war, etc. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (CALCITE-5052) Calcite testkit issue loading resources from jar in DiffRepository (bazel)
[
https://issues.apache.org/jira/browse/CALCITE-5052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17549403#comment-17549403
]
Andrei Sereda commented on CALCITE-5052:
Hello,
Please let me know if you want this issue to be included in the next Calcite
release 1.31.
If so, do you think it can be resolved in 1-2 weeks ?
Our goal is to create an RC mid-June.
Thanks.
> Calcite testkit issue loading resources from jar in DiffRepository (bazel)
> --
>
> Key: CALCITE-5052
> URL: https://issues.apache.org/jira/browse/CALCITE-5052
> Project: Calcite
> Issue Type: Bug
>Reporter: Marieke Gueye
>Assignee: Marieke Gueye
>Priority: Blocker
> Labels: pull-request-available
> Fix For: 1.31.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Calcite testkit assumes resources are packaged/available with the {{file:}}
> protocol, however jar resources have {{jar:}} as the protocol to indicate the
> resource is within the internal jar file system.
> Here is where calcite requires a {{file:}} protocol:
> [Sources.java|https://github.com/apache/calcite/blob/4bc916619fd286b2c0cc4d5c653c96a68801d74e/core/src/main/java/org/apache/calcite/util/Sources.java#L186]
> Here is where the resource is loaded and returns the URL to the file:
> [DiffRepository.java|https://github.com/apache/calcite/blob/4bc916619fd286b2c0cc4d5c653c96a68801d74e/core/src/test/java/org/apache/calcite/test/DiffRepository.java#L231]
> In bazel builds this URL results in a {{jar:}} protocol.
> Here is an example of test that would fail: {{ExampleTest.kt}}:
>
> {code}
> package com.looker.bazeltest
> import org.apache.calcite.test.DiffRepository
> import org.junit.jupiter.api.Test
> class ExampleTest {
> @Test
> fun testFixtureJarResource() {
> DiffRepository.lookup(ExampleTest::class.java)
> }
> }
> {code}
>
> resource {{ExampleTest.xml}}:
> {code}
>
>
>
> {code}
> Built with Bazel {{BUILD.bazel}}:
> {code}
> kt_jvm_test(
> name = "ExampleTest",
> srcs = glob(["src/test/kotlin/com/bazeltest/ExampleTest.kt"]),
> main_class = "org.junit.platform.console.ConsoleLauncher",
> resources = ["src/test/resources/com/bazeltest/ExampleTest.xml"],
> deps = [
> "@maven//:com_google_truth_truth",
> "@maven//:junit_junit",
> "@maven//:org_apache_calcite_calcite_testkit",
> "@maven//:org_junit_jupiter_junit_jupiter_api",
> "@maven//:org_junit_jupiter_junit_jupiter_engine",
> "@maven//:org_junit_platform_junit_platform_console",
> ],
> )
> {code}
> output:
> {noformat}{{'-- JUnit Jupiter [OK]
> '-- ExampleTest [OK]
> '-- testFixtureJarResource() [X] java.lang.UnsupportedOperationException
> Failures (1):
> JUnit Jupiter:ExampleTest:testFixtureJarResource()
> MethodSource [className = 'com.looker.bazeltest.ExampleTest', methodName =
> 'testFixtureJarResource', methodParameterTypes = '']
> => com.google.common.util.concurrent.UncheckedExecutionException:
> java.lang.UnsupportedOperationException
> com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2051)
> com.google.common.cache.LocalCache.get(LocalCache.java:3962)
> com.google.common.cache.LocalCache.getOrLoad(LocalCache.java:3985)
> com.google.common.cache.LocalCache$LocalLoadingCache.get(LocalCache.java:4946)
> com.google.common.cache.LocalCache$LocalLoadingCache.getUnchecked(LocalCache.java:4952)
> [...]
> Caused by: java.lang.UnsupportedOperationException
> org.apache.calcite.util.Sources$FileSource.file(Sources.java:245)
> org.apache.calcite.test.DiffRepository$Key.toRepo(DiffRepository.java:897)
> com.google.common.cache.CacheLoader$FunctionToCacheLoader.load(CacheLoader.java:168)
> com.google.common.cache.LocalCache$LoadingValueReference.loadFuture(LocalCache.java:3529)
> com.google.common.cache.LocalCache$Segment.loadSync(LocalCache.java:2278)
> [...]
> Test run finished after 122 ms
> [ 2 containers found ]
> [ 0 containers skipped ]
> [ 2 containers started ]
> [ 0 containers aborted ]
> [ 2 containers successful ]
> [ 0 containers failed ]
> [ 1 tests found ]
> [ 0 tests skipped ]
> [ 1 tests started ]
> [ 0 tests aborted ]
> [ 0 tests successful ] [ 1 tests failed ]}}
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Assigned] (CALCITE-5096) Release Calcite 1.31.0
[ https://issues.apache.org/jira/browse/CALCITE-5096?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Sereda reassigned CALCITE-5096: -- Assignee: Andrei Sereda > Release Calcite 1.31.0 > -- > > Key: CALCITE-5096 > URL: https://issues.apache.org/jira/browse/CALCITE-5096 > Project: Calcite > Issue Type: Bug >Reporter: Julian Hyde >Assignee: Andrei Sereda >Priority: Major > Fix For: 1.31.0 > > -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (CALCITE-5150) Parser should parse subquery with order by inside array constructor
[
https://issues.apache.org/jira/browse/CALCITE-5150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17549398#comment-17549398
]
Andrei Sereda commented on CALCITE-5150:
Hello,
Please let me know if you want this issue to be included in the next Calcite
release 1.31.
If so, do you think it can be resolved in 1-2 weeks ?
Our goal is to create an RC mid-June.
Thanks.
> Parser should parse subquery with order by inside array constructor
> ---
>
> Key: CALCITE-5150
> URL: https://issues.apache.org/jira/browse/CALCITE-5150
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Dmitry Sysolyatin
>Assignee: Dmitry Sysolyatin
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.31.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Parser can't parse query that looks like:
> {code}
> SELECT array(select x from (VALUES(1)) x ORDER BY x)
> {code}
> {code}
> Caused by: org.apache.calcite.sql.parser.babel.ParseException: Encountered
> "ORDER" at line 1, column 42.
> Was expecting one of:
> ")" ...
> "NATURAL" ...
> {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (CALCITE-5157) ClassCastException in checkRollUp with DOT operator
[
https://issues.apache.org/jira/browse/CALCITE-5157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17549397#comment-17549397
]
Andrei Sereda commented on CALCITE-5157:
Hello,
Please let me know if you want this issue to be included in the next Calcite
release 1.31.
If so, do you think it can be resolved in 1-2 weeks ?
Our goal is to create an RC mid-June.
Thanks.
> ClassCastException in checkRollUp with DOT operator
> ---
>
> Key: CALCITE-5157
> URL: https://issues.apache.org/jira/browse/CALCITE-5157
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.30.0
>Reporter: Viliam Durina
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.31.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When a query contains nested field access and is using parentheses to
> disambiguate the identifier, the {{SqlValidatorImpl.checkRollup()}} method
> throws a {{ClassCastException}}, assuming that the input of the DOT operator
> is a {{SqlCall}}. I think this assumption is wrong, the DOT operator
> typically has {{SqlIdentifier}} as an input, probably also other classes.
> Here's the stack trace:
> {noformat}
> java.lang.ClassCastException: class org.apache.calcite.sql.SqlIdentifier
> cannot be cast to class org.apache.calcite.sql.SqlCall
> (org.apache.calcite.sql.SqlIdentifier and org.apache.calcite.sql.SqlCall are
> in unnamed module of loader 'app')
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.checkRollUp(SqlValidatorImpl.java:3730)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.checkRollUp(SqlValidatorImpl.java:3749)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.checkRollUpInSelectList(SqlValidatorImpl.java:3673)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateSelect(SqlValidatorImpl.java:3661)
> at
> org.apache.calcite.sql.validate.SelectNamespace.validateImpl(SelectNamespace.java:64)
> at
> org.apache.calcite.sql.validate.AbstractNamespace.validate(AbstractNamespace.java:89)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateNamespace(SqlValidatorImpl.java:1100)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateQuery(SqlValidatorImpl.java:1071)
> at org.apache.calcite.sql.SqlSelect.validate(SqlSelect.java:247)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateScopedExpression(SqlValidatorImpl.java:1046)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validate(SqlValidatorImpl.java:752)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertQuery(SqlToRelConverter.java:587)
> at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:257)
> at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:220)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl.prepare2_(CalcitePrepareImpl.java:648)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl.prepare_(CalcitePrepareImpl.java:514)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl.prepareSql(CalcitePrepareImpl.java:484)
> at
> org.apache.calcite.jdbc.CalciteConnectionImpl.parseQuery(CalciteConnectionImpl.java:234)
> at
> org.apache.calcite.jdbc.CalciteMetaImpl.prepareAndExecute(CalciteMetaImpl.java:623)
> at
> org.apache.calcite.avatica.AvaticaConnection.prepareAndExecuteInternal(AvaticaConnection.java:677)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:156)
> ... 67 more
> {noformat}
> The problem can be reproduced by modifying the
> {{ReflectiveSchemaTest.testSelectWithFieldAccessOnFirstLevelRecordType()}}
> test and putting {{au."birthPlace"}} into parentheses:
> {code:sql}
> select (au."birthPlace")."city" as city from ...
> {code}
> Putting identifiers into parentheses is common to disambiguate field access
> from identifier qualification. For example, if the {{au}} prefix is removed
> from the query in the {{testSelectWithFieldAccessOnFirstLevelRecordType}}
> test, it will fail with {{{}Table 'birthPlace' not found{}}}. But if we put
> {{\"birthPlace\"}} into parentheses, then it is correctly recognized as a
> column of the {{authors}} table.
> I'm not sure about the correct fix to this issue which would not break the
> roll-up functionality, perhaps its author [~zhumayun] can help reviewing the
> PR or suggesting another fix. I'll soon create a PR with a proposed fix.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (CALCITE-5167) SqlOperator#rewriteCall does not give accurate validation error
[
https://issues.apache.org/jira/browse/CALCITE-5167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17549396#comment-17549396
]
Andrei Sereda commented on CALCITE-5167:
Hello,
Please let me know if you want this issue to be included in the next Calcite
release 1.31.
If so, do you think it can be resolved in 1-2 weeks ?
Our goal is to create an RC mid-June.
Thanks.
> SqlOperator#rewriteCall does not give accurate validation error
> ---
>
> Key: CALCITE-5167
> URL: https://issues.apache.org/jira/browse/CALCITE-5167
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.30.0
>Reporter: Benchao Li
>Assignee: Benchao Li
>Priority: Major
> Fix For: 1.31.0
>
>
> As discussed in CALCITE-5118, {{SqlOperator#rewriteCall}} is done before
> validation, which is hard to give accurate validation messages. We prefer to
> use {{SqlRexConvertlet}} to do this work, hence we can make the validation
> error more accurate, and does not give more burden to the optimization phase.
> We should deprecate {{{}SqlOperator#rewriteCall{}}}, and move these rewriting
> logic to {{SqlRexConvertlet.}}
> Currently, {{{}SqlCoalesceFunction{}}}, {{{}SqlDatePartFunction{}}},
> {{{}SqlJdbcFunctionCall{}}}, {{{}SqlNewOperator{}}},
> {{{}SqlNullifFunction{}}}, {{SqlProcedureCallOperator}} used this mechanism,
> we should handle these functions in this issue.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (CALCITE-5177) Query loses hint after decorrelation
[
https://issues.apache.org/jira/browse/CALCITE-5177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17549395#comment-17549395
]
Andrei Sereda commented on CALCITE-5177:
Hello,
Please let me know if you want this issue to be included in the next Calcite
release 1.31.
If so, do you think it can be resolved in 1-2 weeks ?
Our goal is to create an RC mid-June.
Thanks.
> Query loses hint after decorrelation
>
>
> Key: CALCITE-5177
> URL: https://issues.apache.org/jira/browse/CALCITE-5177
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Ruben Q L
>Priority: Blocker
> Fix For: 1.31.0
>
>
> This seems to be a regression caused by CALCITE-5107, which enlarged the list
> of hintable RelNodes by making Filter, SetOp, Sort, Window, Values hintable.
> However, it seems that this patch "missed" some Calcite preprocessing
> elements that can change a plan, and therefore require a manual / ad-hoc
> treatment of hints to avoid losing them in their processing, e.g.
> RelDecorrelator.
> In my specific example, let's have this query:
> {code:sql}
> SELECT /*+ MY_HINT_FOR_JOIN */ c.c_custkey, , c.c_name FROM customer c
> WHERE NOT EXISTS (
> SELECT 1 FROM orders o WHERE o.o_custkey = c.c_custkey AND o.o_orderstatus
> <> 'abc'
> ) ORDER BY c.c_custkey
> {code}
> Before CALCITE-5107, when the query was parsed, a logical plan was created,
> my hint was attached to a LogicalProject. The plan contained a
> LogicalCorrelate (to implement the NOT EXISTS). The plan was then
> decorrelated with RelDecorrelator, and as a result, we obtained a new plan
> with a LogicalJoin (instead of correlate), where the hint had been propagated
> from the projection until the join. Everything is fine.
> After CALCITE-5107, when the query was parsed, now we obtain the same logical
> plan, but now the hint is attached to the LogicalSort (not to the
> LogicalProject). When the decorrelator is executed, the plan is transformed
> (to have LogicalJoin), but {*}the hint is lost{*}, it is not in the new
> plan's sort (or project, or join, it's nowhere).
> Running the debugger, it seems the problem is inside
> RelDecorrelator#decorrelateQuery:
> {code:java}
> ...
> if (!decorrelator.cm.mapCorToCorRel.isEmpty()) {
> newRootRel = decorrelator.decorrelate(newRootRel); // <-- HINT LOST HERE!
> }
> // NOTHING GETS PROPAGATED BECAUSE THE HINT WAS LOST!
> newRootRel = RelOptUtil.propagateRelHints(newRootRel, true);
>
> return newRootRel;
> {code}
> The root cause seems to be that, inside [RelDecorrelator's
> code|https://github.com/apache/calcite/blob/main/core/src/main/java/org/apache/calcite/sql2rel/RelDecorrelator.java],
> there are only a few places where hints are copied from the "old" RelNode to
> the newly created RelNode: 3 calls to RelOptUtil#copyRelHints
> ([here|https://github.com/apache/calcite/blob/63a15128a332af7a641b26a3224392960882170a/core/src/main/java/org/apache/calcite/sql2rel/RelDecorrelator.java#L589],
>
> [here|https://github.com/apache/calcite/blob/63a15128a332af7a641b26a3224392960882170a/core/src/main/java/org/apache/calcite/sql2rel/RelDecorrelator.java#L685],
> and
> [here|https://github.com/apache/calcite/blob/63a15128a332af7a641b26a3224392960882170a/core/src/main/java/org/apache/calcite/sql2rel/RelDecorrelator.java#L796]),
> only for projections and aggregates; + RelBuilder#hints [to copy them for
> joins|https://github.com/apache/calcite/blob/63a15128a332af7a641b26a3224392960882170a/core/src/main/java/org/apache/calcite/sql2rel/RelDecorrelator.java#L1308].
> To sum up, it seems RelDecorrelator only cared to copy hints for the
> "traditional hintables", so probably something like that is missing for sorts
> (and other newly hintable RelNodes added by CALCITE-5107).
> Apart from RelDecorrelator, other classes that might suffer from a similar
> problem are:
> -
> [RelFieldTrimmer|https://github.com/apache/calcite/blob/main/core/src/main/java/org/apache/calcite/sql2rel/RelFieldTrimmer.java]:
> which currently only propagates hints for projections and aggregates
> ([here|https://github.com/apache/calcite/blob/63a15128a332af7a641b26a3224392960882170a/core/src/main/java/org/apache/calcite/sql2rel/RelFieldTrimmer.java#L535],
>
> [here|https://github.com/apache/calcite/blob/63a15128a332af7a641b26a3224392960882170a/core/src/main/java/org/apache/calcite/sql2rel/RelFieldTrimmer.java#L574],
> and
> [here|https://github.com/apache/calcite/blob/63a15128a332af7a641b26a3224392960882170a/core/src/main/java/org/apache/calcite/sql2rel/RelFieldTrimmer.java#L1115]);
> and copies hints for joins
> ([here|https://github.com/apache/calcite/blob/63a15128a332af7a641b26a3224392960882170a/core/src/main/java/org/apache/calcite/sql2rel/RelFieldTrimmer.java#L909]).
> -
>
[jira] [Comment Edited] (CALCITE-4965) IS NOT NULL failed in Elasticsearch Adapter
[
https://issues.apache.org/jira/browse/CALCITE-4965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17477383#comment-17477383
]
Andrei Sereda edited comment on CALCITE-4965 at 1/17/22, 7:48 PM:
--
Fixed in
[ad5cbdbe27e1|https://github.com/apache/calcite/commit/ad5cbdbe27e18a779372785c1af3a3baa80c52a6]
was (Author: asereda):
Fixed in
[ad5cbdbe27e1|[https://github.com/apache/calcite/commit/ad5cbdbe27e18a779372785c1af3a3baa80c52a6]]
> IS NOT NULL failed in Elasticsearch Adapter
> ---
>
> Key: CALCITE-4965
> URL: https://issues.apache.org/jira/browse/CALCITE-4965
> Project: Calcite
> Issue Type: Bug
> Components: elasticsearch-adapter
>Affects Versions: 1.28.0
>Reporter: ZheHu
>Assignee: ZheHu
>Priority: Major
> Labels: pull-request-available
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Running the following test in BooleanLogicTest failed:
> {code:java}
> @Test void testIsNotNull() {
> CalciteAssert.that()
> .with(newConnectionFactory())
> // "where num is not null" also failed
> .query("select * from view where num > 42 or num < 42 or num = 42")
> .returns("");
> }
> {code}
> Exception message:
> {code:java}
> PredicateAnalyzer$PredicateAnalyzerException: Unsupported expression:
> [org.apache.calcite.adapter.elasticsearch.PredicateAnalyzer$CastExpression@26545ea]
> {code}
> The filter condition in query "num > 42 or num < 42 or num = 42" is optimized
> to "IS NOT NULL(CAST(ITEM($0, 'int')):INTEGER)". However, converting the
> optimized RexNode to Elasticsearch query filter failed.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (CALCITE-4965) IS NOT NULL failed in Elasticsearch Adapter
[
https://issues.apache.org/jira/browse/CALCITE-4965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17477383#comment-17477383
]
Andrei Sereda commented on CALCITE-4965:
Fixed in
[ad5cbdbe27e1|[https://github.com/apache/calcite/commit/ad5cbdbe27e18a779372785c1af3a3baa80c52a6]]
> IS NOT NULL failed in Elasticsearch Adapter
> ---
>
> Key: CALCITE-4965
> URL: https://issues.apache.org/jira/browse/CALCITE-4965
> Project: Calcite
> Issue Type: Bug
> Components: elasticsearch-adapter
>Affects Versions: 1.28.0
>Reporter: ZheHu
>Assignee: ZheHu
>Priority: Major
> Labels: pull-request-available
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Running the following test in BooleanLogicTest failed:
> {code:java}
> @Test void testIsNotNull() {
> CalciteAssert.that()
> .with(newConnectionFactory())
> // "where num is not null" also failed
> .query("select * from view where num > 42 or num < 42 or num = 42")
> .returns("");
> }
> {code}
> Exception message:
> {code:java}
> PredicateAnalyzer$PredicateAnalyzerException: Unsupported expression:
> [org.apache.calcite.adapter.elasticsearch.PredicateAnalyzer$CastExpression@26545ea]
> {code}
> The filter condition in query "num > 42 or num < 42 or num = 42" is optimized
> to "IS NOT NULL(CAST(ITEM($0, 'int')):INTEGER)". However, converting the
> optimized RexNode to Elasticsearch query filter failed.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (CALCITE-4292) Wrong results in ElasticSearch when query contains NOT EQUAL
[
https://issues.apache.org/jira/browse/CALCITE-4292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17424558#comment-17424558
]
Andrei Sereda commented on CALCITE-4292:
I agree with Julian's and Stamatis's position. Same query / same data should
return identical results independent of the adapter.
See [Three-Valued-Logic|https://modern-sql.com/concept/three-valued-logic] for
more details.
> Wrong results in ElasticSearch when query contains NOT EQUAL
>
>
> Key: CALCITE-4292
> URL: https://issues.apache.org/jira/browse/CALCITE-4292
> Project: Calcite
> Issue Type: Bug
> Components: elasticsearch-adapter
>Reporter: Shlok Srivastava
>Assignee: Bill Neil
>Priority: Major
> Labels: ElasticSearch, NotEquals, QueryBuilder, calcite,
> pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Currently elasticsearch adapters ignore records which do not have the field
> specified in NotEqual clause, which is ideally included by elasticsearch.
> *Query:*
> {code:java}
> SELECT* from zips WHERE name <> "NMAX"{code}
> The elasticsearch query formed for above is this :
> {code:java}
> {
> "query": {
> "constant_score": {
> "filter": {
> "bool": {
> "must": {
> "exists": {
> "field": "Name"
> }
> },
> "must_not": {
> "term": {
> "Name": "NMQAX"
> }
> }
> }
> }
> }
> }
> }
> {code}
> *Problem* : The above query ignores document which do not have _Name_ field
> which is ideally included by elasticsearch but ignored due to must exists
> condition.
> *Data:*
> {noformat}
> { "_id" : "01701", "name" : "NMAX", "loc" : [ -71.4254860001, 42.300665
> ], "pop" : 65046, "state" : "MA" }
> { "_id" : "02154", "name" : "NORTH WALTHAM", "loc" : [ -71.236497, 42.382492
> ], "pop" : 57871, "state" : "MA" }
> { "_id" : "02401 , "loc" : [ -71.034347, 42.081571 ], "pop" : 59498,
> "state" : "MA" }
> {noformat}
>
>
> *Expected result:*
> {noformat}
> { "_id" : "02154", "name" : "NORTH WALTHAM", "loc" : [ -71.236497, 42.382492
> ], "pop" : 57871, "state" : "MA" }
> { "_id" : "02401", "loc" : [ -71.034347, 42.081571 ], "pop" : 59498,
> "state" : "MA" }
> {noformat}
>
> *Current Result:*
> {noformat}
> { "_id" : "02154", "name" : "NORTH WALTHAM", "loc" : [ -71.236497, 42.382492
> ], "pop" : 57871, "state" : "MA" }
> {noformat}
> RelNode for same -
> {code:java}
> relB.not(relB.equals(relb.literal("Name"),relb.literal"NMQAX")){code}
>
> *Solution* : Remove the exists condition from Not equals Query Expression.
> Elasticsearch doesn't put this condition therefore keeping queries in sync.
> [Code|https://github.com/apache/calcite/blob/1050b36cafbb0c487b7a2ade3efd12850609717e/elasticsearch/src/main/java/org/apache/calcite/adapter/elasticsearch/PredicateAnalyzer.java#L782]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-4787) Evaluate use of Immutables instead of ImmutableBeans
[
https://issues.apache.org/jira/browse/CALCITE-4787?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17418778#comment-17418778
]
Andrei Sereda commented on CALCITE-4787:
{quote}
My last concern is compatibility. If a dependent project is using a different
version of Immutables, what will be the impact?
{quote}
There is no runtime component in Immutables. However, one potential issue
might occur when someone tries to build calcite from the source. For example,
depending on current compile classpath immutables might be using guava
collections instead of JDK and this will affect the use of nulls.
> Evaluate use of Immutables instead of ImmutableBeans
>
>
> Key: CALCITE-4787
> URL: https://issues.apache.org/jira/browse/CALCITE-4787
> Project: Calcite
> Issue Type: Improvement
>Reporter: Jacques Nadeau
>Assignee: Jacques Nadeau
>Priority: Major
> Labels: pull-request-available
> Time Spent: 3.5h
> Remaining Estimate: 0h
>
> In the creation of CALCITE-3328, [Immutables|https://immutables.github.io/]
> was discussed as an alternative to a custom implementation. This ticket is to
> evaluate the impact to the codebase of changing. Ideally, introduction of
> immutables would both add flexibility and reduce the amount of code
> associated with these classes.
> Immutables works via annotation processor which means that it is should be
> relatively seamless to build systems and IDEs.
> The switch would also make it easier to work with these objects types in the
> context of aot compilation tools like GraalVM.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (CALCITE-4165) RelToSqlConverter fails on literal, untyped nulls
[
https://issues.apache.org/jira/browse/CALCITE-4165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrei Sereda closed CALCITE-4165.
--
> RelToSqlConverter fails on literal, untyped nulls
> -
>
> Key: CALCITE-4165
> URL: https://issues.apache.org/jira/browse/CALCITE-4165
> Project: Calcite
> Issue Type: Bug
>Reporter: Steven Talbot
>Assignee: Julian Hyde
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.25.0
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> RelToSqlConverter fails on literal, untyped nulls. Here is a simple test in
> {{RelToSqlConverterTest}}:
>
> {code:java}
> @Test void testUntypedNull() {
> final String sql = "SELECT NULL FROM \"warehouse_class\"";
> final String expected = "SELECT NULL FROM \"warehouse_class\"";
> sql(sql).ok(expected);
> }{code}
> The expected SQL is probably not exactly the right expected SQL, but the test
> explodes on 1.24 so it doesn't matter for our purposes. Here is the top of
> the stack trace (on current master
> [ad53962f|https://github.com/apache/calcite/commit/ad53962f76a48e2627da1c155eb5f005150d3dcb])
> :
> {noformat}
> Unsupported type when convertTypeToSpec: NULLUnsupported type when
> convertTypeToSpec: NULL
> java.lang.UnsupportedOperationException: Unsupported type when
> convertTypeToSpec: NULL at
> org.apache.calcite.sql.type.SqlTypeUtil.convertTypeToSpec(SqlTypeUtil.java:1027)
> at org.apache.calcite.sql.SqlDialect.getCastSpec(SqlDialect.java:778)
> at
> org.apache.calcite.rel.rel2sql.RelToSqlConverter.castNullType(RelToSqlConverter.java:361){noformat}
>
> Seems to be an unintended side-effect of the fix for CALCITE-4066,
> [8db7c9d6|https://github.com/apache/calcite/commit/8db7c9d6ddc317b5fee8705e136c0794c44b463a#diff-fe53d9c0364e000f0aeafa786587e815R1079].
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (CALCITE-4136) ReduceExpressionsRule.FILTER_INSTANCE cannot be initialized by some JVM
[
https://issues.apache.org/jira/browse/CALCITE-4136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrei Sereda closed CALCITE-4136.
--
> ReduceExpressionsRule.FILTER_INSTANCE cannot be initialized by some JVM
> ---
>
> Key: CALCITE-4136
> URL: https://issues.apache.org/jira/browse/CALCITE-4136
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Stamatis Zampetakis
>Priority: Major
> Fix For: 1.25.0
>
> Attachments: DeprecatedRulesAreNull.png
>
>
> In certain JVM implementations the field cannot be initialized leading to
> {{NullPointerException}} when using the rule.
> Few stacktraces are given below:
> {noformat}
> Caused by: java.lang.NullPointerException: at index 0
> at
> com.onwbp.com.google.common.collect.ObjectArrays.checkElementNotNull(ObjectArrays.java:239)
> at
> com.onwbp.com.google.common.collect.ObjectArrays.checkElementsNotNull(ObjectArrays.java:230)
> at
> com.onwbp.com.google.common.collect.ObjectArrays.checkElementsNotNull(ObjectArrays.java:225)
> at
> com.onwbp.com.google.common.collect.ImmutableList.construct(ImmutableList.java:281)
> at
> com.onwbp.com.google.common.collect.ImmutableList.copyOf(ImmutableList.java:239)
> at
> com.onwbp.com.google.common.collect.ImmutableList.copyOf(ImmutableList.java:209)
> at com.onwbp.org.apache.calcite.tools.RuleSets.ofList(RuleSets.java:41)
> {noformat}
> {noformat}
> java.lang.NullPointerException
> at
> org.apache.calcite.plan.AbstractRelOptPlanner.addRule(AbstractRelOptPlanner.java:147)
> at
> org.apache.calcite.plan.volcano.VolcanoPlanner.addRule(VolcanoPlanner.java:416)
> at herddb.sql.CalcitePlanner.runPlanner(CalcitePlanner.java:576)
> at herddb.sql.CalcitePlanner.translate(CalcitePlanner.java:331)
> at herddb.core.TestUtils.scan(TestUtils.java:70)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (CALCITE-4133) Shouldn't trim fields when it's under Union
[
https://issues.apache.org/jira/browse/CALCITE-4133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrei Sereda closed CALCITE-4133.
--
> Shouldn't trim fields when it's under Union
> ---
>
> Key: CALCITE-4133
> URL: https://issues.apache.org/jira/browse/CALCITE-4133
> Project: Calcite
> Issue Type: Bug
>Reporter: Jiatao Tao
>Assignee: Jiatao Tao
>Priority: Major
> Fix For: 1.25.0
>
>
> Consider case like this:
>
> {code:java}
> String sql =
> "select \n"
> + " gender, \n"
> + " count(*) \n"
> + "from \n"
> + "(\n"
> + " (select gender, empno from EMPS) \n"
> + " union \n"
> + " (select gender, empno from EMPS)\n"
> + ") group by gender";
> {code}
> And the plan is:
>
> {code:java}
> EnumerableAggregate(group=[{0}], EXPR$1=[COUNT()])
> EnumerableUnion(all=[false])
> EnumerableProject(GENDER=[$3])
> EnumerableTableScan(table=[[SALES, EMPS]])
> EnumerableProject(GENDER=[$3])
> EnumerableTableScan(table=[[SALES, EMPS]])
> {code}
>
> The col empno has been trimmed, this changes the semantics cuz union will
> distinct values.
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-3399) Field-pruning for set operators (except UNION ALL) changes query semantics
[
https://issues.apache.org/jira/browse/CALCITE-3399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrei Sereda updated CALCITE-3399:
---
Fix Version/s: (was: 1.25.0)
> Field-pruning for set operators (except UNION ALL) changes query semantics
> --
>
> Key: CALCITE-3399
> URL: https://issues.apache.org/jira/browse/CALCITE-3399
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Jin Xing
>Assignee: Jin Xing
>Priority: Major
> Labels: pull-request-available
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
> *RelFieldTrimmer#trimFields* provides functionality to trim fields for
> *UNION, UNION ALL, INTERSECT, INTERSECT ALL, EXCEPT, EXCEPT ALL;*
> But *UNION ALL, INTERSECT, INTERSECT ALL, EXCEPT, EXCEPT ALL* works by
> checking duplication. Column pruning on inputs of *SetOp* might lead to
> different semantics.
>
> Take below example for illustration
> {code:java}
> emp0:
> name, deptno
> "A", 0
> "B", 1
> emp1:
> name, deptno
> "C", 0
> "D", 2
> select deptno from
> (select name, deptno from emp0
> intersect
> select name, deptno from emp1)
> {code}
> Run above Sql on emp0 and emp1, result is not empty if trim fields on inputs
> of INTERSECT, but result is empty if DO NOT trim fields on inputs of INTERSECT
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-1581) UDTF like in hive
[
https://issues.apache.org/jira/browse/CALCITE-1581?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrei Sereda updated CALCITE-1581:
---
Fix Version/s: (was: 1.25.0)
> UDTF like in hive
> -
>
> Key: CALCITE-1581
> URL: https://issues.apache.org/jira/browse/CALCITE-1581
> Project: Calcite
> Issue Type: New Feature
>Reporter: Xiaoyong Deng
>Assignee: Chunwei Lei
>Priority: Major
> Labels: pull-request-available, udtf
> Time Spent: 15h 50m
> Remaining Estimate: 0h
>
> Support one row in and multi-column/multi-row out(one-to-many mapping), just
> like udtf in hive.
> The query would like this:
> {code}
> select
> func(c0, c1) as (f0, f1, f2)
> from table_name;
> {code}
> c0 and c1 are 'table_name' columns. f0, f1 and f2 are new generated columns.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-4130) Aggregation function in order by clause will throw exception in elasticsearch adapter
[
https://issues.apache.org/jira/browse/CALCITE-4130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrei Sereda updated CALCITE-4130:
---
Fix Version/s: (was: 1.25.0)
> Aggregation function in order by clause will throw exception in elasticsearch
> adapter
> -
>
> Key: CALCITE-4130
> URL: https://issues.apache.org/jira/browse/CALCITE-4130
> Project: Calcite
> Issue Type: Bug
> Components: elasticsearch-adapter
>Affects Versions: 1.25.0
>Reporter: yuqi
>Priority: Major
> Labels: pull-request-available
> Time Spent: 1h
> Remaining Estimate: 0h
>
> For sql like
> {code:java}
> select id, count(id) from test group by id order by count(id)
> {code}
> When execute query, `ElasticsearchTable#aggregate` will throw exception like
> {code:java}
> Caused by: java.lang.IllegalArgumentException: Field EXPR$1 not defined for
> aggs
> {code}
> Reproduce:
> {code:java}
> Add test as below in AggregationTest
> CalciteAssert.that()
> .with(newConnectionFactory())
> .query("select cat2, count(cat2) from view group by cat2 order by
> count(cat2)")
> .returnsUnordered("cat2=g; EXPR$1=2",
> "cat2=h; EXPR$1=1");
> {code}
> result:
> {code:java}
> Caused by: java.lang.IllegalArgumentException: Field EXPR$1 not defined for
> aggs
> at
> org.apache.calcite.adapter.elasticsearch.ElasticsearchMapping.missingValueFor(ElasticsearchMapping.java:84)
> at
> org.apache.calcite.adapter.elasticsearch.ElasticsearchTable.aggregate(ElasticsearchTable.java:235)
> at
> org.apache.calcite.adapter.elasticsearch.ElasticsearchTable.find(ElasticsearchTable.java:130)
> at
> org.apache.calcite.adapter.elasticsearch.ElasticsearchTable.access$000(ElasticsearchTable.java:70)
> at
> org.apache.calcite.adapter.elasticsearch.ElasticsearchTable$ElasticsearchQueryable.find(ElasticsearchTable.java:411)
> at Baz.bind(Unknown Source)
> at
> org.apache.calcite.jdbc.CalcitePrepare$CalciteSignature.enumerable(CalcitePrepare.java:355)
> at
> org.apache.calcite.jdbc.CalciteConnectionImpl.enumerable(CalciteConnectionImpl.java:315)
> at
> org.apache.calcite.jdbc.CalciteMetaImpl._createIterable(CalciteMetaImpl.java:507)
> at
> org.apache.calcite.jdbc.CalciteMetaImpl.createIterable(CalciteMetaImpl.java:498)
> at
> org.apache.calcite.avatica.AvaticaResultSet.execute(AvaticaResultSet.java:182)
> at
> org.apache.calcite.jdbc.CalciteResultSet.execute(CalciteResultSet.java:64)
> at
> org.apache.calcite.jdbc.CalciteResultSet.execute(CalciteResultSet.java:43)
> at
> org.apache.calcite.avatica.AvaticaConnection$1.execute(AvaticaConnection.java:667)
> at
> org.apache.calcite.jdbc.CalciteMetaImpl.prepareAndExecute(CalciteMetaImpl.java:567)
> at
> org.apache.calcite.avatica.AvaticaConnection.prepareAndExecuteInternal(AvaticaConnection.java:675)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:156)
> ... 68 more
> {code}
> till now, this problem can only be found in elasticsearch adapter
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (CALCITE-4169) Release Calcite 1.25.0
[ https://issues.apache.org/jira/browse/CALCITE-4169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Sereda resolved CALCITE-4169. Resolution: Fixed Fixed in [68b02dfd4af|https://github.com/apache/calcite/commit/68b02dfd4af15bc94a91a0cd2a30655d04439555] > Release Calcite 1.25.0 > -- > > Key: CALCITE-4169 > URL: https://issues.apache.org/jira/browse/CALCITE-4169 > Project: Calcite > Issue Type: Task >Reporter: Andrei Sereda >Assignee: Andrei Sereda >Priority: Major > Fix For: 1.25.0 > > > Created for tracking 1.25.0 release -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (CALCITE-4169) Release Calcite 1.25.0
[ https://issues.apache.org/jira/browse/CALCITE-4169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Sereda closed CALCITE-4169. -- > Release Calcite 1.25.0 > -- > > Key: CALCITE-4169 > URL: https://issues.apache.org/jira/browse/CALCITE-4169 > Project: Calcite > Issue Type: Task >Reporter: Andrei Sereda >Assignee: Andrei Sereda >Priority: Major > Fix For: 1.25.0 > > > Created for tracking 1.25.0 release -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (CALCITE-2569) UDFs that are table functions must implement SqlTableFunction and have CURSOR as their return type
[ https://issues.apache.org/jira/browse/CALCITE-2569?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Sereda closed CALCITE-2569. -- Released as part of 1.25 ([68b02dfd4af15bc|https://github.com/apache/calcite/commit/68b02dfd4af15bc94a91a0cd2a30655d04439555]) > UDFs that are table functions must implement SqlTableFunction and have CURSOR > as their return type > -- > > Key: CALCITE-2569 > URL: https://issues.apache.org/jira/browse/CALCITE-2569 > Project: Calcite > Issue Type: Bug >Reporter: Julian Hyde >Assignee: Julian Hyde >Priority: Major > Fix For: 1.25.0 > > > UDFs that are table functions must implement SqlTableFunction and have CURSOR > as their return type, > Validate that table functions are not used in contexts that require scalar > functions, such as the SELECT clause. > Change operand type ANY to mean 'scalar expression of any type (but not a > cursor)', and add operand type IGNORE to mean skip validation - for an > operand that is not an expression. TABLE is one of the few operators that > accepts a CURSOR operand. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (CALCITE-4134) Interval expressions
[
https://issues.apache.org/jira/browse/CALCITE-4134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrei Sereda closed CALCITE-4134.
--
Released as part of 1.25
([68b02dfd4af15bc|https://github.com/apache/calcite/commit/68b02dfd4af15bc94a91a0cd2a30655d04439555])
> Interval expressions
>
>
> Key: CALCITE-4134
> URL: https://issues.apache.org/jira/browse/CALCITE-4134
> Project: Calcite
> Issue Type: Sub-task
>Affects Versions: 1.23.0
>Reporter: Julian Hyde
>Assignee: Julian Hyde
>Priority: Major
> Fix For: 1.25.0
>
>
> Support interval expressions.
> Standard SQL has only interval literals (e.g. {{INTERVAL '1' HOUR}},
> {{INTERVAL -'1:2' HOUR TO MINUTE}}). Note that the 'value' part is a
> character literal and may contain formatting characters like ':'.
> Interval expressions are a SQL extension present in
> [MySQL|https://dev.mysql.com/doc/refman/8.0/en/expressions.html#temporal-intervals]
> and
> [BigQuery|https://cloud.google.com/bigquery/docs/reference/standard-sql/datetime_functions#datetime_add].
> We support the syntax {{INTERVAL numericExpression timeUnit}}:
> * the 'value' part is a numeric expression;
> * {{timeUnit}} is a time unit (such as {{HOUR}}), not a time unit range (such
> as {{HOUR TO MINUTE}});
> * {{timeUnit}} may have precision, e.g. {{HOUR(2)}};
> * {{timeUnit}} may be plural, e.g. {{HOURS}}, if
> {{SqlConformance.allowPluralTimeUnits}} (see CALCITE-3383);
> * numeric literals and identifiers do not require parentheses, but other
> expressions require parentheses.
> Examples:
> * {{SELECT INTERVAL empno HOUR FROM Emp}}
> * {{SELECT INTERVAL (empno * 2) MINUTE FROM Emp}}
> * {{INTERVAL -3 YEAR}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (CALCITE-4137) Checkstyle should ensure that every class has a Javadoc comment
[
https://issues.apache.org/jira/browse/CALCITE-4137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrei Sereda closed CALCITE-4137.
--
Released as part of 1.25
([68b02dfd4af15bc|https://github.com/apache/calcite/commit/68b02dfd4af15bc94a91a0cd2a30655d04439555])
> Checkstyle should ensure that every class has a Javadoc comment
> ---
>
> Key: CALCITE-4137
> URL: https://issues.apache.org/jira/browse/CALCITE-4137
> Project: Calcite
> Issue Type: Bug
>Reporter: Julian Hyde
>Assignee: Julian Hyde
>Priority: Major
> Fix For: 1.25.0
>
>
> Checkstyle should ensure that every class, interface, enum, package has a
> Javadoc comment. And that javadoc types (e.g {{@param}} and {{@return}}) are
> not empty.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (CALCITE-4079) Dialect constants in SqlDialect can cause class initialization deadlock
[
https://issues.apache.org/jira/browse/CALCITE-4079?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrei Sereda closed CALCITE-4079.
--
Released as part of 1.25
([68b02dfd4af15bc|https://github.com/apache/calcite/commit/68b02dfd4af15bc94a91a0cd2a30655d04439555])
> Dialect constants in SqlDialect can cause class initialization deadlock
> ---
>
> Key: CALCITE-4079
> URL: https://issues.apache.org/jira/browse/CALCITE-4079
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.23.0
>Reporter: TANG Wen-hui
>Assignee: Julian Hyde
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.25.0
>
> Attachments: CALCITE-4079.01.patch,
> image-2020-07-01-19-27-25-354.png, image-2020-07-01-19-51-32-397.png
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> {code:java}
> /** @deprecated Use {@link AnsiSqlDialect#DEFAULT} instead. */
> @Deprecated // to be removed before 2.0
> public static final SqlDialect DUMMY =
> AnsiSqlDialect.DEFAULT;
> /** @deprecated Use {@link CalciteSqlDialect#DEFAULT} instead. */
> @Deprecated // to be removed before 2.0
> public static final SqlDialect CALCITE =
> CalciteSqlDialect.DEFAULT;{code}
> SqlDialect#DUMMY and SqlDialect#CALCITE are marked deprecated and have not be
> used in any places.
> It would be better to remove them to avoid class initialization deadlock.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (CALCITE-4081) Round-tripping a DECIMAL literal through Planner -> RelToSqlConverter -> Planner throws validation error
[
https://issues.apache.org/jira/browse/CALCITE-4081?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrei Sereda closed CALCITE-4081.
--
Released as part of 1.25
([68b02dfd4af15bc|https://github.com/apache/calcite/commit/68b02dfd4af15bc94a91a0cd2a30655d04439555])
> Round-tripping a DECIMAL literal through Planner -> RelToSqlConverter ->
> Planner throws validation error
>
>
> Key: CALCITE-4081
> URL: https://issues.apache.org/jira/browse/CALCITE-4081
> Project: Calcite
> Issue Type: Bug
>Reporter: Steven Talbot
>Assignee: Chunwei Lei
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.25.0
>
> Time Spent: 2h 20m
> Remaining Estimate: 0h
>
> Take the following SQL:
> SELECT CAST('.11' AS DECIMAL(38,6)) AS
> "num"
> And, in the default Calcite SQL dialect with all defaults, send it through
> Planner parse -> valiate -> rel to get a RelNode. The RelNode will have a
> Project with the "111.1" literal in there as a RexLiteral
> with Decimal type.
>
> The use RelToSqlConverter to convert that RelNode back to SQL. The SQL now
> looks like
> SELECT .11 AS "num"
>
> If you attempt to parse and validate that SQL, you get "Numeric literal
> '.11' out of range" throw by
> SqlValidatorImpl.validateLiteral()
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (CALCITE-4129) Support equality check for whole rel plan tree
[
https://issues.apache.org/jira/browse/CALCITE-4129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrei Sereda closed CALCITE-4129.
--
Released as part of 1.25
([68b02dfd4af15bc|https://github.com/apache/calcite/commit/68b02dfd4af15bc94a91a0cd2a30655d04439555])
> Support equality check for whole rel plan tree
> --
>
> Key: CALCITE-4129
> URL: https://issues.apache.org/jira/browse/CALCITE-4129
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: Haisheng Yuan
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.25.0
>
> Time Spent: 2h
> Remaining Estimate: 0h
>
> Currently the only way to check rel node tree deep equality is transforming
> into String by {{RelOptUtil.toString(rel)}} with
> {{SqlExplainLevel.EXPPLAN_ATTRIBUTES}}, which is inefficient. One example is
> RexSubQuery. It has to do it this way, because the rel being reference by
> RexSubQuery is possibly not yet registered to VolcanoPlanner, and the digest
> {{equals}} checks the input RelNode by identity (not content). That is OK for
> RelSubset and HepRelVertex, if the RelNode is already registered in planner,
> but not for plain RelNode that is outside of planner. Due to this, we have to
> implement another set of deep equals logic in our system.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (CALCITE-4118) RexSimplify might remove CAST from RexNode incorrectly
[
https://issues.apache.org/jira/browse/CALCITE-4118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrei Sereda closed CALCITE-4118.
--
Released as part of 1.25
([68b02dfd4af15bc|https://github.com/apache/calcite/commit/68b02dfd4af15bc94a91a0cd2a30655d04439555])
> RexSimplify might remove CAST from RexNode incorrectly
> --
>
> Key: CALCITE-4118
> URL: https://issues.apache.org/jira/browse/CALCITE-4118
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.23.0, 1.24.0
>Reporter: Shuo Cheng
>Assignee: Chunwei Lei
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.25.0
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> {code:java}
> @Test void testCastError() {
> final String sql = "select cast(cast(count(distinct empno) as
> varchar(65536)) as varbinary)\n"
> + "from emp group by deptno";
> sql(sql).ok();
> }
> {code}
> Consider the above test case, we get the following plan after SqlToRel.
> {code:java}
> LogicalProject(EXPR$0=[CAST($1):VARBINARY NOT NULL])
> LogicalAggregate(group=[{0}], agg#0=[COUNT(DISTINCT $1)])
> LogicalProject(DEPTNO=[$7], EMPNO=[$0])
> LogicalTableScan(table=[[CATALOG, SALES, EMP]])
> {code}
> As it is shown, `cast(* as varchar)` is removed (by
> RexSimplify#SimplifyCast), which is obviously wrong, because BIGINT can not
> cast to VARBINARY.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (CALCITE-4128) Remove dependency of File adapter on Demo CSV adapter
[ https://issues.apache.org/jira/browse/CALCITE-4128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Sereda closed CALCITE-4128. -- Released as part of 1.25 ([68b02dfd4af15bc|https://github.com/apache/calcite/commit/68b02dfd4af15bc94a91a0cd2a30655d04439555]) > Remove dependency of File adapter on Demo CSV adapter > - > > Key: CALCITE-4128 > URL: https://issues.apache.org/jira/browse/CALCITE-4128 > Project: Calcite > Issue Type: Bug >Reporter: Julian Hyde >Assignee: Julian Hyde >Priority: Major > Fix For: 1.25.0 > > > Remove dependency of File adapter on Demo CSV adapter. > The dependency should be in the other direction. We want the File adapter to > have lots of capabilities, and the Demo CSV adapter to be easy to understand. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (CALCITE-2160) Spatial grid index, to accelerate polygon-to-polygon spatial joins
[
https://issues.apache.org/jira/browse/CALCITE-2160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrei Sereda closed CALCITE-2160.
--
Released as part of 1.25
([68b02dfd4af15bc|https://github.com/apache/calcite/commit/68b02dfd4af15bc94a91a0cd2a30655d04439555])
> Spatial grid index, to accelerate polygon-to-polygon spatial joins
> --
>
> Key: CALCITE-2160
> URL: https://issues.apache.org/jira/browse/CALCITE-2160
> Project: Calcite
> Issue Type: Bug
> Components: spatial
>Reporter: Julian Hyde
>Assignee: Julian Hyde
>Priority: Major
> Fix For: 1.25.0
>
>
> Recognize materialized views that convert a geometry into a grid of
> rectangles, and use such materialized views for point-to-polygon and
> polgyon-to-polygon joins.
> Implement the [ST_MakeGrid|http://www.h2gis.org/docs/dev/ST_MakeGrid] and
> [ST_MakeGridPoints|http://www.h2gis.org/docs/dev/ST_MakeGridPoints] functions.
> Add a test data set based upon western U.S. states and national parks. Given
> a materialized view
> {code}CREATE MATERIALIZED VIEW StateGrids (name, x, y, PRIMARY KEY (name)) AS
> SELECT s.name, ST_XMin(g.the_geom), ST_YMin(g.the_geom)
> FROM States AS s
> CROSS APPLY TABLE(ST_MakeGrid(s.geom, 1, 1)) AS g{code}
> and a similar materialized view ParkGrids on Parks, the query
> {code}SELECT p.name AS park, s.name AS state
> FROM Parks AS p
> JOIN States AS s ON ST_Overlaps(s.geom, p.geom)
> ORDER BY 1, 2{code}
> should return
> {noformat}
> Park State
> =
> Death Valley CA
> Death Valley NV
> Yellowstone ID
> Yellowstone MT
> Yellowstone WY
> Yosemite CA
> {noformat}
> and should semi-join to the {{StateGrids}} and {{ParkGrids}} tables to reduce
> the size of the input before applying St_Overlaps: {code}SELECT p.name AS
> park, s.name AS state
> FROM Parks AS p
> JOIN States AS s ON ST_Overlaps(s.geom, p.geom)
> WHERE (p.name, s.name) IN (
> SELECT DISTINCT pg.name, sg.name
> FROM ParkGrids AS pg
> JOIN StateGrids AS sg ON pg.id = sg.id){code}
> Note the semi-join, to remove duplicates in case a park and a state have
> several cells that overlap.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (CALCITE-4156) ReflectiveRelMetadataProvider constructor should throw an exception (instead of assertion) when called with an empty map
[ https://issues.apache.org/jira/browse/CALCITE-4156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Sereda closed CALCITE-4156. -- Released as part of 1.25 ([68b02dfd4af15bc|https://github.com/apache/calcite/commit/68b02dfd4af15bc94a91a0cd2a30655d04439555]) > ReflectiveRelMetadataProvider constructor should throw an exception (instead > of assertion) when called with an empty map > > > Key: CALCITE-4156 > URL: https://issues.apache.org/jira/browse/CALCITE-4156 > Project: Calcite > Issue Type: Task > Components: core >Reporter: Ruben Q L >Assignee: Ruben Q L >Priority: Minor > Labels: pull-request-available > Fix For: 1.25.0 > > Time Spent: 1h 50m > Remaining Estimate: 0h > > ReflectiveRelMetadataProvider's constructor verifies that it is not created > with an empty map, using an assertion. However, this is not the most reliable > way of verifying this situation, since assertions can be deactivated. In such > scenario, we could silently end up having an invalid > ReflectiveRelMetadataProvider, with no actual methods attached. > Also, since the map is private and has no getter, there is no way for a > caller module to verify this situation on its side. > For this reason, it is proposed a minor change: replace the assertion with an > IllegalArgumentException, which will work in 100% of the cases and will > always prevent constructing an invalid ReflectiveRelMetadataProvider. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (CALCITE-3957) AggregateMergeRule should merge SUM0 into COUNT even if GROUP BY is empty
[
https://issues.apache.org/jira/browse/CALCITE-3957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrei Sereda closed CALCITE-3957.
--
Released as part of 1.25
([68b02dfd4af15bc|https://github.com/apache/calcite/commit/68b02dfd4af15bc94a91a0cd2a30655d04439555])
> AggregateMergeRule should merge SUM0 into COUNT even if GROUP BY is empty
> -
>
> Key: CALCITE-3957
> URL: https://issues.apache.org/jira/browse/CALCITE-3957
> Project: Calcite
> Issue Type: Bug
>Reporter: Steven Talbot
>Assignee: Julian Hyde
>Priority: Major
> Fix For: 1.25.0
>
>
> {{AggregateMergeRule}} should merge {{SUM0}} into {{COUNT}} even if {{GROUP
> BY}} is empty.
> Basically, the comment in
> [AggregateMergeRule|https://github.com/apache/calcite/blame/571731b80a58eb095ebac7123285c375e7afff90/core/src/main/java/org/apache/calcite/rel/rules/AggregateMergeRule.java#L117-L120],
> bq. Should not merge if top agg with empty group keys and the lower agg
> function is COUNT, because in case of empty input for lower agg, the result
> is empty, if we merge them, we end up with 1 result with 0, which is wrong.
> does not apply if the top aggregate is a SUM0, I believe. Without a fix for
> this, there's this one case where this rule falls down and isn't able to
> merge something that just got rolled up: otherwise it's a pretty nice
> invariant that if one of our standard rollup rules for aggregates (say, in
> {{MaterializedViewRule}}) just split the aggregate, this rule should be able
> to merge it back.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (CALCITE-4102) Some improvements to aggregate related operations
[ https://issues.apache.org/jira/browse/CALCITE-4102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Sereda closed CALCITE-4102. -- Released as part of 1.25 ([68b02dfd4af15bc|https://github.com/apache/calcite/commit/68b02dfd4af15bc94a91a0cd2a30655d04439555]) > Some improvements to aggregate related operations > - > > Key: CALCITE-4102 > URL: https://issues.apache.org/jira/browse/CALCITE-4102 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: Liya Fan >Assignee: Liya Fan >Priority: Minor > Labels: pull-request-available > Fix For: 1.25.0 > > Time Spent: 2h 40m > Remaining Estimate: 0h > > 1. Improve the use of data structures > 2. Extract common methods > 3. Avoid expensive operations -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (CALCITE-4154) Add a rule to merge a Project onto an Aggregate
[
https://issues.apache.org/jira/browse/CALCITE-4154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrei Sereda closed CALCITE-4154.
--
Released as part of 1.25
([68b02dfd4af15bc|https://github.com/apache/calcite/commit/68b02dfd4af15bc94a91a0cd2a30655d04439555])
> Add a rule to merge a Project onto an Aggregate
> ---
>
> Key: CALCITE-4154
> URL: https://issues.apache.org/jira/browse/CALCITE-4154
> Project: Calcite
> Issue Type: Bug
>Reporter: Julian Hyde
>Assignee: Julian Hyde
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.25.0
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Add a rule to merge a {{Project}} onto an {{Aggregate}}. In practice, it
> means that aggregate functions that are not used in the Project are removed
> from the Aggregate.
> For example,
> {code:java}
> SELECT deptno, sum_sal
> FROM (
> SELECT deptno, job, SUM(sal) AS sum_sal, MIN(ename) AS min_ename
> FROM emp
> GROUP BY deptno, job)
> {code}
> becomes
> {code:java}
> SELECT deptno, sum_sal
> FROM (
> SELECT deptno, job, SUM(sal) AS sum_sal
> FROM emp
> GROUP BY deptno, job)
> {code}
> Note that {{min_ename}} is removed from the {{Aggregate}} (because it is not
> used by the {{Project}}). {{job}} is not used, but it remains because it is a
> {{GROUP BY}} key.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (CALCITE-4111) Remove VolcanoPlannerPhase in VolcanoPlanner
[ https://issues.apache.org/jira/browse/CALCITE-4111?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Sereda closed CALCITE-4111. -- Released as part of 1.25 ([68b02dfd4af15bc|https://github.com/apache/calcite/commit/68b02dfd4af15bc94a91a0cd2a30655d04439555]) > Remove VolcanoPlannerPhase in VolcanoPlanner > > > Key: CALCITE-4111 > URL: https://issues.apache.org/jira/browse/CALCITE-4111 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: Jiatao Tao >Assignee: Jiatao Tao >Priority: Minor > Labels: pull-request-available > Fix For: 1.25.0 > > Time Spent: 1.5h > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (CALCITE-4080) Allow character literals as column aliases, if SqlConformance.allowCharLiteralAlias()
[
https://issues.apache.org/jira/browse/CALCITE-4080?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrei Sereda closed CALCITE-4080.
--
Released as part of 1.25
([68b02dfd4af15bc|https://github.com/apache/calcite/commit/68b02dfd4af15bc94a91a0cd2a30655d04439555])
> Allow character literals as column aliases, if
> SqlConformance.allowCharLiteralAlias()
> -
>
> Key: CALCITE-4080
> URL: https://issues.apache.org/jira/browse/CALCITE-4080
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.23.0
>Reporter: Dan Cojocaru
>Assignee: Julian Hyde
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.25.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Exception occurs while parsing query with quoted alias for select columns.
> {code:java}
> final FrameworkConfig config = Frameworks.newConfigBuilder()
> .parserConfig(SqlParser.configBuilder().setLex(Lex.MYSQL)
> .setConformance(SqlConformanceEnum.MYSQL_5).build())
> .programs(Programs.ofRules(Programs.RULE_SET))
> .build();
> Planner p = Frameworks.getPlanner(config);
> SqlNode n = p.parse("SELECT 1 AS 'some alias' from dual");
> {code}
> The following exception is thrown:
> {code:java}
> org.apache.calcite.sql.parser.SqlParseException: Encountered "\'some alias\'"
> at line 1, column 13.
> Was expecting one of:
> ...
> ...
> ...
> ...
> ...{code}
> If query is changed into :
> {code:java}
> "SELECT 1 AS some_alias from dual"
> {code}
> the query is parsed correctly.
>
> Quoted aliases ( e.g: 'some alias' ) {color:#172b4d}should be valid as
> well.{color}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (CALCITE-3923) Refactor how planner rules are parameterized
[
https://issues.apache.org/jira/browse/CALCITE-3923?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrei Sereda closed CALCITE-3923.
--
Released as part of 1.25
([68b02dfd4af15bc|https://github.com/apache/calcite/commit/68b02dfd4af15bc94a91a0cd2a30655d04439555])
> Refactor how planner rules are parameterized
>
>
> Key: CALCITE-3923
> URL: https://issues.apache.org/jira/browse/CALCITE-3923
> Project: Calcite
> Issue Type: Bug
>Reporter: Julian Hyde
>Assignee: Julian Hyde
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.25.0
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> People often want different variants of planner rules. An example is
> {{FilterJoinRule}}, which has a 'boolean smart’ parameter, a predicate (which
> returns whether to pull up filter conditions), operands (which determine the
> precise sub-classes of {{RelNode}} that the rule should match) and a
> {{RelBuilderFactory}} (which controls the type of {{RelNode}} created by this
> rule).
> Suppose you have an instance of {{FilterJoinRule}} and you want to change
> {{smart}} from true to false. The {{smart}} parameter is immutable (good!)
> but you can’t easily create a clone of the rule because you don’t know the
> values of the other parameters. Your instance might even be (unbeknownst to
> you) a sub-class with extra parameters and a private constructor.
> So, my proposal is to put all of the config information of a {{RelOptRule}}
> into a single {{config}} parameter that contains all relevant properties.
> Each sub-class of {{RelOptRule}} would have one constructor with just a
> ‘config’ parameter. Each config knows which sub-class of {{RelOptRule}} to
> create. Therefore it is easy to copy a config, change one or more properties,
> and create a new rule instance.
> Adding a property to a rule’s config does not require us to add or deprecate
> any constructors.
> The operands are part of the config, so if you have a rule that matches a
> {{EnumerableFilter}} on an {{EnumerableJoin}} and you want to make it match
> an {{EnumerableFilter}} on an {{EnumerableNestedLoopJoin}}, you can easily
> create one with one changed operand.
> The config is immutable and self-describing, so we can use it to
> automatically generate a unique description for each rule instance.
> (See the email thread [[DISCUSS] Refactor how planner rules are
> parameterized|https://lists.apache.org/thread.html/rfdf6f9b7821988bdd92b0377e3d293443a6376f4773c4c658c891cf9%40%3Cdev.calcite.apache.org%3E].)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (CALCITE-4132) Estimate the number of distinct values more accurately
[ https://issues.apache.org/jira/browse/CALCITE-4132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Sereda closed CALCITE-4132. -- Released as part of 1.25 ([68b02dfd4af15bc|https://github.com/apache/calcite/commit/68b02dfd4af15bc94a91a0cd2a30655d04439555]) > Estimate the number of distinct values more accurately > -- > > Key: CALCITE-4132 > URL: https://issues.apache.org/jira/browse/CALCITE-4132 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: Liya Fan >Assignee: Liya Fan >Priority: Major > Labels: pull-request-available > Fix For: 1.25.0 > > Time Spent: 1h 10m > Remaining Estimate: 0h > > Currently, we estimate the NDV of many operators based on the > RelMdUtil#numDistinctVals method. This method estimates the expected number > of distinct values selected n times (with replacement) from a collection with > N distinct values. The estimation is based on the approximation when N > approaches infinity. > However, when N is not a large number, the difference between the approximate > and exact values can be notabe. In addtion, the error can be magnified by > different combinations of N and n, which can lead the optimizer to make wrong > decisions. > For example, when we select one element from a table with a 4-value enum, we > expect to get one distinct value according to common sense. However, the > current implementation gives 0.88, which is counter-intuitive, and leads to a > 10+% error. > Therefore, we give the exact estimation based on the unbiased estimator (The > proof is given in the comment). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (CALCITE-4145) Exception when query from UDF field with structured type
[
https://issues.apache.org/jira/browse/CALCITE-4145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrei Sereda closed CALCITE-4145.
--
Released as part of 1.25
([68b02dfd4af15bc|https://github.com/apache/calcite/commit/68b02dfd4af15bc94a91a0cd2a30655d04439555])
> Exception when query from UDF field with structured type
>
>
> Key: CALCITE-4145
> URL: https://issues.apache.org/jira/browse/CALCITE-4145
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.23.0, 1.24.0
>Reporter: Danny Chen
>Assignee: Danny Chen
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.25.0
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Check this sql in {{SqlToRelConverterTest}}
> {code:java}
> @Test void testUdfWithStructuredReturnType() {
> final String sql = "SELECT deptno, tmp.r.not_null_field,
> tmp.r.nullable_field FROM\n"
> + "(SELECT deptno, ROW_FUNC() AS r from dept)tmp";
> sql(sql).ok();
> }
> {code}
> {{ArrayIndexOutOfBoundsException}} throws because the nested field got a -1
> index when querying the field by simple name.
> To solve the problem, for a nested field, return its parent field's
> monotonicity.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (CALCITE-4114) Remove method CalciteAssert.forceDecorrelate
[
https://issues.apache.org/jira/browse/CALCITE-4114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrei Sereda closed CALCITE-4114.
--
Released as part of 1.25
([68b02dfd4af15bc|https://github.com/apache/calcite/commit/68b02dfd4af15bc94a91a0cd2a30655d04439555])
> Remove method CalciteAssert.forceDecorrelate
>
>
> Key: CALCITE-4114
> URL: https://issues.apache.org/jira/browse/CALCITE-4114
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: Jiatao Tao
>Assignee: Jiatao Tao
>Priority: Trivial
> Labels: pull-request-available
> Fix For: 1.25.0
>
> Attachments: image-2020-07-09-14-34-52-644.png
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> The description is: "Creates a \{@link FrameworkConfig} that does not
> decorrelate.", and the body is set
> CalciteConnectionProperty.FORCE_DECORRELATE to false.
> But the function name is forceDecorrelate, quite confusing.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (CALCITE-4022) Support unparse special syntax when operator is INSERT
[
https://issues.apache.org/jira/browse/CALCITE-4022?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrei Sereda closed CALCITE-4022.
--
Released as part of 1.25
([68b02dfd4af15bc|https://github.com/apache/calcite/commit/68b02dfd4af15bc94a91a0cd2a30655d04439555])
> Support unparse special syntax when operator is INSERT
> --
>
> Key: CALCITE-4022
> URL: https://issues.apache.org/jira/browse/CALCITE-4022
> Project: Calcite
> Issue Type: Wish
> Components: core
>Reporter: xzh_dz
>Assignee: Wang Yanlin
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.25.0
>
> Attachments: image-2020-05-25-17-38-36-009.png
>
> Time Spent: 3h 10m
> Remaining Estimate: 0h
>
> This exception can be reproduced as below:
> SqlParserTest:
> {code:java}
> @Test void test() throws Exception {
> final String sql = "insert into emps select * from emps";
> final SqlNode sqlNode = getSqlParser(sql).parseStmt();
> final SqlNode sqlNodeVisited = sqlNode.accept(new SqlShuttle() {
> @Override public SqlNode visit(SqlIdentifier identifier) {
> return new SqlIdentifier(identifier.names,
> identifier.getParserPosition());
> }
> });
> System.out.println(sqlNodeVisited.toString());
> }
> {code}
> !image-2020-05-25-17-38-36-009.png!
> Method threw 'java.lang.UnsupportedOperationException' exception. Cannot
> evaluate org.apache.calcite.sql.SqlBasicCall.toString()
> SqlInsert is a SqlSpecialOperator, when `toString` method is called, this
> problem is shown.We can see that `SqlSyntax#SPECIAL#unparse()` hasn't been
> implemented yet.
> exception :
> java.lang.UnsupportedOperationException: class
> org.apache.calcite.sql.SqlSyntax$6: SPECIAL
> at org.apache.calcite.util.Util.needToImplement(Util.java:967)
> at org.apache.calcite.sql.SqlSyntax$6.unparse(SqlSyntax.java:116)
> at org.apache.calcite.sql.SqlOperator.unparse(SqlOperator.java:333)
> at org.apache.calcite.sql.SqlDialect.unparseCall(SqlDialect.java:462)
> at org.apache.calcite.sql.SqlCall.unparse(SqlCall.java:104)
> at org.apache.calcite.sql.SqlNode.toSqlString(SqlNode.java:151)
> at org.apache.calcite.sql.SqlNode.toString(SqlNode.java:126)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (CALCITE-2854) Codegen compile error when implementing unary minus function with data type BigDecimal
[
https://issues.apache.org/jira/browse/CALCITE-2854?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrei Sereda closed CALCITE-2854.
--
Released as part of 1.25
([68b02dfd4af15bc|https://github.com/apache/calcite/commit/68b02dfd4af15bc94a91a0cd2a30655d04439555])
> Codegen compile error when implementing unary minus function with data type
> BigDecimal
> --
>
> Key: CALCITE-2854
> URL: https://issues.apache.org/jira/browse/CALCITE-2854
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.18.0
>Reporter: Lai Zhou
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.25.0
>
> Time Spent: 8h 10m
> Remaining Estimate: 0h
>
> case:
> {code:java}
> @Test public void test() throws Exception {
> final String cr = "create table t (a DECIMAL)";
> final String se = "select -a as aa from t";
> Connection c = connect();
> Statement s = c.createStatement();
> s.execute(cr);
> s.executeQuery(se);
> }
> {code}
> error msg:
> {code:java}
> Caused by: org.codehaus.commons.compiler.CompileException: Line 21, Column
> 71: Object of type "java.math.BigDecimal" cannot be converted to a numeric
> type
> {code}
> {code:java}
> public Object current() {
> final java.math.BigDecimal current = inputEnumerator.current() == null ?
> (java.math.BigDecimal) null :
> org.apache.calcite.runtime.SqlFunctions.toBigDecimal(inputEnumerator.current());
> return current == null ? (java.math.BigDecimal) null : - current;
> }
> {code}
> `- current` is not right ,we'd better constructor a new BigDecimal object to
> to replace this code snippet，like
> {code:java}
> return current == null ? (java.math.BigDecimal) null :
> SqlFunctions.negativeDecimal(current);
> {code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (CALCITE-4115) Improve the prompt of using SQL keywords for sql parser
[
https://issues.apache.org/jira/browse/CALCITE-4115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrei Sereda closed CALCITE-4115.
--
Released as part of 1.25
([68b02dfd4af15bc|https://github.com/apache/calcite/commit/68b02dfd4af15bc94a91a0cd2a30655d04439555])
> Improve the prompt of using SQL keywords for sql parser
> ---
>
> Key: CALCITE-4115
> URL: https://issues.apache.org/jira/browse/CALCITE-4115
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.23.0
>Reporter: Danny Chen
>Assignee: Danny Chen
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.25.0
>
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> Current when a user uses a reserved-keyword in the SQL, for example:
> {code:sql}
> select DEFAULT from emp;
> {code}
> the parser would report with error message:
> {noformat}
> Encountered "DEFAULT" at line 1, column 8.
> Was expecting one of:
> "ABS" ...
> "ALL" ...
> "ARRAY" ...
> "AVG" ...
> "CARDINALITY" ...
> "CASE" ...
> "CAST" ...
> "CEIL" ...
> "CEILING" ...
> "CHAR_LENGTH" ...
> "CHARACTER_LENGTH" ...
> {noformat}
> It is hard to infer that the DEFAULT is actually a reserved-keyword, we can
> promote the message to make it more clear.
> For example, in SQL-SERVER, if you use such a keyword, the server reports
> "Incorrect syntax near the keyword 'DEFAULT'", which is very clear that the
> DEFAULT is a keyword.
> Based on the SQL-SERVER message, i would suggest to also report the position
> with a suggested fix solution, the template is like this:
> {code:java}
> Incorrect syntax near the keyword {keyword} at line {line_number},
> column {column_number}.\n
> Either uses a non-reserved keyword or quotes the keyword with
> character: {quoting_character}.
> {code}
> We would tell user that the mistake is a keyword and its position, also how
> to fix it.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (CALCITE-4139) Prevent NPE in ListTransientTable
[ https://issues.apache.org/jira/browse/CALCITE-4139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Sereda closed CALCITE-4139. -- Released as part of 1.25 ([68b02dfd4af15bc|https://github.com/apache/calcite/commit/68b02dfd4af15bc94a91a0cd2a30655d04439555]) > Prevent NPE in ListTransientTable > - > > Key: CALCITE-4139 > URL: https://issues.apache.org/jira/browse/CALCITE-4139 > Project: Calcite > Issue Type: Task > Components: core >Reporter: Ruben Q L >Assignee: Ruben Q L >Priority: Minor > Labels: pull-request-available > Fix For: 1.25.0 > > Time Spent: 50m > Remaining Estimate: 0h > > ListTransientTable#scan returns an enumerator that can potentially lead to > NPE. Code should be fixed to prevent this from happening. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (CALCITE-4150) RelToSqlConverter does not support null without a cast: "Unsupported type when convertTypeToSpec: NULL"
[
https://issues.apache.org/jira/browse/CALCITE-4150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrei Sereda closed CALCITE-4150.
--
Released as part of 1.25
([68b02dfd4af15bc|https://github.com/apache/calcite/commit/68b02dfd4af15bc94a91a0cd2a30655d04439555])
> RelToSqlConverter does not support null without a cast: "Unsupported type
> when convertTypeToSpec: NULL"
> ---
>
> Key: CALCITE-4150
> URL: https://issues.apache.org/jira/browse/CALCITE-4150
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.24.0
>Reporter: Anton Haidai
>Assignee: Anton Haidai
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.25.0
>
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> RelToSqlConverterTest:
> {code:java}
> @Test void testSelectNullNoCast() {
> String query = "select \"product_id\", null as dummy from \"product\"";
> final String expected = "SELECT \"product_id\", CAST(NULL AS NULL) AS
> \"DUMMY\"\n"
> + "FROM \"foodmart\".\"product\"";
> sql(query).ok(expected);
> }{code}
> the test works fine in 1.23.
> result in 1.24:
> {code:java}
> Unsupported type when convertTypeToSpec: NULL
> java.lang.UnsupportedOperationException: Unsupported type when
> convertTypeToSpec: NULL at
> org.apache.calcite.sql.type.SqlTypeUtil.convertTypeToSpec(SqlTypeUtil.java:1078)
> at org.apache.calcite.sql.SqlDialect.getCastSpec(SqlDialect.java:790) at
> org.apache.calcite.rel.rel2sql.RelToSqlConverter.castNullType(RelToSqlConverter.java:361)
> at
> org.apache.calcite.rel.rel2sql.RelToSqlConverter.visit(RelToSqlConverter.java:342)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method) at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566) at
> org.apache.calcite.util.ReflectUtil$2.invoke(ReflectUtil.java:524) at
> org.apache.calcite.rel.rel2sql.RelToSqlConverter.dispatch(RelToSqlConverter.java:131){code}
> Please note, that there is an existing test "testSelectNull()", but it tests
> nulls with a cast, "CAST(NULL AS INT)".
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (CALCITE-4141) Make checkstyle tasks relocatable to support Gradle build cache
[
https://issues.apache.org/jira/browse/CALCITE-4141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrei Sereda closed CALCITE-4141.
--
Released as part of 1.25
([68b02dfd4af15bc|https://github.com/apache/calcite/commit/68b02dfd4af15bc94a91a0cd2a30655d04439555])
> Make checkstyle tasks relocatable to support Gradle build cache
> ---
>
> Key: CALCITE-4141
> URL: https://issues.apache.org/jira/browse/CALCITE-4141
> Project: Calcite
> Issue Type: Task
>Affects Versions: avatica-1.17.0, 1.23.0
>Reporter: Vladimir Sitnikov
>Priority: Major
> Fix For: 1.25.0
>
>
> Checkstyle configuration uses {{base_dir=rootDir.toString()}} property which
> defeats caching as different workstations tend to have different absolute
> path to the Calcite checkout.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-2854) Codegen compile error when implementing unary minus function with data type BigDecimal
[
https://issues.apache.org/jira/browse/CALCITE-2854?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrei Sereda updated CALCITE-2854:
---
Fix Version/s: 1.25.0
> Codegen compile error when implementing unary minus function with data type
> BigDecimal
> --
>
> Key: CALCITE-2854
> URL: https://issues.apache.org/jira/browse/CALCITE-2854
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.18.0
>Reporter: Lai Zhou
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.25.0
>
> Time Spent: 8h 10m
> Remaining Estimate: 0h
>
> case:
> {code:java}
> @Test public void test() throws Exception {
> final String cr = "create table t (a DECIMAL)";
> final String se = "select -a as aa from t";
> Connection c = connect();
> Statement s = c.createStatement();
> s.execute(cr);
> s.executeQuery(se);
> }
> {code}
> error msg:
> {code:java}
> Caused by: org.codehaus.commons.compiler.CompileException: Line 21, Column
> 71: Object of type "java.math.BigDecimal" cannot be converted to a numeric
> type
> {code}
> {code:java}
> public Object current() {
> final java.math.BigDecimal current = inputEnumerator.current() == null ?
> (java.math.BigDecimal) null :
> org.apache.calcite.runtime.SqlFunctions.toBigDecimal(inputEnumerator.current());
> return current == null ? (java.math.BigDecimal) null : - current;
> }
> {code}
> `- current` is not right ,we'd better constructor a new BigDecimal object to
> to replace this code snippet，like
> {code:java}
> return current == null ? (java.math.BigDecimal) null :
> SqlFunctions.negativeDecimal(current);
> {code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (CALCITE-4169) Release Calcite 1.25.0
Andrei Sereda created CALCITE-4169: -- Summary: Release Calcite 1.25.0 Key: CALCITE-4169 URL: https://issues.apache.org/jira/browse/CALCITE-4169 Project: Calcite Issue Type: Task Reporter: Andrei Sereda Assignee: Andrei Sereda Created for tracking 1.25.0 release -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-4069) Elasticsearch the result of count(*) will be added to the result list twice when use multiple aggregations without group by
[
https://issues.apache.org/jira/browse/CALCITE-4069?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17138874#comment-17138874
]
Andrei Sereda commented on CALCITE-4069:
What would happen in the case below ?
{code:sql}
select count(*), sum(field1), min(field2), count(*) from foo
{code}
> Elasticsearch the result of count(*) will be added to the result list twice
> when use multiple aggregations without group by
> ---
>
> Key: CALCITE-4069
> URL: https://issues.apache.org/jira/browse/CALCITE-4069
> Project: Calcite
> Issue Type: Improvement
> Components: elasticsearch-adapter
>Reporter: yeyonghao
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> when you write a sql:
> {code:java}
> select count(*) from mytable
> {code}
> in:
> {code:java}
> org.apache.calcite.adapter.elasticsearch.ElasticsearchTable#aggregate
> {code}
> As an optimization, totalHit will be the result of the query for count *:
> {code:java}
> // elastic exposes total number of documents matching a query in
> "/hits/total" path
> // this can be used for simple "select count(*) from table"
> final long total = res.searchHits().total().value();
> {code}
> It is then added to the result set:
> {code:java}
> if (groupBy.isEmpty()) {
> // put totals automatically for count(*) expression(s), unless they contain
> group by
> for (String expr : countAll) {
> result.forEach(m -> m.put(expr, total));
> }
> }
> {code}
> This is fine if there is only one count * aggregate function in SQL.
> But when you write multiple aggregate functions in your SQL:
> {code:java}
> select count(*),sum(field1) from mytable{code}
> You'll notice that the result of count * is repeatedly added to the result
> set (it doesn't affect the final result, but I think it can be optimized).
> The result of count * is first added to the result set along with other
> aggregate function result values in the following code:
> {code:java}
> final List> result = new ArrayList<>();
> if (res.aggregations() != null) {
> // collect values
> ElasticsearchJson.visitValueNodes(res.aggregations(), m -> {
> // using 'Collectors.toMap' will trigger Java 8 bug here
> Map newMap = new LinkedHashMap<>();
> for (String key: m.keySet()) {
> newMap.put(fieldMap.getOrDefault(key, key), m.get(key));
> }
> result.add(newMap);
> });
> } else {
> // probably no group by. add single result
> result.add(new LinkedHashMap<>());
> }
> {code}
> The second time is added again in the following code:
> {code:java}
> // elastic exposes total number of documents matching a query in
> "/hits/total" path
> // this can be used for simple "select count(*) from table"
> final long total = res.searchHits().total().value();
> if (groupBy.isEmpty()) {
> // put totals automatically for count(*) expression(s), unless they contain
> group by
> for (String expr : countAll) {
> result.forEach(m -> m.put(expr, total));
> }
> }
> {code}
> Although such operations have no effect on the final result when there are
> multiple aggregate functions, it is obvious that they can be
> optimized.TotalHit is added to the result set only when groupby. isEmpty()
> and aggregation. size() == 1 simultaneously satisfy:
> {code:java}
> if (groupBy.isEmpty() && aggregations.size() == 1) {
>...
> }
> {code}
> This avoids repeatedly adding count * to the result set.
>
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (CALCITE-4069) Elasticsearch the result of count(*) will be added to the result list twice when use multiple aggregations without group by
[
https://issues.apache.org/jira/browse/CALCITE-4069?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17138874#comment-17138874
]
Andrei Sereda edited comment on CALCITE-4069 at 6/17/20, 10:24 PM:
---
What would happen in the case below ?
{code:sql}
select count(*), sum(field1), min(field2), count(*) from foo
{code}
Assume {{aggregations.size() > 1}} ?
was (Author: asereda):
What would happen in the case below ?
{code:sql}
select count(*), sum(field1), min(field2), count(*) from foo
{code}
> Elasticsearch the result of count(*) will be added to the result list twice
> when use multiple aggregations without group by
> ---
>
> Key: CALCITE-4069
> URL: https://issues.apache.org/jira/browse/CALCITE-4069
> Project: Calcite
> Issue Type: Improvement
> Components: elasticsearch-adapter
>Reporter: yeyonghao
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> when you write a sql:
> {code:java}
> select count(*) from mytable
> {code}
> in:
> {code:java}
> org.apache.calcite.adapter.elasticsearch.ElasticsearchTable#aggregate
> {code}
> As an optimization, totalHit will be the result of the query for count *:
> {code:java}
> // elastic exposes total number of documents matching a query in
> "/hits/total" path
> // this can be used for simple "select count(*) from table"
> final long total = res.searchHits().total().value();
> {code}
> It is then added to the result set:
> {code:java}
> if (groupBy.isEmpty()) {
> // put totals automatically for count(*) expression(s), unless they contain
> group by
> for (String expr : countAll) {
> result.forEach(m -> m.put(expr, total));
> }
> }
> {code}
> This is fine if there is only one count * aggregate function in SQL.
> But when you write multiple aggregate functions in your SQL:
> {code:java}
> select count(*),sum(field1) from mytable{code}
> You'll notice that the result of count * is repeatedly added to the result
> set (it doesn't affect the final result, but I think it can be optimized).
> The result of count * is first added to the result set along with other
> aggregate function result values in the following code:
> {code:java}
> final List> result = new ArrayList<>();
> if (res.aggregations() != null) {
> // collect values
> ElasticsearchJson.visitValueNodes(res.aggregations(), m -> {
> // using 'Collectors.toMap' will trigger Java 8 bug here
> Map newMap = new LinkedHashMap<>();
> for (String key: m.keySet()) {
> newMap.put(fieldMap.getOrDefault(key, key), m.get(key));
> }
> result.add(newMap);
> });
> } else {
> // probably no group by. add single result
> result.add(new LinkedHashMap<>());
> }
> {code}
> The second time is added again in the following code:
> {code:java}
> // elastic exposes total number of documents matching a query in
> "/hits/total" path
> // this can be used for simple "select count(*) from table"
> final long total = res.searchHits().total().value();
> if (groupBy.isEmpty()) {
> // put totals automatically for count(*) expression(s), unless they contain
> group by
> for (String expr : countAll) {
> result.forEach(m -> m.put(expr, total));
> }
> }
> {code}
> Although such operations have no effect on the final result when there are
> multiple aggregate functions, it is obvious that they can be
> optimized.TotalHit is added to the result set only when groupby. isEmpty()
> and aggregation. size() == 1 simultaneously satisfy:
> {code:java}
> if (groupBy.isEmpty() && aggregations.size() == 1) {
>...
> }
> {code}
> This avoids repeatedly adding count * to the result set.
>
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (CALCITE-3912) Incorrect mapping parsing when properties have same name as reserved keywords in ElasticSearch
[
https://issues.apache.org/jira/browse/CALCITE-3912?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17081526#comment-17081526
]
Andrei Sereda edited comment on CALCITE-3912 at 4/11/20, 7:04 PM:
--
Fixed in
[3755eb587|https://github.com/apache/calcite/commit/3755eb5871860f1fd5dc51990129784caa8ac0a4]
was (Author: asereda):
Fixed in
[3755eb587](https://github.com/apache/calcite/commit/3755eb5871860f1fd5dc51990129784caa8ac0a4)
> Incorrect mapping parsing when properties have same name as reserved keywords
> in ElasticSearch
> --
>
> Key: CALCITE-3912
> URL: https://issues.apache.org/jira/browse/CALCITE-3912
> Project: Calcite
> Issue Type: Improvement
> Components: elasticsearch-adapter
>Affects Versions: 1.21.0
>Reporter: Andrei Sereda
>Assignee: Andrei Sereda
>Priority: Major
> Labels: pull-request-available
> Time Spent: 20m
> Remaining Estimate: 0h
>
> If a property has name {{type}} or {{properties}} ES adapter doesn't
> correctly process the
> [mapping|https://www.elastic.co/guide/en/elasticsearch/reference/current/mapping.html]
> structure.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (CALCITE-3912) Incorrect mapping parsing when properties have same name as reserved keywords in ElasticSearch
[
https://issues.apache.org/jira/browse/CALCITE-3912?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrei Sereda resolved CALCITE-3912.
Resolution: Fixed
Fixed in
[3755eb587](https://github.com/apache/calcite/commit/3755eb5871860f1fd5dc51990129784caa8ac0a4)
> Incorrect mapping parsing when properties have same name as reserved keywords
> in ElasticSearch
> --
>
> Key: CALCITE-3912
> URL: https://issues.apache.org/jira/browse/CALCITE-3912
> Project: Calcite
> Issue Type: Improvement
> Components: elasticsearch-adapter
>Reporter: Andrei Sereda
>Assignee: Andrei Sereda
>Priority: Major
> Labels: pull-request-available
> Time Spent: 20m
> Remaining Estimate: 0h
>
> If a property has name {{type}} or {{properties}} ES adapter doesn't
> correctly process the
> [mapping|https://www.elastic.co/guide/en/elasticsearch/reference/current/mapping.html]
> structure.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-3912) Incorrect mapping parsing when properties have same name as reserved keywords in ElasticSearch
[
https://issues.apache.org/jira/browse/CALCITE-3912?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrei Sereda updated CALCITE-3912:
---
Affects Version/s: 1.21.0
> Incorrect mapping parsing when properties have same name as reserved keywords
> in ElasticSearch
> --
>
> Key: CALCITE-3912
> URL: https://issues.apache.org/jira/browse/CALCITE-3912
> Project: Calcite
> Issue Type: Improvement
> Components: elasticsearch-adapter
>Affects Versions: 1.21.0
>Reporter: Andrei Sereda
>Assignee: Andrei Sereda
>Priority: Major
> Labels: pull-request-available
> Time Spent: 20m
> Remaining Estimate: 0h
>
> If a property has name {{type}} or {{properties}} ES adapter doesn't
> correctly process the
> [mapping|https://www.elastic.co/guide/en/elasticsearch/reference/current/mapping.html]
> structure.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-3912) Incorrect mapping parsing when properties have same name as reserved keywords in ElasticSearch
[
https://issues.apache.org/jira/browse/CALCITE-3912?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrei Sereda updated CALCITE-3912:
---
Description: If a property has name {{type}} or {{properties}} ES adapter
doesn't correctly process the
[mapping|https://www.elastic.co/guide/en/elasticsearch/reference/current/mapping.html]
structure. (was: If a property has name {{type}} or {{properties}} ES adapter
doesn't process them correctly)
> Incorrect mapping parsing when properties have same name as reserved keywords
> in ElasticSearch
> --
>
> Key: CALCITE-3912
> URL: https://issues.apache.org/jira/browse/CALCITE-3912
> Project: Calcite
> Issue Type: Improvement
> Components: elasticsearch-adapter
>Reporter: Andrei Sereda
>Assignee: Andrei Sereda
>Priority: Major
>
> If a property has name {{type}} or {{properties}} ES adapter doesn't
> correctly process the
> [mapping|https://www.elastic.co/guide/en/elasticsearch/reference/current/mapping.html]
> structure.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (CALCITE-3912) Incorrect mapping parsing when properties have same name as reserved keywords in ElasticSearch
Andrei Sereda created CALCITE-3912:
--
Summary: Incorrect mapping parsing when properties have same name
as reserved keywords in ElasticSearch
Key: CALCITE-3912
URL: https://issues.apache.org/jira/browse/CALCITE-3912
Project: Calcite
Issue Type: Improvement
Components: elasticsearch-adapter
Reporter: Andrei Sereda
Assignee: Andrei Sereda
If a property has name {{type}} or {{properties}} ES adapter doesn't process
them correctly
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (CALCITE-3739) Remove failed snapshot track file in Windows OS for Cassandra adapter
[
https://issues.apache.org/jira/browse/CALCITE-3739?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrei Sereda reassigned CALCITE-3739:
--
Assignee: Andrei Sereda
> Remove failed snapshot track file in Windows OS for Cassandra adapter
> -
>
> Key: CALCITE-3739
> URL: https://issues.apache.org/jira/browse/CALCITE-3739
> Project: Calcite
> Issue Type: Bug
> Components: cassandra-adapter
>Reporter: Feng Zhu
>Assignee: Andrei Sereda
>Priority: Major
> Fix For: 1.22.0
>
> Attachments: screen.png
>
>
> In Windows OS, CassandraUnit leaves an extra "cassandra/.toDelete" snapshot
> track file.
> After migrating to Gradle, it is flagged as "unapproved license" and fails
> on "rat" task.
> It is annoying to manually delete this file every time.
> !screen.png!
> The issue is also mentioned in CALCITE-2442. But I found the snapshot file
> still exists with the fix.
> {code:java}
> @AfterClass
> public static void tearDown() {
> if (RULE instanceof CassandraCQLUnit) {
> CassandraCQLUnit rule = (CassandraCQLUnit) RULE;
> rule.getSession().close();
> rule.getCluster().close();
> // see https://issues.apache.org/jira/browse/CALCITE-2442
> // see https://issues.apache.org/jira/browse/CASSANDRA-13085
> // Is it done by cluster.close() already ?
> if (FBUtilities.isWindows) {
> WindowsFailedSnapshotTracker.deleteOldSnapshots();
> }
> }
> }
> {code}
> I make some profling work. It seems that the snapshot track file is locked by
> other threads.
> "The process cannot access the file because it is being used by another
> process."
> Any ideas?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-2442) Cassandra unit test intermittent failures
[
https://issues.apache.org/jira/browse/CALCITE-2442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17035885#comment-17035885
]
Andrei Sereda commented on CALCITE-2442:
[~rubenql] changes have been merged in master. Can you pls validate in your
environment ?
> Cassandra unit test intermittent failures
> -
>
> Key: CALCITE-2442
> URL: https://issues.apache.org/jira/browse/CALCITE-2442
> Project: Calcite
> Issue Type: Bug
> Components: cassandra-adapter
>Reporter: Andrei Sereda
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.22.0
>
> Time Spent: 4h 40m
> Remaining Estimate: 0h
>
> We have noticed that there are failures due to :
> # Wrong parsing of new [JDK version scheme|http://openjdk.java.net/jeps/223]
> (by calcite and cassandra dependencies like jamm). {{10-ea}} vs {{10.0.2}}
> # Cassandra startup timeout on Linux Jenkins CI server. Contrary to github
> travis CI (the one which validates PRs), it takes about 20s for embedded
> cassandra to start (still under investigation).
> # [~Sergey Nuyanzin] reported that
> [CassandraUnit|https://github.com/jsevellec/cassandra-unit] leaves
> {{.toDelete}} folder in maven module folder ({{cassandra/}}) rather than
> {{target/}} where all build and temporary files should be located. Not a
> failure but annoyance.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (CALCITE-2442) Cassandra unit test intermittent failures
[
https://issues.apache.org/jira/browse/CALCITE-2442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrei Sereda resolved CALCITE-2442.
Resolution: Fixed
Fixed in
[9b2a559](https://github.com/apache/calcite/commit/9b2a5592f3852a39225ec0b41b1768f533c825d0)
> Cassandra unit test intermittent failures
> -
>
> Key: CALCITE-2442
> URL: https://issues.apache.org/jira/browse/CALCITE-2442
> Project: Calcite
> Issue Type: Bug
> Components: cassandra-adapter
>Reporter: Andrei Sereda
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.22.0
>
> Time Spent: 4h 40m
> Remaining Estimate: 0h
>
> We have noticed that there are failures due to :
> # Wrong parsing of new [JDK version scheme|http://openjdk.java.net/jeps/223]
> (by calcite and cassandra dependencies like jamm). {{10-ea}} vs {{10.0.2}}
> # Cassandra startup timeout on Linux Jenkins CI server. Contrary to github
> travis CI (the one which validates PRs), it takes about 20s for embedded
> cassandra to start (still under investigation).
> # [~Sergey Nuyanzin] reported that
> [CassandraUnit|https://github.com/jsevellec/cassandra-unit] leaves
> {{.toDelete}} folder in maven module folder ({{cassandra/}}) rather than
> {{target/}} where all build and temporary files should be located. Not a
> failure but annoyance.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (CALCITE-2442) Cassandra unit test intermittent failures
[
https://issues.apache.org/jira/browse/CALCITE-2442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17035884#comment-17035884
]
Andrei Sereda edited comment on CALCITE-2442 at 2/13/20 3:24 AM:
-
Fixed in
[9b2a559|https://github.com/apache/calcite/commit/9b2a5592f3852a39225ec0b41b1768f533c825d0]
was (Author: asereda):
Fixed in
[9b2a559](https://github.com/apache/calcite/commit/9b2a5592f3852a39225ec0b41b1768f533c825d0)
> Cassandra unit test intermittent failures
> -
>
> Key: CALCITE-2442
> URL: https://issues.apache.org/jira/browse/CALCITE-2442
> Project: Calcite
> Issue Type: Bug
> Components: cassandra-adapter
>Reporter: Andrei Sereda
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.22.0
>
> Time Spent: 4h 40m
> Remaining Estimate: 0h
>
> We have noticed that there are failures due to :
> # Wrong parsing of new [JDK version scheme|http://openjdk.java.net/jeps/223]
> (by calcite and cassandra dependencies like jamm). {{10-ea}} vs {{10.0.2}}
> # Cassandra startup timeout on Linux Jenkins CI server. Contrary to github
> travis CI (the one which validates PRs), it takes about 20s for embedded
> cassandra to start (still under investigation).
> # [~Sergey Nuyanzin] reported that
> [CassandraUnit|https://github.com/jsevellec/cassandra-unit] leaves
> {{.toDelete}} folder in maven module folder ({{cassandra/}}) rather than
> {{target/}} where all build and temporary files should be located. Not a
> failure but annoyance.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-3739) Remove failed snapshot track file in Windows OS for Cassandra adapter
[
https://issues.apache.org/jira/browse/CALCITE-3739?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17035701#comment-17035701
]
Andrei Sereda commented on CALCITE-3739:
I have updated cassandra tests to JUnit5 which allows to have a callback after
all tests.
[~donnyzone] sorry to bother you, but can you pls test again ?
> Remove failed snapshot track file in Windows OS for Cassandra adapter
> -
>
> Key: CALCITE-3739
> URL: https://issues.apache.org/jira/browse/CALCITE-3739
> Project: Calcite
> Issue Type: Bug
> Components: cassandra-adapter
>Reporter: Feng Zhu
>Priority: Major
> Attachments: screen.png
>
>
> In Windows OS, CassandraUnit leaves an extra "cassandra/.toDelete" snapshot
> track file.
> After migrating to Gradle, it is flagged as "unapproved license" and fails
> on "rat" task.
> It is annoying to manually delete this file every time.
> !screen.png!
> The issue is also mentioned in CALCITE-2442. But I found the snapshot file
> still exists with the fix.
> {code:java}
> @AfterClass
> public static void tearDown() {
> if (RULE instanceof CassandraCQLUnit) {
> CassandraCQLUnit rule = (CassandraCQLUnit) RULE;
> rule.getSession().close();
> rule.getCluster().close();
> // see https://issues.apache.org/jira/browse/CALCITE-2442
> // see https://issues.apache.org/jira/browse/CASSANDRA-13085
> // Is it done by cluster.close() already ?
> if (FBUtilities.isWindows) {
> WindowsFailedSnapshotTracker.deleteOldSnapshots();
> }
> }
> }
> {code}
> I make some profling work. It seems that the snapshot track file is locked by
> other threads.
> "The process cannot access the file because it is being used by another
> process."
> Any ideas?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (CALCITE-2442) Cassandra unit test intermittent failures
[
https://issues.apache.org/jira/browse/CALCITE-2442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17035388#comment-17035388
]
Andrei Sereda edited comment on CALCITE-2442 at 2/12/20 3:49 PM:
-
I think CassandraUnit doesn't properly shutdown the CassandraDaemon (it's not
gradle's problem)
was (Author: asereda):
I think CassandraUnit doesn't properly shutdown the CassandraDaemon
> Cassandra unit test intermittent failures
> -
>
> Key: CALCITE-2442
> URL: https://issues.apache.org/jira/browse/CALCITE-2442
> Project: Calcite
> Issue Type: Bug
> Components: cassandra-adapter
>Reporter: Andrei Sereda
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.22.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> We have noticed that there are failures due to :
> # Wrong parsing of new [JDK version scheme|http://openjdk.java.net/jeps/223]
> (by calcite and cassandra dependencies like jamm). {{10-ea}} vs {{10.0.2}}
> # Cassandra startup timeout on Linux Jenkins CI server. Contrary to github
> travis CI (the one which validates PRs), it takes about 20s for embedded
> cassandra to start (still under investigation).
> # [~Sergey Nuyanzin] reported that
> [CassandraUnit|https://github.com/jsevellec/cassandra-unit] leaves
> {{.toDelete}} folder in maven module folder ({{cassandra/}}) rather than
> {{target/}} where all build and temporary files should be located. Not a
> failure but annoyance.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-2442) Cassandra unit test intermittent failures
[
https://issues.apache.org/jira/browse/CALCITE-2442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17035388#comment-17035388
]
Andrei Sereda commented on CALCITE-2442:
I think CassandraUnit doesn't properly shutdown the CassandraDaemon
> Cassandra unit test intermittent failures
> -
>
> Key: CALCITE-2442
> URL: https://issues.apache.org/jira/browse/CALCITE-2442
> Project: Calcite
> Issue Type: Bug
> Components: cassandra-adapter
>Reporter: Andrei Sereda
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.22.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> We have noticed that there are failures due to :
> # Wrong parsing of new [JDK version scheme|http://openjdk.java.net/jeps/223]
> (by calcite and cassandra dependencies like jamm). {{10-ea}} vs {{10.0.2}}
> # Cassandra startup timeout on Linux Jenkins CI server. Contrary to github
> travis CI (the one which validates PRs), it takes about 20s for embedded
> cassandra to start (still under investigation).
> # [~Sergey Nuyanzin] reported that
> [CassandraUnit|https://github.com/jsevellec/cassandra-unit] leaves
> {{.toDelete}} folder in maven module folder ({{cassandra/}}) rather than
> {{target/}} where all build and temporary files should be located. Not a
> failure but annoyance.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-2442) Cassandra unit test intermittent failures
[
https://issues.apache.org/jira/browse/CALCITE-2442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17034898#comment-17034898
]
Andrei Sereda commented on CALCITE-2442:
[~donnyzone] Can you pls try https://github.com/apache/calcite/pull/1798 ?
> Cassandra unit test intermittent failures
> -
>
> Key: CALCITE-2442
> URL: https://issues.apache.org/jira/browse/CALCITE-2442
> Project: Calcite
> Issue Type: Bug
> Components: cassandra-adapter
>Reporter: Andrei Sereda
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.22.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> We have noticed that there are failures due to :
> # Wrong parsing of new [JDK version scheme|http://openjdk.java.net/jeps/223]
> (by calcite and cassandra dependencies like jamm). {{10-ea}} vs {{10.0.2}}
> # Cassandra startup timeout on Linux Jenkins CI server. Contrary to github
> travis CI (the one which validates PRs), it takes about 20s for embedded
> cassandra to start (still under investigation).
> # [~Sergey Nuyanzin] reported that
> [CassandraUnit|https://github.com/jsevellec/cassandra-unit] leaves
> {{.toDelete}} folder in maven module folder ({{cassandra/}}) rather than
> {{target/}} where all build and temporary files should be located. Not a
> failure but annoyance.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-2426) Calcite - mongodb - Returns row but no data displayed.
[
https://issues.apache.org/jira/browse/CALCITE-2426?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17022286#comment-17022286
]
Andrei Sereda commented on CALCITE-2426:
Hi Platon,
It is possible this is a bug in mongo adapter. It doesn't handle very well
{{SELECT *}} type of queries.
The only option one can offer right now is explicitly select fields in
projection {{SELECT a, b, c}} which is not ideal, I agree.
I will try to fix this bug in a couple of weeks (quite busy right now).
> Calcite - mongodb - Returns row but no data displayed.
> --
>
> Key: CALCITE-2426
> URL: https://issues.apache.org/jira/browse/CALCITE-2426
> Project: Calcite
> Issue Type: Bug
>Reporter: sathishkumar
>Assignee: Andrei Sereda
>Priority: Critical
>
> sqlline version 1.3.0
> sqlline> !connect
> jdbc:calcite:schemaFactory=org.apache.calcite.adapter.mongodb.MongoSchemaFactory;schema.host=localhost;schema.database=*;
> admin admin
> 0: jdbc:calcite:schemaFactory=org.apache.calc> !tables
>
>
> ++++++---++---++
> |TABLE_CAT|TABLE_SCHEM|TABLE_NAME|TABLE_TYPE|REMARKS|TYPE_CAT|TYPE_SCHEM|TYPE_NAME|SELF_REFERENCING_C|
> ++++++---++---++
> | |adhoc|company_preferences|TABLE| | | | | |
> | |adhoc|property|TABLE| | | | | |
> | |adhoc|templates|TABLE| | | | | |
> | |adhoc|user_preferences|TABLE| | | | | |
> *| | adhoc | users | TABLE | | | | | |*
> | |metadata|COLUMNS|SYSTEM TABLE| | | | | |
> | |metadata|TABLES|SYSTEM TABLE| | | | | |
> ++++++---++---++
> 0: jdbc:calcite:schemaFactory=org.apache.calc> *select * from "users";*
> +--+
> |_MAP|
> +--+
> | |
> +--+
> *1 row selected (0.584 seconds)*
> 0: jdbc:calcite:schemaFactory=org.apache.calc>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (CALCITE-2426) Calcite - mongodb - Returns row but no data displayed.
[ https://issues.apache.org/jira/browse/CALCITE-2426?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Sereda reassigned CALCITE-2426: -- Assignee: Andrei Sereda > Calcite - mongodb - Returns row but no data displayed. > -- > > Key: CALCITE-2426 > URL: https://issues.apache.org/jira/browse/CALCITE-2426 > Project: Calcite > Issue Type: Bug >Reporter: sathishkumar >Assignee: Andrei Sereda >Priority: Critical > > sqlline version 1.3.0 > sqlline> !connect > jdbc:calcite:schemaFactory=org.apache.calcite.adapter.mongodb.MongoSchemaFactory;schema.host=localhost;schema.database=*; > admin admin > 0: jdbc:calcite:schemaFactory=org.apache.calc> !tables > > > ++++++---++---++ > |TABLE_CAT|TABLE_SCHEM|TABLE_NAME|TABLE_TYPE|REMARKS|TYPE_CAT|TYPE_SCHEM|TYPE_NAME|SELF_REFERENCING_C| > ++++++---++---++ > | |adhoc|company_preferences|TABLE| | | | | | > | |adhoc|property|TABLE| | | | | | > | |adhoc|templates|TABLE| | | | | | > | |adhoc|user_preferences|TABLE| | | | | | > *| | adhoc | users | TABLE | | | | | |* > | |metadata|COLUMNS|SYSTEM TABLE| | | | | | > | |metadata|TABLES|SYSTEM TABLE| | | | | | > ++++++---++---++ > 0: jdbc:calcite:schemaFactory=org.apache.calc> *select * from "users";* > +--+ > |_MAP| > +--+ > | | > +--+ > *1 row selected (0.584 seconds)* > 0: jdbc:calcite:schemaFactory=org.apache.calc> -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-3739) Remove failed snapshot track file in Windows OS for Cassandra adapter
[
https://issues.apache.org/jira/browse/CALCITE-3739?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17016480#comment-17016480
]
Andrei Sereda commented on CALCITE-3739:
What is the full path to {{f}} ?
{code:java}
Paths.get(f).toAbsolutePath()
{code}
> Remove failed snapshot track file in Windows OS for Cassandra adapter
> -
>
> Key: CALCITE-3739
> URL: https://issues.apache.org/jira/browse/CALCITE-3739
> Project: Calcite
> Issue Type: Bug
> Components: cassandra-adapter
>Reporter: Feng Zhu
>Priority: Major
> Attachments: screen.png
>
>
> In Windows OS, CassandraUnit leaves an extra "cassandra/.toDelete" snapshot
> track file.
> After migrating to Gradle, it is flagged as "unapproved license" and fails
> on "rat" task.
> It is annoying to manually delete this file every time.
> !screen.png!
> The issue is also mentioned in CALCITE-2442. But I found the snapshot file
> still exists with the fix.
> {code:java}
> @AfterClass
> public static void tearDown() {
> if (RULE instanceof CassandraCQLUnit) {
> CassandraCQLUnit rule = (CassandraCQLUnit) RULE;
> rule.getSession().close();
> rule.getCluster().close();
> // see https://issues.apache.org/jira/browse/CALCITE-2442
> // see https://issues.apache.org/jira/browse/CASSANDRA-13085
> // Is it done by cluster.close() already ?
> if (FBUtilities.isWindows) {
> WindowsFailedSnapshotTracker.deleteOldSnapshots();
> }
> }
> }
> {code}
> I make some profling work. It seems that the snapshot track file is locked by
> other threads.
> "The process cannot access the file because it is being used by another
> process."
> Any ideas?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-3739) Remove failed snapshot track file in Windows OS for Cassandra adapter
[
https://issues.apache.org/jira/browse/CALCITE-3739?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17016440#comment-17016440
]
Andrei Sereda commented on CALCITE-3739:
[~donnyzone] do you have a stack trace with locked threads ?
> Remove failed snapshot track file in Windows OS for Cassandra adapter
> -
>
> Key: CALCITE-3739
> URL: https://issues.apache.org/jira/browse/CALCITE-3739
> Project: Calcite
> Issue Type: Bug
> Components: cassandra-adapter
>Reporter: Feng Zhu
>Priority: Major
> Attachments: screen.png
>
>
> In Windows OS, CassandraUnit leaves an extra "cassandra/.toDelete" snapshot
> track file.
> After migrating to Gradle, it is flagged as "unapproved license" and fails
> on "rat" task.
> It is annoying to manually delete this file every time.
> !screen.png!
> The issue is also mentioned in CALCITE-2442. But I found the snapshot file
> still exists with the fix.
> {code:java}
> @AfterClass
> public static void tearDown() {
> if (RULE instanceof CassandraCQLUnit) {
> CassandraCQLUnit rule = (CassandraCQLUnit) RULE;
> rule.getSession().close();
> rule.getCluster().close();
> // see https://issues.apache.org/jira/browse/CALCITE-2442
> // see https://issues.apache.org/jira/browse/CASSANDRA-13085
> // Is it done by cluster.close() already ?
> if (FBUtilities.isWindows) {
> WindowsFailedSnapshotTracker.deleteOldSnapshots();
> }
> }
> }
> {code}
> I make some profling work. It seems that the snapshot track file is locked by
> other threads.
> "The process cannot access the file because it is being used by another
> process."
> Any ideas?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-3739) Remove failed snapshot track file in Windows OS for Cassandra adapter
[
https://issues.apache.org/jira/browse/CALCITE-3739?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17016425#comment-17016425
]
Andrei Sereda commented on CALCITE-3739:
[~donnyzone] this PR was not yet merged.
Let me take a look right now
> Remove failed snapshot track file in Windows OS for Cassandra adapter
> -
>
> Key: CALCITE-3739
> URL: https://issues.apache.org/jira/browse/CALCITE-3739
> Project: Calcite
> Issue Type: Bug
> Components: cassandra-adapter
>Reporter: Feng Zhu
>Priority: Major
> Attachments: screen.png
>
>
> In Windows OS, CassandraUnit leaves an extra "cassandra/.toDelete" snapshot
> track file.
> After migrating to Gradle, it is flagged as "unapproved license" and fails
> on "rat" task.
> It is annoying to manually delete this file every time.
> !screen.png!
> The issue is also mentioned in CALCITE-2442. But I found the snapshot file
> still exists with the fix.
> {code:java}
> @AfterClass
> public static void tearDown() {
> if (RULE instanceof CassandraCQLUnit) {
> CassandraCQLUnit rule = (CassandraCQLUnit) RULE;
> rule.getSession().close();
> rule.getCluster().close();
> // see https://issues.apache.org/jira/browse/CALCITE-2442
> // see https://issues.apache.org/jira/browse/CASSANDRA-13085
> // Is it done by cluster.close() already ?
> if (FBUtilities.isWindows) {
> WindowsFailedSnapshotTracker.deleteOldSnapshots();
> }
> }
> }
> {code}
> I make some profling work. It seems that the snapshot track file is locked by
> other threads.
> "The process cannot access the file because it is being used by another
> process."
> Any ideas?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-3735) In ImmutableBeans, allow interfaces to have default methods
[ https://issues.apache.org/jira/browse/CALCITE-3735?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17016270#comment-17016270 ] Andrei Sereda commented on CALCITE-3735: Yes, seems like calling interface default methods reflectively in not straight-forward in java. Worst, different code for JDK 8, 9-10, 11. This is one of the advantages of codegen-ed immutable classes. Probably you already saw [Correct Reflective Access to Interface Default Methods in Java 8, 9, 10|https://blog.jooq.org/2018/03/28/correct-reflective-access-to-interface-default-methods-in-java-8-9-10/] post. > In ImmutableBeans, allow interfaces to have default methods > --- > > Key: CALCITE-3735 > URL: https://issues.apache.org/jira/browse/CALCITE-3735 > Project: Calcite > Issue Type: Bug >Reporter: Julian Hyde >Priority: Major > > In ImmutableBeans, allow interfaces to have default methods. > (These are invoked in the usual way by the client. The mechanics are a bit > tricky because they involve method handles, and the APIs are different in JDK > 8 than later JDKs.) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (CALCITE-3560) Additional calcite.util.Source implementation for generic text source (eg. CharSource)
[
https://issues.apache.org/jira/browse/CALCITE-3560?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrei Sereda resolved CALCITE-3560.
Resolution: Fixed
Fixed in
[9e80eb6ed90|https://github.com/apache/calcite/commit/9e80eb6ed90b3f053cdbae2431e96dc09cf81211]
> Additional calcite.util.Source implementation for generic text source (eg.
> CharSource)
> --
>
> Key: CALCITE-3560
> URL: https://issues.apache.org/jira/browse/CALCITE-3560
> Project: Calcite
> Issue Type: Improvement
> Components: csv-adapter, file-adapter
>Affects Versions: 1.21.0
>Reporter: Andrei Sereda
>Assignee: Andrei Sereda
>Priority: Major
> Labels: pull-request-available, pull-requests-available
> Time Spent: 2h 10m
> Remaining Estimate: 0h
>
> Currently calcite {{calcite.util.Source}} interface can be built only from
> [File|https://docs.oracle.com/javase/8/docs/api/java/io/File.html] or
> [URL|https://docs.oracle.com/javase/8/docs/api/java/net/URL.html]. This
> forces data to be stored on disk or accessed remotely using URL api.
> This proposal adds another Source implementation on the top of
> [CharSource|https://guava.dev/releases/19.0/api/docs/com/google/common/io/CharSource.html]
> so calcite adapters can operate on in-memory elements like String or generic
> text sources.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (CALCITE-3281) Support mixed Primitive types for BinaryExpression evaluate method.
[
https://issues.apache.org/jira/browse/CALCITE-3281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrei Sereda reassigned CALCITE-3281:
--
Assignee: Wang Yanlin
> Support mixed Primitive types for BinaryExpression evaluate method.
>
>
> Key: CALCITE-3281
> URL: https://issues.apache.org/jira/browse/CALCITE-3281
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.21.0
>Reporter: Wang Yanlin
>Assignee: Wang Yanlin
>Priority: Major
> Labels: pull-request-available
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Currently, the value of [expression0 and expression1
> |https://github.com/apache/calcite/blob/master/linq4j/src/main/java/org/apache/calcite/linq4j/tree/BinaryExpression.java#L26]
> must be the same type.
> Otherwise, when evaluate, we will get a ClassCastException, something like
> this
> {code:java}
> java.lang.ClassCastException: java.lang.Integer cannot be cast to
> java.lang.Long
> at
> org.apache.calcite.linq4j.tree.BinaryExpression.evaluate(BinaryExpression.java:75)
> at
> org.apache.calcite.linq4j.tree.GotoStatement.evaluate(GotoStatement.java:97)
> at
> org.apache.calcite.linq4j.tree.BlockStatement.evaluate(BlockStatement.java:83)
> at org.apache.calcite.linq4j.tree.Evaluator.evaluate(Evaluator.java:55)
> at
> org.apache.calcite.linq4j.tree.FunctionExpression.lambda$compile$0(FunctionExpression.java:87)
> at
> org.apache.calcite.linq4j.test.ExpressionTest.testLambdaCallsBinaryOpMixType(ExpressionTest.java:349)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
> at
> com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:47)
> at
> com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242)
> at
> com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70)
> {code}
> Actually, we can do something to support mixed primitive types in
> BinaryExpression.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (CALCITE-3281) Support mixed Primitive types for BinaryExpression evaluate method.
[
https://issues.apache.org/jira/browse/CALCITE-3281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrei Sereda resolved CALCITE-3281.
Resolution: Fixed
Fixed in
[67ed3223|https://github.com/apache/calcite/commit/67ed322370472dc4403eed485d0b61fe5a40f84f]
> Support mixed Primitive types for BinaryExpression evaluate method.
>
>
> Key: CALCITE-3281
> URL: https://issues.apache.org/jira/browse/CALCITE-3281
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.21.0
>Reporter: Wang Yanlin
>Priority: Major
> Labels: pull-request-available
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Currently, the value of [expression0 and expression1
> |https://github.com/apache/calcite/blob/master/linq4j/src/main/java/org/apache/calcite/linq4j/tree/BinaryExpression.java#L26]
> must be the same type.
> Otherwise, when evaluate, we will get a ClassCastException, something like
> this
> {code:java}
> java.lang.ClassCastException: java.lang.Integer cannot be cast to
> java.lang.Long
> at
> org.apache.calcite.linq4j.tree.BinaryExpression.evaluate(BinaryExpression.java:75)
> at
> org.apache.calcite.linq4j.tree.GotoStatement.evaluate(GotoStatement.java:97)
> at
> org.apache.calcite.linq4j.tree.BlockStatement.evaluate(BlockStatement.java:83)
> at org.apache.calcite.linq4j.tree.Evaluator.evaluate(Evaluator.java:55)
> at
> org.apache.calcite.linq4j.tree.FunctionExpression.lambda$compile$0(FunctionExpression.java:87)
> at
> org.apache.calcite.linq4j.test.ExpressionTest.testLambdaCallsBinaryOpMixType(ExpressionTest.java:349)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
> at
> com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:47)
> at
> com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242)
> at
> com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70)
> {code}
> Actually, we can do something to support mixed primitive types in
> BinaryExpression.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-3281) Support mixed Primitive types for BinaryExpression evaluate method.
[
https://issues.apache.org/jira/browse/CALCITE-3281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrei Sereda updated CALCITE-3281:
---
Affects Version/s: 1.21.0
> Support mixed Primitive types for BinaryExpression evaluate method.
>
>
> Key: CALCITE-3281
> URL: https://issues.apache.org/jira/browse/CALCITE-3281
> Project: Calcite
> Issue Type: Bug
>Affects Versions: 1.21.0
>Reporter: Wang Yanlin
>Priority: Major
> Labels: pull-request-available
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Currently, the value of [expression0 and expression1
> |https://github.com/apache/calcite/blob/master/linq4j/src/main/java/org/apache/calcite/linq4j/tree/BinaryExpression.java#L26]
> must be the same type.
> Otherwise, when evaluate, we will get a ClassCastException, something like
> this
> {code:java}
> java.lang.ClassCastException: java.lang.Integer cannot be cast to
> java.lang.Long
> at
> org.apache.calcite.linq4j.tree.BinaryExpression.evaluate(BinaryExpression.java:75)
> at
> org.apache.calcite.linq4j.tree.GotoStatement.evaluate(GotoStatement.java:97)
> at
> org.apache.calcite.linq4j.tree.BlockStatement.evaluate(BlockStatement.java:83)
> at org.apache.calcite.linq4j.tree.Evaluator.evaluate(Evaluator.java:55)
> at
> org.apache.calcite.linq4j.tree.FunctionExpression.lambda$compile$0(FunctionExpression.java:87)
> at
> org.apache.calcite.linq4j.test.ExpressionTest.testLambdaCallsBinaryOpMixType(ExpressionTest.java:349)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
> at
> com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:47)
> at
> com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242)
> at
> com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70)
> {code}
> Actually, we can do something to support mixed primitive types in
> BinaryExpression.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-3281) Support mixed Primitive types for BinaryExpression evaluate method.
[
https://issues.apache.org/jira/browse/CALCITE-3281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrei Sereda updated CALCITE-3281:
---
Component/s: core
> Support mixed Primitive types for BinaryExpression evaluate method.
>
>
> Key: CALCITE-3281
> URL: https://issues.apache.org/jira/browse/CALCITE-3281
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.21.0
>Reporter: Wang Yanlin
>Priority: Major
> Labels: pull-request-available
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Currently, the value of [expression0 and expression1
> |https://github.com/apache/calcite/blob/master/linq4j/src/main/java/org/apache/calcite/linq4j/tree/BinaryExpression.java#L26]
> must be the same type.
> Otherwise, when evaluate, we will get a ClassCastException, something like
> this
> {code:java}
> java.lang.ClassCastException: java.lang.Integer cannot be cast to
> java.lang.Long
> at
> org.apache.calcite.linq4j.tree.BinaryExpression.evaluate(BinaryExpression.java:75)
> at
> org.apache.calcite.linq4j.tree.GotoStatement.evaluate(GotoStatement.java:97)
> at
> org.apache.calcite.linq4j.tree.BlockStatement.evaluate(BlockStatement.java:83)
> at org.apache.calcite.linq4j.tree.Evaluator.evaluate(Evaluator.java:55)
> at
> org.apache.calcite.linq4j.tree.FunctionExpression.lambda$compile$0(FunctionExpression.java:87)
> at
> org.apache.calcite.linq4j.test.ExpressionTest.testLambdaCallsBinaryOpMixType(ExpressionTest.java:349)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
> at
> com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:47)
> at
> com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242)
> at
> com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70)
> {code}
> Actually, we can do something to support mixed primitive types in
> BinaryExpression.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (CALCITE-3561) Implement Uncollect relational operator in Interpreter (for SQL queries that use UNNEST)
[
https://issues.apache.org/jira/browse/CALCITE-3561?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrei Sereda resolved CALCITE-3561.
Resolution: Fixed
Fixed in
[f1e51e6c|https://github.com/apache/calcite/commit/f1e51e6c310b68d399b360ff374ffc6d46fefdba]
> Implement Uncollect relational operator in Interpreter (for SQL queries that
> use UNNEST)
>
>
> Key: CALCITE-3561
> URL: https://issues.apache.org/jira/browse/CALCITE-3561
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.21.0
>Reporter: Wang Yanlin
>Assignee: Wang Yanlin
>Priority: Major
> Labels: pull-request-available
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> Using unnest in Interpreter will cause exception,
> {code:java}
> // InterpreterTest
> @Test public void testInterpretUnnest() throws Exception {
> final String sql = "select * from unnest(multiset[1, 2])";
> sql(sql).returnsRows("[1]", "[2]");
> }
> {code}
> got
> {code:java}
> java.lang.AssertionError: interpreter: no implementation for class
> org.apache.calcite.rel.core.Uncollect
> at
> org.apache.calcite.interpreter.Interpreter$CompilerImpl.visit(Interpreter.java:463)
> at
> org.apache.calcite.interpreter.Nodes$CoreCompiler.visit(Nodes.java:44)
> at org.apache.calcite.rel.SingleRel.childrenAccept(SingleRel.java:72)
> at
> org.apache.calcite.interpreter.Interpreter$CompilerImpl.visit(Interpreter.java:450)
> at
> org.apache.calcite.interpreter.Nodes$CoreCompiler.visit(Nodes.java:44)
> at
> org.apache.calcite.interpreter.Interpreter$CompilerImpl.visitRoot(Interpreter.java:408)
> at
> org.apache.calcite.interpreter.Interpreter.(Interpreter.java:89)
> at
> org.apache.calcite.test.InterpreterTest$Sql.returnsRows(InterpreterTest.java:121)
> at
> org.apache.calcite.test.InterpreterTest$Sql.returnsRows(InterpreterTest.java:105)
> at
> org.apache.calcite.test.InterpreterTest.testInterpretUnnest(InterpreterTest.java:446)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> {code}
> Add support to use unnest in Interpreter.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-3561) Implement Uncollect relational operator in Interpreter (for SQL queries that use UNNEST)
[
https://issues.apache.org/jira/browse/CALCITE-3561?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrei Sereda updated CALCITE-3561:
---
Component/s: core
> Implement Uncollect relational operator in Interpreter (for SQL queries that
> use UNNEST)
>
>
> Key: CALCITE-3561
> URL: https://issues.apache.org/jira/browse/CALCITE-3561
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.21.0
>Reporter: Wang Yanlin
>Assignee: Wang Yanlin
>Priority: Major
> Labels: pull-request-available
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> Using unnest in Interpreter will cause exception,
> {code:java}
> // InterpreterTest
> @Test public void testInterpretUnnest() throws Exception {
> final String sql = "select * from unnest(multiset[1, 2])";
> sql(sql).returnsRows("[1]", "[2]");
> }
> {code}
> got
> {code:java}
> java.lang.AssertionError: interpreter: no implementation for class
> org.apache.calcite.rel.core.Uncollect
> at
> org.apache.calcite.interpreter.Interpreter$CompilerImpl.visit(Interpreter.java:463)
> at
> org.apache.calcite.interpreter.Nodes$CoreCompiler.visit(Nodes.java:44)
> at org.apache.calcite.rel.SingleRel.childrenAccept(SingleRel.java:72)
> at
> org.apache.calcite.interpreter.Interpreter$CompilerImpl.visit(Interpreter.java:450)
> at
> org.apache.calcite.interpreter.Nodes$CoreCompiler.visit(Nodes.java:44)
> at
> org.apache.calcite.interpreter.Interpreter$CompilerImpl.visitRoot(Interpreter.java:408)
> at
> org.apache.calcite.interpreter.Interpreter.(Interpreter.java:89)
> at
> org.apache.calcite.test.InterpreterTest$Sql.returnsRows(InterpreterTest.java:121)
> at
> org.apache.calcite.test.InterpreterTest$Sql.returnsRows(InterpreterTest.java:105)
> at
> org.apache.calcite.test.InterpreterTest.testInterpretUnnest(InterpreterTest.java:446)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> {code}
> Add support to use unnest in Interpreter.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-3561) Implement Uncollect relational operator in Interpreter (for SQL queries that use UNNEST)
[
https://issues.apache.org/jira/browse/CALCITE-3561?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrei Sereda updated CALCITE-3561:
---
Affects Version/s: 1.21.0
> Implement Uncollect relational operator in Interpreter (for SQL queries that
> use UNNEST)
>
>
> Key: CALCITE-3561
> URL: https://issues.apache.org/jira/browse/CALCITE-3561
> Project: Calcite
> Issue Type: Improvement
>Affects Versions: 1.21.0
>Reporter: Wang Yanlin
>Assignee: Wang Yanlin
>Priority: Major
> Labels: pull-request-available
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> Using unnest in Interpreter will cause exception,
> {code:java}
> // InterpreterTest
> @Test public void testInterpretUnnest() throws Exception {
> final String sql = "select * from unnest(multiset[1, 2])";
> sql(sql).returnsRows("[1]", "[2]");
> }
> {code}
> got
> {code:java}
> java.lang.AssertionError: interpreter: no implementation for class
> org.apache.calcite.rel.core.Uncollect
> at
> org.apache.calcite.interpreter.Interpreter$CompilerImpl.visit(Interpreter.java:463)
> at
> org.apache.calcite.interpreter.Nodes$CoreCompiler.visit(Nodes.java:44)
> at org.apache.calcite.rel.SingleRel.childrenAccept(SingleRel.java:72)
> at
> org.apache.calcite.interpreter.Interpreter$CompilerImpl.visit(Interpreter.java:450)
> at
> org.apache.calcite.interpreter.Nodes$CoreCompiler.visit(Nodes.java:44)
> at
> org.apache.calcite.interpreter.Interpreter$CompilerImpl.visitRoot(Interpreter.java:408)
> at
> org.apache.calcite.interpreter.Interpreter.(Interpreter.java:89)
> at
> org.apache.calcite.test.InterpreterTest$Sql.returnsRows(InterpreterTest.java:121)
> at
> org.apache.calcite.test.InterpreterTest$Sql.returnsRows(InterpreterTest.java:105)
> at
> org.apache.calcite.test.InterpreterTest.testInterpretUnnest(InterpreterTest.java:446)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> {code}
> Add support to use unnest in Interpreter.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (CALCITE-3567) UNNEST(RECORDTYPE(MAP)) not supported
[
https://issues.apache.org/jira/browse/CALCITE-3567?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrei Sereda resolved CALCITE-3567.
Resolution: Fixed
Fixed in
[560d8951|https://github.com/apache/calcite/commit/560d8951279fddb305626fd3d188b88fbf88b1f9]
> UNNEST(RECORDTYPE(MAP)) not supported
> -
>
> Key: CALCITE-3567
> URL: https://issues.apache.org/jira/browse/CALCITE-3567
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.21.0
>Reporter: Wang Yanlin
>Assignee: Wang Yanlin
>Priority: Major
> Labels: pull-request-available
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> UNNEST(RECORDTYPE(ARRAY)) and UNNEST(RECORDTYPE(MULTISET)) works well, but
> UNNEST(RECORDTYPE(MAP)) is not supported.
> {code:java}
> // JdbcTest
> @Test public void testUnnestRecordType() {
> // unnest(RecordType(Array))
> CalciteAssert.that()
> .query("select * from unnest\n"
> + "(select t.x from (values array[10, 20], array[30, 40]) as
> t(x))\n"
> + " with ordinality as t(a, o)")
> .returnsUnordered("A=10; O=1", "A=20; O=2",
> "A=30; O=1", "A=40; O=2");
> // unnest(RecordType(Multiset))
> CalciteAssert.that()
> .query("select * from unnest\n"
> + "(select t.x from (values multiset[10, 20], array[30, 40]) as
> t(x))\n"
> + " with ordinality as t(a, o)")
> .returnsUnordered("A=10; O=1", "A=20; O=2",
> "A=30; O=1", "A=40; O=2");
> // unnest(RecordType(Map))
> CalciteAssert.that()
> .query("select * from unnest\n"
> + "(select t.x from (values map['a', 20, 'b', 30], map['c', 40])
> as t(x))\n"
> + " with ordinality as t(a, b, o)")
> .returnsUnordered("A=a; B=20; O=1", "A=B; B=30; O=2",
> "A=c; B=40; O=1");
> }
> {code}
> In the case, test for *unnest(RecordType(Array))* and
> *unnest(RecordType(Multiset))* success, but got exception for
> *unnest(RecordType(Map))*.
> For the first two test of *unnest(RecordType(Array))* and
> *unnest(RecordType(Multiset))*, the relnode tree with type is like this
> {noformat}
> EnumerableUncollect(withOrdinality=[true]), type = RecordType(INTEGER EXPR$0,
> INTEGER ORDINALITY)
> EnumerableUnion(all=[true]), type = RecordType(INTEGER ARRAY EXPR$0)
> EnumerableCalc(expr#0=[{inputs}], expr#1=[10], expr#2=[20],
> expr#3=[ARRAY($t1, $t2)], EXPR$0=[$t3]), type = RecordType(INTEGER ARRAY
> EXPR$0)
> EnumerableValues(tuples=[[{ 0 }]]), type = RecordType(INTEGER ZERO)
> EnumerableCalc(expr#0=[{inputs}], expr#1=[30], expr#2=[40],
> expr#3=[ARRAY($t1, $t2)], EXPR$0=[$t3]), type = RecordType(INTEGER ARRAY
> EXPR$0)
> EnumerableValues(tuples=[[{ 0 }]]), type = RecordType(INTEGER ZERO)
> EnumerableUncollect(withOrdinality=[true]), type = RecordType(INTEGER EXPR$0,
> INTEGER ORDINALITY)
> EnumerableUnion(all=[true]), type = RecordType(INTEGER ARRAY EXPR$0)
> EnumerableCalc(expr#0=[{inputs}], expr#1=[$SLICE($t0)], EXPR$0=[$t1]),
> type = RecordType(INTEGER MULTISET EXPR$0)
> EnumerableCollect(field=[EXPR$0]), type = RecordType(RecordType(INTEGER
> ROW_VALUE) MULTISET EXPR$0)
> EnumerableValues(tuples=[[{ 10 }, { 20 }]]), type =
> RecordType(INTEGER ROW_VALUE)
> EnumerableCalc(expr#0=[{inputs}], expr#1=[30], expr#2=[40],
> expr#3=[ARRAY($t1, $t2)], EXPR$0=[$t3]), type = RecordType(INTEGER ARRAY
> EXPR$0)
> EnumerableValues(tuples=[[{ 0 }]]), type = RecordType(INTEGER ZERO)
> {noformat}
> Part of the stacktrace of the exception is:
> {code:java}
> Cannot apply 'UNNEST' to arguments of type 'UNNEST( INTEGER) MAP X)>)'. Supported form(s): 'UNNEST()'
> 'UNNEST()'
> 'UNNEST()'
> UNNEST()
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> at
> org.apache.calcite.runtime.Resources$ExInstWithCause.ex(Resources.java:463)
> at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:839)
> at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:824)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.newValidationError(SqlValidatorImpl.java:4905)
> at
> org.apache.calcite.sql.SqlCallBinding.newValidationSignatureError(SqlCallBinding.java:280)
> at
> org.apache.calcite.sql.type.CompositeOperandTypeChecker.checkOperandTypes(CompositeOperandTypeChecker.java:261)
> at
>
