[jira] [Commented] (CALCITE-4639) Broken links on download page
[ https://issues.apache.org/jira/browse/CALCITE-4639?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17428607#comment-17428607 ] duan xiong commented on CALCITE-4639: - [~julianhyde] Ok. I will finish this as soon as possible. > Broken links on download page > - > > Key: CALCITE-4639 > URL: https://issues.apache.org/jira/browse/CALCITE-4639 > Project: Calcite > Issue Type: Bug >Reporter: Sebb >Priority: Major > Attachments: 捕获.PNG > > > There are lots of broken links on the download page. > These are mainly because early releases did not have separate sha256 hashes. > For example: apache-calcite-1.13.0-src.tar.gz.sha256 is missing; should be > apache-calcite-1.13.0-src.tar.gz.mds > Wrong file name: apache-optiq-0.9.0-incubating-src should be > apache-optiq-0.9.0-incubating-source-release > Could not find any instances of calcite 0.8 or optiq 0.8 > Was that release before the ASF? > Please fix the links and test them. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-4774) When predicate conditions are equivalent, materialized view recognition fails.
[
https://issues.apache.org/jira/browse/CALCITE-4774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17428597#comment-17428597
]
Julian Hyde commented on CALCITE-4774:
--
Those two tests are so similar that it took me five minutes to see what was
different. Tests such as these need commentary explaining what they are trying
to test.
> When predicate conditions are equivalent, materialized view recognition fails.
> --
>
> Key: CALCITE-4774
> URL: https://issues.apache.org/jira/browse/CALCITE-4774
> Project: Calcite
> Issue Type: Improvement
>Reporter: xzh_dz
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.28.0
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> {code:java}
> // code placeholder
> org.apache.calcite.test.MaterializedViewSubstitutionVisitorTest
> @Test void testRexCondition() {
> final String mv = ""
> + "select \"name\"\n"
> + "from \"emps\"\n"
> + "where \"deptno\" > 100 and \"deptno\" > 50\n"
> + "group by \"name\"";
> final String query = ""
> + "select \"name\"\n"
> + "from \"emps\"\n"
> + "where \"deptno\" > 100"
> + "group by \"name\"";
> sql(mv, query).withChecker(
> resultContains(""
> + "EnumerableTableScan(table=[[hr, MV0]])")).ok();
> }
> {code}
> Materialized view failed to be matched by optimized results:Materialized view
> failed to be matched by optimized results: java.lang.AssertionError:
> Materialized view failed to be matched by optimized results: at
> org.apache.calcite.test.AbstractMaterializedViewTest.checkMaterialize(AbstractMaterializedViewTest.java:116)
> at
> org.apache.calcite.test.AbstractMaterializedViewTest.access$000(AbstractMaterializedViewTest.java:67)
> at
> org.apache.calcite.test.AbstractMaterializedViewTest$Sql.ok(AbstractMaterializedViewTest.java:229)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (CALCITE-4550) Simplify JaninoRelMetadataProvider API for binding methods
[ https://issues.apache.org/jira/browse/CALCITE-4550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jesus Camacho Rodriguez resolved CALCITE-4550. -- Fix Version/s: 1.28.0 Resolution: Fixed Fixed in [77ff9f6|https://github.com/apache/calcite/commit/77ff9f6145272a899f694c6a2d8ab8ff5422d0c6]. Thanks [~jamesstarr]! > Simplify JaninoRelMetadataProvider API for binding methods > -- > > Key: CALCITE-4550 > URL: https://issues.apache.org/jira/browse/CALCITE-4550 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: James Starr >Assignee: James Starr >Priority: Major > Labels: pull-request-available > Fix For: 1.28.0 > > Time Spent: 1h 20m > Remaining Estimate: 0h > > JaninoRelMetadataProvider uses the a complicated convention for binding > handler instances to a the dynamically created handler. It requires the > method to stated once in Metadata, then again MetadataHandler with slightly > different signature and finally again a reference to the Metadata method must > be included MetadataDef. This is needlessly rather complicated and verbose > for something that is trying to reduce boiler plate. > Having JaninoRelMetadataProvider get the declared methods directly from the > handler interface would decouple JaninoRelMetadataProvider from method > definitions in Metadata and MetadataDef. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-4843) optimize ALL,SOME sub-query list when op is the <, <=,> or >=
[
https://issues.apache.org/jira/browse/CALCITE-4843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17428574#comment-17428574
]
Chunwei Lei commented on CALCITE-4843:
--
The optimization is positive. But I wonder if the user would write such query.
> optimize ALL,SOME sub-query list when op is the <, <=,> or >=
> -
>
> Key: CALCITE-4843
> URL: https://issues.apache.org/jira/browse/CALCITE-4843
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.27.0
>Reporter: duan xiong
>Assignee: duan xiong
>Priority: Major
>
> some example:
> {code:java}
> sal > all (values 1, 2, 3, 4, 5, 6, 7, null) can be optimized to
> sal>all(values 7, null)
> sal > some(values 1, 2, 3, 4, 5, 6, 7, null) can be optimized to
> sal>some(values 1, null){code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-4848) Adding a HAVING condition to a query with a dynamic parameter makes the result always empty
[
https://issues.apache.org/jira/browse/CALCITE-4848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17428573#comment-17428573
]
Chunwei Lei commented on CALCITE-4848:
--
The PR looks good to me.
> Adding a HAVING condition to a query with a dynamic parameter makes the
> result always empty
> ---
>
> Key: CALCITE-4848
> URL: https://issues.apache.org/jira/browse/CALCITE-4848
> Project: Calcite
> Issue Type: Bug
>Affects Versions: 1.27.0
>Reporter: Thomas Rebele
>Assignee: Thomas Rebele
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.28.0
>
> Attachments: CALCITE-4848.patch
>
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> The query
> {code:java}
> SELECT sal, COUNT(1) AS count_val
> FROM emp t WHERE sal = ?
> GROUP BY sal HAVING sal < 1000 {code}
> gets translated to the following logical plan:
> {code:java}
> LogicalFilter(condition=[<($0, 1000)])
> LogicalAggregate(group=[{0}], COUNT_VAL=[COUNT()])
> LogicalProject(SAL=[$5], $f1=[1])
> LogicalFilter(condition=[=($5, ?0)])
> LogicalTableScan(table=[[CATALOG, SALES, EMP]]) {code}
> However, applying CoreRules.FILTER_REDUCE_EXPRESSIONS to the plan it just
> becomes
> {code:java}
> LogicalValues(tuples=[[]]) {code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-4849) Query SQL cannot complete materialized view rewrite properly
[
https://issues.apache.org/jira/browse/CALCITE-4849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17428570#comment-17428570
]
Chunwei Lei commented on CALCITE-4849:
--
It would be great if you can provide a test case to reproduce it, [~jhkcool].
> Query SQL cannot complete materialized view rewrite properly
> -
>
> Key: CALCITE-4849
> URL: https://issues.apache.org/jira/browse/CALCITE-4849
> Project: Calcite
> Issue Type: Bug
>Affects Versions: 1.27.0
>Reporter: jhkcool
>Priority: Major
>
> {code:java}
> #materialization view MV:
> SELECT name,age FROM test WHERE age>20
> #query sql:
> SELECT name FROM test WHERE age>30
> #expect results after rewriting
> SELECT name FROM MV WHERE age>30
> {code}
> but there is a exception:
> {code:java}
> e.message: source #1 has no target in mapping [size=1, sourceCount=2,
> targetCount=1, elements=[0:0]]
> Java exception follows:
> org.apache.calcite.util.mapping.Mappings$NoElementException: source #1 has no
> target in mapping [size=1, sourceCount=2, targetCount=1, elements=[0:0]]
> at
> org.apache.calcite.util.mapping.Mappings$AbstractMapping.getTarget(Mappings.java:944)
> at
> org.apache.calcite.rex.RexPermuteInputsShuttle.visitInputRef(RexPermuteInputsShuttle.java:87)
> at
> org.apache.calcite.rex.RexPermuteInputsShuttle.visitInputRef(RexPermuteInputsShuttle.java:35)
> at org.apache.calcite.rex.RexInputRef.accept(RexInputRef.java:114)
> at org.apache.calcite.rex.RexShuttle.visitList(RexShuttle.java:161)
> at org.apache.calcite.rex.RexShuttle.visitCall(RexShuttle.java:113)
> at
> org.apache.calcite.rex.RexPermuteInputsShuttle.visitCall(RexPermuteInputsShuttle.java:102)
> at
> org.apache.calcite.rex.RexPermuteInputsShuttle.visitCall(RexPermuteInputsShuttle.java:35)
> at org.apache.calcite.rex.RexCall.accept(RexCall.java:189)
> at
> org.apache.calcite.sql2rel.RelFieldTrimmer.trimFields(RelFieldTrimmer.java:438)
> at sun.reflect.GeneratedMethodAccessor17.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.apache.calcite.util.ReflectUtil$2.invoke(ReflectUtil.java:531)
> at
> org.apache.calcite.sql2rel.RelFieldTrimmer.dispatchTrimFields(RelFieldTrimmer.java:284)
> at
> org.apache.calcite.sql2rel.RelFieldTrimmer.trim(RelFieldTrimmer.java:171)
> at
> org.apache.calcite.plan.RelOptMaterializations.trimUnusedfields(RelOptMaterializations.java:232)
> at
> org.apache.calcite.plan.RelOptMaterializations.substitute(RelOptMaterializations.java:187)
> at
> org.apache.calcite.plan.RelOptMaterializations.useMaterializedViews(RelOptMaterializations.java:73)
> at
> org.apache.calcite.plan.volcano.VolcanoPlanner.registerMaterializations(VolcanoPlanner.java:323)
> at
> org.apache.calcite.plan.volcano.VolcanoPlanner.findBestExp(VolcanoPlanner.java:527)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-4639) Broken links on download page
[ https://issues.apache.org/jira/browse/CALCITE-4639?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17428548#comment-17428548 ] Julian Hyde commented on CALCITE-4639: -- I've put out an appeal on dev@. This issue doesn't need to be fixed before 1.28 but it needs to be fixed before we announce the release (probably in the next 7 days). > Broken links on download page > - > > Key: CALCITE-4639 > URL: https://issues.apache.org/jira/browse/CALCITE-4639 > Project: Calcite > Issue Type: Bug >Reporter: Sebb >Priority: Major > Attachments: 捕获.PNG > > > There are lots of broken links on the download page. > These are mainly because early releases did not have separate sha256 hashes. > For example: apache-calcite-1.13.0-src.tar.gz.sha256 is missing; should be > apache-calcite-1.13.0-src.tar.gz.mds > Wrong file name: apache-optiq-0.9.0-incubating-src should be > apache-optiq-0.9.0-incubating-source-release > Could not find any instances of calcite 0.8 or optiq 0.8 > Was that release before the ASF? > Please fix the links and test them. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-4842) Nested row type fails with unsupported type Record2_2
[
https://issues.apache.org/jira/browse/CALCITE-4842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17428543#comment-17428543
]
Julian Hyde commented on CALCITE-4842:
--
This fix is adding some non-trivial concepts to the type system. There need to
be more tests than simply one or two queries, more documentation and code
structure.
> Nested row type fails with unsupported type Record2_2
> -
>
> Key: CALCITE-4842
> URL: https://issues.apache.org/jira/browse/CALCITE-4842
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.27.0
>Reporter: Sergey Nuyanzin
>Priority: Major
> Labels: pull-request-available
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Queries with nested rows fail with the exception below
> for instance these queries could be used to reproduce
> {code:sql}
> select row(row(1));
> select row(row(1, 2), row(3, 4));
> {code}
> At the same time
> {code:sql}
> select array[row(row(1))];
> select array[row(row(1, 2), row(3, 4))];
> {code}
> are ok
> {noformat}
> java.sql.SQLException: Error while executing SQL "select row(row(1))":
> unsupported type Record1_0
> 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.execute(AvaticaStatement.java:217)
> at sqlline.Commands.executeSingleQuery(Commands.java:1130)
> at sqlline.Commands.execute(Commands.java:1079)
> at sqlline.Commands.sql(Commands.java:1033)
> at sqlline.SqlLine.dispatch(SqlLine.java:822)
> at sqlline.SqlLine.begin(SqlLine.java:596)
> at sqlline.SqlLine.start(SqlLine.java:269)
> at sqlline.SqlLine.main(SqlLine.java:208)
> Caused by: java.lang.RuntimeException: unsupported type Record1_0
> at org.apache.calcite.linq4j.tree.Types.toClass(Types.java:152)
> at org.apache.calcite.linq4j.tree.Types.toClassArray(Types.java:166)
> at org.apache.calcite.linq4j.tree.Expressions.call(Expressions.java:449)
> at
> org.apache.calcite.adapter.enumerable.EnumerableRelImplementor.classDecl(EnumerableRelImplementor.java:292)
> at
> org.apache.calcite.adapter.enumerable.EnumerableRelImplementor.access$000(EnumerableRelImplementor.java:79)
> at
> org.apache.calcite.adapter.enumerable.EnumerableRelImplementor$TypeRegistrar.register(EnumerableRelImplementor.java:562)
> at
> org.apache.calcite.adapter.enumerable.EnumerableRelImplementor$TypeRegistrar.register(EnumerableRelImplementor.java:566)
> at
> org.apache.calcite.adapter.enumerable.EnumerableRelImplementor$TypeRegistrar.go(EnumerableRelImplementor.java:576)
> at
> org.apache.calcite.adapter.enumerable.EnumerableRelImplementor.implementRoot(EnumerableRelImplementor.java:146)
> at
> org.apache.calcite.adapter.enumerable.EnumerableInterpretable.toBindable(EnumerableInterpretable.java:113)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl$CalcitePreparingStmt.implement(CalcitePrepareImpl.java:1130)
> at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:318)
> at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:215)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl.prepare2_(CalcitePrepareImpl.java:647)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl.prepare_(CalcitePrepareImpl.java:513)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl.prepareSql(CalcitePrepareImpl.java:483)
> at
> org.apache.calcite.jdbc.CalciteConnectionImpl.parseQuery(CalciteConnectionImpl.java:249)
> at
> org.apache.calcite.jdbc.CalciteMetaImpl.prepareAndExecute(CalciteMetaImpl.java:623)
> at
> org.apache.calcite.avatica.AvaticaConnection.prepareAndExecuteInternal(AvaticaConnection.java:675)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:156)
> ... 8 more
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (CALCITE-4762) Upgrade Calcite to Avatica 1.19
[ https://issues.apache.org/jira/browse/CALCITE-4762?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Hyde resolved CALCITE-4762. -- Resolution: Fixed Fixed in [d0837f17|https://github.com/apache/calcite/commit/d0837f171c783180cb1e44aa1bafd99e568d2f3e]. > Upgrade Calcite to Avatica 1.19 > --- > > Key: CALCITE-4762 > URL: https://issues.apache.org/jira/browse/CALCITE-4762 > Project: Calcite > Issue Type: Bug > Components: jdbc-driver >Reporter: Julian Hyde >Assignee: Julian Hyde >Priority: Major > Labels: pull-request-available > Fix For: 1.28.0 > > Time Spent: 10m > Remaining Estimate: 0h > > Upgrade Calcite to Avatica version 1.19. > Currently version 1.19 has not been released. > 1.19 fixes at least one issue whose test cases are attached as PRs. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-4600) ClassCastException retrieving from an ARRAY that has DATE, TIME or TIMESTAMP elements
[
https://issues.apache.org/jira/browse/CALCITE-4600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17428539#comment-17428539
]
Julian Hyde commented on CALCITE-4600:
--
Added a test to Calcite in
[95b3ab6a|https://github.com/apache/calcite/commit/95b3ab6abd7b0272fff977472633926fde9b9495].
> ClassCastException retrieving from an ARRAY that has DATE, TIME or TIMESTAMP
> elements
> -
>
> Key: CALCITE-4600
> URL: https://issues.apache.org/jira/browse/CALCITE-4600
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Affects Versions: avatica-1.17.0
>Reporter: Sergey Nuyanzin
>Assignee: Sergey Nuyanzin
>Priority: Major
> Labels: pull-request-available
> Fix For: avatica-1.19.0
>
> Time Spent: 2h 20m
> Remaining Estimate: 0h
>
> cases to reproduce
> {code:sql}
> select array[current_date];
> select array[cast('1900-1-1' as date)];
> select array[current_timestamp];
> select array[current_time];
> {code}
> each query fails with {{ClassCastException}} mentioned below.
> It seems the reason is that date/time/timestamp could be both int/long and
> java_sql_*.
> {noformat}
> class java.sql.Date cannot be cast to class java.lang.Number (java.sql.Date
> is in module java.sql of loader 'platform'; java.lang.Number is in module
> java.base of loader 'bootstrap')
> java.lang.ClassCastException: class java.sql.Date cannot be cast to class
> java.lang.Number (java.sql.Date is in module java.sql of loader 'platform';
> java.lang.Number is in module java.base of loader 'bootstrap')
> at
> org.apache.calcite.avatica.util.AbstractCursor$NumberAccessor.getNumber(AbstractCursor.java:722)
> at
> org.apache.calcite.avatica.util.AbstractCursor$DateFromNumberAccessor.getString(AbstractCursor.java:928)
> at org.apache.calcite.avatica.util.ArrayImpl.toString(ArrayImpl.java:62)
> at
> org.apache.calcite.avatica.util.AbstractCursor$ArrayAccessor.getString(AbstractCursor.java:1365)
> at
> org.apache.calcite.avatica.AvaticaResultSet.getString(AvaticaResultSet.java:239)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-4602) ClassCastException retrieving from ARRAY that has mixed INTEGER and DECIMAL elements
[
https://issues.apache.org/jira/browse/CALCITE-4602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17428538#comment-17428538
]
Julian Hyde commented on CALCITE-4602:
--
Added a test in Calcite in
[c3f3decd3|https://github.com/apache/calcite/commit/c3f3decd39c29d85bd5ec659ebcec853e2f337ff].
The test expects output that is 'wrong' due to CALCITE-4850, and the expected
output will be changed when that bug is fixed.
> ClassCastException retrieving from ARRAY that has mixed INTEGER and DECIMAL
> elements
>
>
> Key: CALCITE-4602
> URL: https://issues.apache.org/jira/browse/CALCITE-4602
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Affects Versions: avatica-1.17.0
>Reporter: Sergey Nuyanzin
>Assignee: Sergey Nuyanzin
>Priority: Major
> Labels: pull-request-available
> Fix For: avatica-1.19.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Cases to reproduce: any query with array containing both int and bigdecimal
> elements for instance
> {code:sql}
> select array[1, 1.1];
> select array[1.1, 1];
> {code}
> which leads to ClassCastException
> {noformat}
> class java.lang.Integer cannot be cast to class java.math.BigDecimal
> (java.lang.Integer and java.math.BigDecimal are in module java.base of loader
> 'bootstrap')
> java.lang.ClassCastException: class java.lang.Integer cannot be cast to class
> java.math.BigDecimal (java.lang.Integer and java.math.BigDecimal are in
> module java.base of loader 'bootstrap')
> at
> org.apache.calcite.avatica.util.AbstractCursor$BigDecimalAccessor.getBigDecimal(AbstractCursor.java:701)
> at
> org.apache.calcite.avatica.util.AbstractCursor$ArrayAccessor.convertValue(AbstractCursor.java:1338)
> at
> org.apache.calcite.avatica.util.AbstractCursor$ArrayAccessor.getObject(AbstractCursor.java:1299)
> at
> org.apache.calcite.avatica.util.AbstractCursor$ArrayAccessor.getArray(AbstractCursor.java:1352)
> at
> org.apache.calcite.avatica.util.AbstractCursor$ArrayAccessor.getString(AbstractCursor.java:1364)
> at
> org.apache.calcite.avatica.AvaticaResultSet.getString(AvaticaResultSet.java:239)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-4847) Parse SQL with BigQuery-style quoted identifiers and character literals
[
https://issues.apache.org/jira/browse/CALCITE-4847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17428537#comment-17428537
]
Jack Scott commented on CALCITE-4847:
-
Thanks Julian!
> Parse SQL with BigQuery-style quoted identifiers and character literals
> ---
>
> Key: CALCITE-4847
> URL: https://issues.apache.org/jira/browse/CALCITE-4847
> Project: Calcite
> Issue Type: Bug
>Reporter: Julian Hyde
>Assignee: Julian Hyde
>Priority: Major
> Fix For: 1.28.0
>
>
> Parse SQL with BigQuery-style quoted identifiers and character literals.
> BigQuery quotes identifiers using backticks, escaping interior backticks
> using backslash. In CALCITE-4767 we added {{Quoting.BACK_TICK_BACKSLASH}} to
> distinguish this style from what MySQL does, namely {{Quoting.BACK_TICK}}.
> BigQuery quotes character literals using double quotes, escaping interior
> double quotes using backslash. In CALCITE-4767 we added
> {{Quoting.DOUBLE_QUOTE_BACKSLASH}} to distinguish this style from
> {{Quoting.DOUBLE_QUOTE}}.
> After this change, we should be able to parse the following query if we
> invoke the parser with {{lex=BIG_QUERY}} or {{dialect=BIG_QUERY}}:
> {code}
> SELECT "a \"quoted\" char literal"
> FROM `a \`quoted\` table`
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-4757) In Avatica, support columns of type "NULL" in query results
[
https://issues.apache.org/jira/browse/CALCITE-4757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17428536#comment-17428536
]
Julian Hyde commented on CALCITE-4757:
--
Added a test in Calcite in
[a7728d79|https://github.com/apache/calcite/commit/a7728d79878a6e4c063e7646cd4e6f4f1ce9c2ea].
> In Avatica, support columns of type "NULL" in query results
> ---
>
> Key: CALCITE-4757
> URL: https://issues.apache.org/jira/browse/CALCITE-4757
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Affects Versions: avatica-1.18.0
>Reporter: duan xiong
>Assignee: duan xiong
>Priority: Major
> Fix For: avatica-1.19.0
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> When I run:
> {code:java}
> select * from (values(null,true))
> {code}
> Caused by: java.lang.RuntimeException: unknown type 0.
> Looks like AvaticaSite can't handle Types.NULL.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (CALCITE-4628) If SqlImplementor fails, include the RelNode in the exception
[
https://issues.apache.org/jira/browse/CALCITE-4628?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde resolved CALCITE-4628.
--
Resolution: Fixed
Fixed in
[342aeba1|https://github.com/apache/calcite/commit/342aeba1087857df48891655cf0de41d5f3479c7].
> If SqlImplementor fails, include the RelNode in the exception
> -
>
> Key: CALCITE-4628
> URL: https://issues.apache.org/jira/browse/CALCITE-4628
> Project: Calcite
> Issue Type: Bug
>Reporter: Julian Hyde
>Assignee: Julian Hyde
>Priority: Major
> Fix For: 1.28.0
>
>
> If {{SqlImplementor}} fails, include the {{RelNode}} in the exception. (For
> example, we recently encountered a
> {{java.lang.ArrayIndexOutOfBoundsException}} where the problem was in the
> {{RelNode}} but the {{RelNode}} was not in the stack.)
> Add a catch block that calls
> [Util.throwAsRuntime|https://github.com/apache/calcite/blob/f1309fa3af6826e73377e54081160228eb7ab951/core/src/main/java/org/apache/calcite/util/Util.java#L961]
> to the {{SqlImplementor.visitRoot}} method. That method seems to be a widely
> used entry point.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-4795) In class SqlBasicCall, make the "operands" field private
[
https://issues.apache.org/jira/browse/CALCITE-4795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17428534#comment-17428534
]
Julian Hyde commented on CALCITE-4795:
--
The first part of this change, where we deprecate the {{operands}} field is
merged as
[a250ab0d|https://github.com/apache/calcite/commit/a250ab0de827f221eb0bec780f5454f33cd7e782].
The second part, where we make the {{operands}} field a private list, will
follow after release 1.28.
> In class SqlBasicCall, make the "operands" field private
>
>
> Key: CALCITE-4795
> URL: https://issues.apache.org/jira/browse/CALCITE-4795
> Project: Calcite
> Issue Type: Bug
>Reporter: Julian Hyde
>Assignee: Julian Hyde
>Priority: Major
> Fix For: 1.28.0
>
>
> In {{class SqlBasicCall}}, the {{operands}}
> [field|https://github.com/apache/calcite/blob/4bc916619fd286b2c0cc4d5c653c96a68801d74e/core/src/main/java/org/apache/calcite/sql/SqlBasicCall.java#L34]
> is a {{public}} array. This seems crazy to me – any client might be writing
> into that field at any time. I propose to make the field private.
> This presents some compatibility problems, because people might be depending
> on the field. So I propose a quick deprecation and removal:
> * In release 1.28 (the next release, as I write this) the field and the
> {{public SqlNode[] getOperands()}} method will be marked deprecated. We will
> mirror into another field, {{private final List operandList =
> Arrays.asList(operands);}} We can replace all uses of the {{operands}} field
> in Calcite with uses of the new {{operandList}} field.
> * In release 1.29 (the release after next) the {{operands}} field and the
> {{getOperands()}} method will be removed. People can operate using
> {{List getOperandList()}} and {{setOperand(int, SqlNode)}} methods
> that are inherited from {{SqlCall}}.
> After the field is a private list, we could consider making it an immutable
> list. The list would be copied when people call {{setOperand}}, but would not
> need to be cloned when the {{SqlBasicCall}} is created or cloned.
> This case completes the work started in CALCITE-147.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-4795) In class SqlBasicCall, make the "operands" field private
[
https://issues.apache.org/jira/browse/CALCITE-4795?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde updated CALCITE-4795:
-
Fix Version/s: (was: 1.28.0)
1.29.0
> In class SqlBasicCall, make the "operands" field private
>
>
> Key: CALCITE-4795
> URL: https://issues.apache.org/jira/browse/CALCITE-4795
> Project: Calcite
> Issue Type: Bug
>Reporter: Julian Hyde
>Assignee: Julian Hyde
>Priority: Major
> Fix For: 1.29.0
>
>
> In {{class SqlBasicCall}}, the {{operands}}
> [field|https://github.com/apache/calcite/blob/4bc916619fd286b2c0cc4d5c653c96a68801d74e/core/src/main/java/org/apache/calcite/sql/SqlBasicCall.java#L34]
> is a {{public}} array. This seems crazy to me – any client might be writing
> into that field at any time. I propose to make the field private.
> This presents some compatibility problems, because people might be depending
> on the field. So I propose a quick deprecation and removal:
> * In release 1.28 (the next release, as I write this) the field and the
> {{public SqlNode[] getOperands()}} method will be marked deprecated. We will
> mirror into another field, {{private final List operandList =
> Arrays.asList(operands);}} We can replace all uses of the {{operands}} field
> in Calcite with uses of the new {{operandList}} field.
> * In release 1.29 (the release after next) the {{operands}} field and the
> {{getOperands()}} method will be removed. People can operate using
> {{List getOperandList()}} and {{setOperand(int, SqlNode)}} methods
> that are inherited from {{SqlCall}}.
> After the field is a private list, we could consider making it an immutable
> list. The list would be copied when people call {{setOperand}}, but would not
> need to be cloned when the {{SqlBasicCall}} is created or cloned.
> This case completes the work started in CALCITE-147.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (CALCITE-4847) Parse SQL with BigQuery-style quoted identifiers and character literals
[
https://issues.apache.org/jira/browse/CALCITE-4847?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde resolved CALCITE-4847.
--
Resolution: Fixed
Fixed in
[c2d0d66|https://github.com/apache/calcite/commit/c2d0d66722212f3cc674bcac26376195bfe6f1af].
> Parse SQL with BigQuery-style quoted identifiers and character literals
> ---
>
> Key: CALCITE-4847
> URL: https://issues.apache.org/jira/browse/CALCITE-4847
> Project: Calcite
> Issue Type: Bug
>Reporter: Julian Hyde
>Assignee: Julian Hyde
>Priority: Major
> Fix For: 1.28.0
>
>
> Parse SQL with BigQuery-style quoted identifiers and character literals.
> BigQuery quotes identifiers using backticks, escaping interior backticks
> using backslash. In CALCITE-4767 we added {{Quoting.BACK_TICK_BACKSLASH}} to
> distinguish this style from what MySQL does, namely {{Quoting.BACK_TICK}}.
> BigQuery quotes character literals using double quotes, escaping interior
> double quotes using backslash. In CALCITE-4767 we added
> {{Quoting.DOUBLE_QUOTE_BACKSLASH}} to distinguish this style from
> {{Quoting.DOUBLE_QUOTE}}.
> After this change, we should be able to parse the following query if we
> invoke the parser with {{lex=BIG_QUERY}} or {{dialect=BIG_QUERY}}:
> {code}
> SELECT "a \"quoted\" char literal"
> FROM `a \`quoted\` table`
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (CALCITE-4616) AggregateUnionTransposeRule causes row type mismatch when some inputs have unique grouping key
[
https://issues.apache.org/jira/browse/CALCITE-4616?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde resolved CALCITE-4616.
--
Resolution: Fixed
Fixed in
[94812771|https://github.com/apache/calcite/commit/948127710f7fb44b795b25dfb4d9c2214c1392c7];
thanks for the PR, [~vozerov]!
> AggregateUnionTransposeRule causes row type mismatch when some inputs have
> unique grouping key
> --
>
> Key: CALCITE-4616
> URL: https://issues.apache.org/jira/browse/CALCITE-4616
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.26.0
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.28.0
>
> Time Spent: 2h
> Remaining Estimate: 0h
>
> Consider the following relational tree:
> {code}
> 1: Aggregate[group=a, SUM(b)]
> 2: Union
> 3: Input1[a, b, c]
> 4: Input2[a, b, c]
> {code}
> It may happen, that {{Input1}} has a unique key on {{[a]}}. In this case,
> Apache Calcite, will not install the {{Aggregate}} on top of it, which leads
> to the following tree:
> {code}
> 1: Aggregate[group=a, SUM(b)]
> 2: Union
> 3: Input1[a, b, c]
> 4: Aggregate[group=a, SUM(b)]
> 5: Input2[a, b, c]
> {code}
> Obviously, the tree is incorrect, because {{Union}} inputs now have different
> row types.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (CALCITE-4740) JDBC adapter generates incorrect HAVING clause in BigQuery dialect
[
https://issues.apache.org/jira/browse/CALCITE-4740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17428531#comment-17428531
]
Julian Hyde edited comment on CALCITE-4740 at 10/13/21, 11:27 PM:
--
Fixed in
[e20f8819|https://github.com/apache/calcite/commit/e20f8819e8017e9bde7317a43f2c56cb39bdab8d];
thanks for the PR, [~yanjing.wang]!
Quite a lot of your commit was refactoring all of the occurrences of "EXPR$"
into one place, so I split that out as a separate refactoring commit.
was (Author: julianhyde):
Fixed in
[e20f8819|https://github.com/apache/calcite/commit/e20f8819e8017e9bde7317a43f2c56cb39bdab8d];
thanks for the PR, [~yanjing.wang]!
> JDBC adapter generates incorrect HAVING clause in BigQuery dialect
> --
>
> Key: CALCITE-4740
> URL: https://issues.apache.org/jira/browse/CALCITE-4740
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.27.0
> Environment: jdk8
> macos
>Reporter: yanjing.wang
>Priority: Minor
> Labels: pull-request-available
> Fix For: 1.28.0
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> I'm converting
> {code:java}
> String query = select
> "product_id" , sum("shelf_width")
> from "foodmart"."product"
> where "product_id" > 0
> group by "product_id" having sum("shelf_width") > 1{code}
> with big query dialect, but results
> {code:java}
> SELECT product_id, SUM(shelf_width)
> FROM foodmart.product
> WHERE product_id > 0
> GROUP BY product_id
> HAVING `EXPR$1` > 1
> {code}
> Maybe we need replace having clause aliases when stripping trivial aliases.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (CALCITE-4740) JDBC adapter generates incorrect HAVING clause in BigQuery dialect
[
https://issues.apache.org/jira/browse/CALCITE-4740?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde resolved CALCITE-4740.
--
Resolution: Fixed
Fixed in
[e20f8819|https://github.com/apache/calcite/commit/e20f8819e8017e9bde7317a43f2c56cb39bdab8d];
thanks for the PR, [~yanjing.wang]!
> JDBC adapter generates incorrect HAVING clause in BigQuery dialect
> --
>
> Key: CALCITE-4740
> URL: https://issues.apache.org/jira/browse/CALCITE-4740
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.27.0
> Environment: jdk8
> macos
>Reporter: yanjing.wang
>Priority: Minor
> Labels: pull-request-available
> Fix For: 1.28.0
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> I'm converting
> {code:java}
> String query = select
> "product_id" , sum("shelf_width")
> from "foodmart"."product"
> where "product_id" > 0
> group by "product_id" having sum("shelf_width") > 1{code}
> with big query dialect, but results
> {code:java}
> SELECT product_id, SUM(shelf_width)
> FROM foodmart.product
> WHERE product_id > 0
> GROUP BY product_id
> HAVING `EXPR$1` > 1
> {code}
> Maybe we need replace having clause aliases when stripping trivial aliases.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (CALCITE-2736) ReduceExpressionsRule never reduces dynamic expressions but this should be configurable
[
https://issues.apache.org/jira/browse/CALCITE-2736?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde resolved CALCITE-2736.
--
Fix Version/s: 1.28.0
Resolution: Fixed
Fixed in
[82dd78a1|https://github.com/apache/calcite/commit/82dd78a14f6aef2eeec2f9c94978d04b4acc5359];
thanks for the PR, [~yingyu]! I fixed up your code for recent changes to
{{ReduceExpressionsRule.Config}} in CALCITE-4830.
> ReduceExpressionsRule never reduces dynamic expressions but this should be
> configurable
> ---
>
> Key: CALCITE-2736
> URL: https://issues.apache.org/jira/browse/CALCITE-2736
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: Jacques Nadeau
>Assignee: Jacques Nadeau
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.28.0
>
> Time Spent: 2h
> Remaining Estimate: 0h
>
> There are situations where it is helpful to reduce dynamic SqlCalls. Right
> now, the ReduceExpressionsRule always avoids doing this. We should enhance
> the rule so this can be configurable depending on where in planning the rule
> is used.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-4851) Lots of warnings about Execution optimizations have been disabled when build CALCITE
[
https://issues.apache.org/jira/browse/CALCITE-4851?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
duan xiong updated CALCITE-4851:
Description:
Lots of warnings about Execution optimizations have been disabled when build
CALCITE. For example:
{noformat}
Execution optimizations have been disabled for task ':babel:sourcesJar' to
ensure correctness due to the following reasons:
- Gradle detected a problem with the following location:
'/calcite/babel/build/javacc/javaCCMain'.
Reason: Task ':babel:sourcesJar' uses this output of task ':babel:javaCCMain'
without declaring an explicit or implicit dependency.
This can lead to incorrect results being produced, depending on what order the
tasks are executed. Please refer to
https://docs.gradle.org/7.2/userguide/validation_problems.html#implicit_dependency
for more details about this problem.{noformat}
and
{noformat}
Gradle detected a problem with the following location: '/calcite'. Reason:
Task ':gitProps' uses this output of task ':babel:checkstyleTest' without
declaring an explicit or implicit dependency.
This can lead to incorrect results being produced, depending on what order the
tasks are executed. Please refer to
https://docs.gradle.org/7.2/userguide/validation_problems.html#implicit_dependency
for more details about this problem.{noformat}
was:
Lots of warnings about Execution optimizations have been disabled when build
CALCITE. For example:
{noformat}
Execution optimizations have been disabled for task ':babel:sourcesJar' to
ensure correctness due to the following reasons:
- Gradle detected a problem with the following location:
'/calcite/babel/build/javacc/javaCCMain'.
Reason: Task ':babel:sourcesJar' uses this output of task ':babel:javaCCMain'
without declaring an explicit or implicit dependency.
This can lead to incorrect results being produced, depending on what order the
tasks are executed. Please refer to
https://docs.gradle.org/7.2/userguide/validation_problems.html#implicit_dependency
for more details about this problem.{noformat}
and
{noformat}
Gradle detected a problem with the following location: '/calcite'. Reason:
Task ':gitProps' uses this output of task ':babel:checkstyleTest' without
declaring an explicit or implicit dependency.
This can lead to incorrect results being produced, depending on what order the
tasks are executed. Please refer to
https://docs.gradle.org/7.2/userguide/validation_problems.html#implicit_dependency
for more details about this problem.{noformat}
> Lots of warnings about Execution optimizations have been disabled when build
> CALCITE
>
>
> Key: CALCITE-4851
> URL: https://issues.apache.org/jira/browse/CALCITE-4851
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.27.0
> Environment: MacOS
> Gradle 7.2
> Jdk 11
>Reporter: duan xiong
>Priority: Major
>
> Lots of warnings about Execution optimizations have been disabled when build
> CALCITE. For example:
> {noformat}
> Execution optimizations have been disabled for task ':babel:sourcesJar' to
> ensure correctness due to the following reasons:
> - Gradle detected a problem with the following location:
> '/calcite/babel/build/javacc/javaCCMain'.
> Reason: Task ':babel:sourcesJar' uses this output of task ':babel:javaCCMain'
> without declaring an explicit or implicit dependency.
> This can lead to incorrect results being produced, depending on what order
> the tasks are executed. Please refer to
> https://docs.gradle.org/7.2/userguide/validation_problems.html#implicit_dependency
> for more details about this problem.{noformat}
> and
> {noformat}
> Gradle detected a problem with the following location: '/calcite'. Reason:
> Task ':gitProps' uses this output of task ':babel:checkstyleTest' without
> declaring an explicit or implicit dependency.
> This can lead to incorrect results being produced, depending on what order
> the tasks are executed. Please refer to
> https://docs.gradle.org/7.2/userguide/validation_problems.html#implicit_dependency
> for more details about this problem.{noformat}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-4851) Lots of warnings about Execution optimizations have been disabled when build CALCITE
[
https://issues.apache.org/jira/browse/CALCITE-4851?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
duan xiong updated CALCITE-4851:
Description:
Lots of warnings about Execution optimizations have been disabled when build
CALCITE. For example:
{noformat}
Execution optimizations have been disabled for task ':babel:sourcesJar' to
ensure correctness due to the following reasons:
- Gradle detected a problem with the following location:
'/calcite/babel/build/javacc/javaCCMain'.
Reason: Task ':babel:sourcesJar' uses this output of task ':babel:javaCCMain'
without declaring an explicit or implicit dependency.
This can lead to incorrect results being produced, depending on what order the
tasks are executed. Please refer to
https://docs.gradle.org/7.2/userguide/validation_problems.html#implicit_dependency
for more details about this problem.{noformat}
and
{noformat}
Gradle detected a problem with the following location: '/calcite'. Reason:
Task ':gitProps' uses this output of task ':babel:checkstyleTest' without
declaring an explicit or implicit dependency.
This can lead to incorrect results being produced, depending on what order the
tasks are executed. Please refer to
https://docs.gradle.org/7.2/userguide/validation_problems.html#implicit_dependency
for more details about this problem.{noformat}
was:
Lots of warnings about Execution optimizations have been disabled when build
CALCITE. For example:
{noformat}
Execution optimizations have been disabled for task ':babel:sourcesJar' to
ensure correctness due to the following reasons:
- Gradle detected a problem with the following location:
'/calcite/babel/build/javacc/javaCCMain'. Reason: Task ':babel:sourcesJar' uses
this output of task ':babel:javaCCMain' without declaring an explicit or
implicit dependency. This can lead to incorrect results being produced,
depending on what order the tasks are executed. Please refer to
https://docs.gradle.org/7.2/userguide/validation_problems.html#implicit_dependency
for more details about this problem.{noformat}
and
{noformat}
Gradle detected a problem with the following location: '/calcite'. Reason: Task
':gitProps' uses this output of task ':babel:checkstyleTest' without declaring
an explicit or implicit dependency. This can lead to incorrect results being
produced, depending on what order the tasks are executed. Please refer to
https://docs.gradle.org/7.2/userguide/validation_problems.html#implicit_dependency
for more details about this problem.{noformat}
> Lots of warnings about Execution optimizations have been disabled when build
> CALCITE
>
>
> Key: CALCITE-4851
> URL: https://issues.apache.org/jira/browse/CALCITE-4851
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.27.0
> Environment: MacOS
> Gradle 7.2
> Jdk 11
>Reporter: duan xiong
>Priority: Major
>
> Lots of warnings about Execution optimizations have been disabled when build
> CALCITE. For example:
> {noformat}
> Execution optimizations have been disabled for task ':babel:sourcesJar' to
> ensure correctness due to the following reasons:
> - Gradle detected a problem with the following location:
> '/calcite/babel/build/javacc/javaCCMain'.
> Reason: Task ':babel:sourcesJar' uses this output of task ':babel:javaCCMain'
> without declaring an explicit or implicit dependency.
> This can lead to incorrect results being produced, depending on what order
> the tasks are executed. Please refer to
> https://docs.gradle.org/7.2/userguide/validation_problems.html#implicit_dependency
> for more details about this problem.{noformat}
> and
> {noformat}
> Gradle detected a problem with the following location: '/calcite'. Reason:
> Task ':gitProps' uses this output of task ':babel:checkstyleTest' without
> declaring an explicit or implicit dependency.
> This can lead to incorrect results being produced, depending on what order
> the tasks are executed. Please refer to
> https://docs.gradle.org/7.2/userguide/validation_problems.html#implicit_dependency
> for more details about this problem.{noformat}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (CALCITE-4851) Lots of warnings about Execution optimizations have been disabled when build CALCITE
duan xiong created CALCITE-4851:
---
Summary: Lots of warnings about Execution optimizations have been
disabled when build CALCITE
Key: CALCITE-4851
URL: https://issues.apache.org/jira/browse/CALCITE-4851
Project: Calcite
Issue Type: Improvement
Components: core
Affects Versions: 1.27.0
Environment: MacOS
Gradle 7.2
Jdk 11
Reporter: duan xiong
Lots of warnings about Execution optimizations have been disabled when build
CALCITE. For example:
{noformat}
Execution optimizations have been disabled for task ':babel:sourcesJar' to
ensure correctness due to the following reasons:
- Gradle detected a problem with the following location:
'/calcite/babel/build/javacc/javaCCMain'. Reason: Task ':babel:sourcesJar' uses
this output of task ':babel:javaCCMain' without declaring an explicit or
implicit dependency. This can lead to incorrect results being produced,
depending on what order the tasks are executed. Please refer to
https://docs.gradle.org/7.2/userguide/validation_problems.html#implicit_dependency
for more details about this problem.{noformat}
and
{noformat}
Gradle detected a problem with the following location: '/calcite'. Reason: Task
':gitProps' uses this output of task ':babel:checkstyleTest' without declaring
an explicit or implicit dependency. This can lead to incorrect results being
produced, depending on what order the tasks are executed. Please refer to
https://docs.gradle.org/7.2/userguide/validation_problems.html#implicit_dependency
for more details about this problem.{noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-4762) Upgrade Calcite to Avatica 1.19
[ https://issues.apache.org/jira/browse/CALCITE-4762?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CALCITE-4762: Labels: pull-request-available (was: ) > Upgrade Calcite to Avatica 1.19 > --- > > Key: CALCITE-4762 > URL: https://issues.apache.org/jira/browse/CALCITE-4762 > Project: Calcite > Issue Type: Bug > Components: jdbc-driver >Reporter: Julian Hyde >Assignee: Julian Hyde >Priority: Major > Labels: pull-request-available > Fix For: 1.28.0 > > Time Spent: 10m > Remaining Estimate: 0h > > Upgrade Calcite to Avatica version 1.19. > Currently version 1.19 has not been released. > 1.19 fixes at least one issue whose test cases are attached as PRs. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CALCITE-4841) Support numeric column type in CSV and File adapter
[ https://issues.apache.org/jira/browse/CALCITE-4841?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Louis Kuang updated CALCITE-4841: - Description: Currently, the csv adapter does not support the numeric column type (see supported types in [CsvFieldType|https://github.com/apache/calcite/blob/4bc916619fd286b2c0cc4d5c653c96a68801d74e/file/src/main/java/org/apache/calcite/adapter/file/CsvFieldType.java#L35]. Any type that is not supported will be interpreted by the [CsvEnumerator|https://github.com/apache/calcite/blob/master/file/src/main/java/org/apache/calcite/adapter/file/CsvEnumerator.java] as string. When dealing with decimal numbers, the currently most appropriate type is `double`. However, this is not accurate enough for financial data. This feature request proposes adding a `numeric` column type that will be implemented by the Java `BigDecimal` type (and by conversion in [JavaToSqlTypeConversionRules|https://github.com/apache/calcite/blob/4bc916619fd286b2c0cc4d5c653c96a68801d74e/core/src/main/java/org/apache/calcite/sql/type/JavaToSqlTypeConversionRules.java#L74] be represented as a `Decimal` SQL type). This allow financial data to be represented and computed more accurately (`BigDecimal` has higher precision than `double`). Please see sample implementation in PR. Context: I am trying to leverage Calcite to add some SQL support to [ledger|https://www.ledger-cli.org/] reporting. was: Currently, the csv adapter does not support the numeric column type (see supported types in [CsvFieldType|https://github.com/apache/calcite/blob/4bc916619fd286b2c0cc4d5c653c96a68801d74e/file/src/main/java/org/apache/calcite/adapter/file/CsvFieldType.java#L35]. Any type that is not supported will be interpreted by the [CsvEnumerator|https://github.com/apache/calcite/blob/master/file/src/main/java/org/apache/calcite/adapter/file/CsvEnumerator.java] as string. When dealing with decimal numbers, the currently most appropriate type is `double`. However, this is not accurate enough for financial data. This feature request proposes adding a `numeric` column type that will be implemented by the Java `BigDecimal` type (and by conversion in [JavaToSqlTypeConversionRules|https://github.com/apache/calcite/blob/4bc916619fd286b2c0cc4d5c653c96a68801d74e/core/src/main/java/org/apache/calcite/sql/type/JavaToSqlTypeConversionRules.java#L74] be represented as a `Decimal` SQL type). This allow financial data to be represented and computed more accurately (`BigDecimal` has higher precision than `double`). Please see sample implementation in PR. > Support numeric column type in CSV and File adapter > --- > > Key: CALCITE-4841 > URL: https://issues.apache.org/jira/browse/CALCITE-4841 > Project: Calcite > Issue Type: Improvement > Components: csv-adapter, file-adapter >Reporter: Louis Kuang >Priority: Minor > Labels: pull-request-available > Time Spent: 40m > Remaining Estimate: 0h > > Currently, the csv adapter does not support the numeric column type (see > supported types in > [CsvFieldType|https://github.com/apache/calcite/blob/4bc916619fd286b2c0cc4d5c653c96a68801d74e/file/src/main/java/org/apache/calcite/adapter/file/CsvFieldType.java#L35]. > Any type that is not supported will be interpreted by the > [CsvEnumerator|https://github.com/apache/calcite/blob/master/file/src/main/java/org/apache/calcite/adapter/file/CsvEnumerator.java] > as string. > When dealing with decimal numbers, the currently most appropriate type is > `double`. However, this is not accurate enough for financial data. This > feature request proposes adding a `numeric` column type that will be > implemented by the Java `BigDecimal` type (and by conversion in > [JavaToSqlTypeConversionRules|https://github.com/apache/calcite/blob/4bc916619fd286b2c0cc4d5c653c96a68801d74e/core/src/main/java/org/apache/calcite/sql/type/JavaToSqlTypeConversionRules.java#L74] > be represented as a `Decimal` SQL type). This allow financial data to be > represented and computed more accurately (`BigDecimal` has higher precision > than `double`). > Please see sample implementation in PR. > Context: I am trying to leverage Calcite to add some SQL support to > [ledger|https://www.ledger-cli.org/] reporting. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-4841) Support numeric column type in CSV and File adapter
[ https://issues.apache.org/jira/browse/CALCITE-4841?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17428385#comment-17428385 ] Louis Kuang commented on CALCITE-4841: -- Maybe I am missing the registration somewhere. I thought the following happen: CsvSchemaFactory --> CsvSchema --> CsvTable --> getRowType --> CsvEnumerator.deduceRowType --> CsvFieldType.toType(typeFactory) --> RelDataTypeFactoryImpl.createJavaType(BigDecimal.class) --> JavaType(BigDecimal.class) --> getSqlTypeName --> JavaToSqlTypeConversionRules.lookup(BigDecimal.class) --> SqlTypeName.DECIMAL and similarly for the FileFieldType. This seems enough for `!describe FooTable` to print the column type as `DECIMAL` It's true that I have not registered BigDecimal.class in RelDataTypeFactorImpl#CLASS_FAMILIES though. Is there a commit that I can use to reference adding a new type to Calcite? > Support numeric column type in CSV and File adapter > --- > > Key: CALCITE-4841 > URL: https://issues.apache.org/jira/browse/CALCITE-4841 > Project: Calcite > Issue Type: Improvement > Components: csv-adapter, file-adapter >Reporter: Louis Kuang >Priority: Minor > Labels: pull-request-available > Time Spent: 40m > Remaining Estimate: 0h > > Currently, the csv adapter does not support the numeric column type (see > supported types in > [CsvFieldType|https://github.com/apache/calcite/blob/4bc916619fd286b2c0cc4d5c653c96a68801d74e/file/src/main/java/org/apache/calcite/adapter/file/CsvFieldType.java#L35]. > Any type that is not supported will be interpreted by the > [CsvEnumerator|https://github.com/apache/calcite/blob/master/file/src/main/java/org/apache/calcite/adapter/file/CsvEnumerator.java] > as string. > When dealing with decimal numbers, the currently most appropriate type is > `double`. However, this is not accurate enough for financial data. This > feature request proposes adding a `numeric` column type that will be > implemented by the Java `BigDecimal` type (and by conversion in > [JavaToSqlTypeConversionRules|https://github.com/apache/calcite/blob/4bc916619fd286b2c0cc4d5c653c96a68801d74e/core/src/main/java/org/apache/calcite/sql/type/JavaToSqlTypeConversionRules.java#L74] > be represented as a `Decimal` SQL type). This allow financial data to be > represented and computed more accurately (`BigDecimal` has higher precision > than `double`). > Please see sample implementation in PR. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-4337) Support PARTITION BY clause in table function call
[
https://issues.apache.org/jira/browse/CALCITE-4337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17428210#comment-17428210
]
Viliam Durina commented on CALCITE-4337:
1. They say "may not be partitioned", but what they actually mean is what I
said, that is, each row is its own partition. The engine is also free to assign
partitions in any way; if each row is a partition, then it assigns each row
arbitrarily. I think there's no contradiction. My intention was to come up with
a generalized notion of partitioning that covers each option.
2. Copartitioning means that the tables are partitioned using the exact same
key. My idea was actually more general - it would be possible to execute a call
where partitioning keys of one argument are a prefix or partitioning keys of
another argument.
> Support PARTITION BY clause in table function call
> --
>
> Key: CALCITE-4337
> URL: https://issues.apache.org/jira/browse/CALCITE-4337
> Project: Calcite
> Issue Type: New Feature
> Components: core
>Affects Versions: 1.26.0
>Reporter: Danny Chen
>Assignee: Danny Chen
>Priority: Major
> Labels: pull-request-available
> Attachments: image-2021-09-30-11-04-33-474.png,
> image-2021-09-30-11-05-12-400.png, image-2021-09-30-11-05-42-033.png,
> image-2021-10-13-20-19-55-855.png, image-2021-10-13-20-22-42-675.png,
> image-2021-10-13-20-23-26-890.png
>
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> An example from the SQL standard 2016 Polymorphic Table Functions:
> {code:sql}
> SELECT W.wstart, W.wend, OI.customer, SUM(OI.price)
> FROM TABLE(SESSION(
> data => TABLE(order_item) AS OI PARTITION BY customer,
> timecol => DESCRIPTOR(order_time),
> timeout => INTERVAL '10' MINUTE)) W
> GROUP BY 1, 2, 3
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-4337) Support PARTITION BY clause in table function call
[
https://issues.apache.org/jira/browse/CALCITE-4337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17428190#comment-17428190
]
JING ZHANG commented on CALCITE-4337:
-
[~vilo] Thanks for your share. I agree with most of your views except the
following points:
1. Input tables with row semantics may not be partitioned. I don't think it's a
special case of partitioning because input rows could be assigned in
arbitrarily way, for example, random, round-roubin, any, broadcast and so on.
On this point, the SQL standard has the following description
!image-2021-10-13-20-19-55-855.png|width=734,height=105!
2. SQL standard also has description about PTF with multiple partitioned input
table parameters. I list one of the description as following, you could find
more in SQL standard file.
!image-2021-10-13-20-23-26-890.png|width=733,height=533!
3. `Time` column used to estimate activity of each partition for SESSION
function, we should not partition by `time` column. The SESSION function used
to group elements by sessions of activity. A session window closes when it does
not receive elements with same partition key for a certain period of time and a
new session window would open in the later. I would use the example in [session
table function document|https://calcite.apache.org/docs/reference.html#session]
[2]. In the case, partition key is `product`. If there are only 4 types of
products exists: 'p1', 'p2', 'p3', 'p4'. A session window on product 'p1' would
open after receives the first element with product 'p1', the window would close
if current task does not receive elements with product 'p1' for more than '20'
MINUTES. If an element with product 'p1' comes after the previous session
window closes, a new session window with product 'p1' would open.
SELECT * FROM TABLE(
SESSION(
TABLE orders PARTITION BY product,
DESCRIPTOR(rowtime),
INTERVAL '20' MINUTE));
> Support PARTITION BY clause in table function call
> --
>
> Key: CALCITE-4337
> URL: https://issues.apache.org/jira/browse/CALCITE-4337
> Project: Calcite
> Issue Type: New Feature
> Components: core
>Affects Versions: 1.26.0
>Reporter: Danny Chen
>Assignee: Danny Chen
>Priority: Major
> Labels: pull-request-available
> Attachments: image-2021-09-30-11-04-33-474.png,
> image-2021-09-30-11-05-12-400.png, image-2021-09-30-11-05-42-033.png,
> image-2021-10-13-20-19-55-855.png, image-2021-10-13-20-22-42-675.png,
> image-2021-10-13-20-23-26-890.png
>
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> An example from the SQL standard 2016 Polymorphic Table Functions:
> {code:sql}
> SELECT W.wstart, W.wend, OI.customer, SUM(OI.price)
> FROM TABLE(SESSION(
> data => TABLE(order_item) AS OI PARTITION BY customer,
> timecol => DESCRIPTOR(order_time),
> timeout => INTERVAL '10' MINUTE)) W
> GROUP BY 1, 2, 3
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-4337) Support PARTITION BY clause in table function call
[
https://issues.apache.org/jira/browse/CALCITE-4337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
JING ZHANG updated CALCITE-4337:
Attachment: image-2021-10-13-20-23-26-890.png
> Support PARTITION BY clause in table function call
> --
>
> Key: CALCITE-4337
> URL: https://issues.apache.org/jira/browse/CALCITE-4337
> Project: Calcite
> Issue Type: New Feature
> Components: core
>Affects Versions: 1.26.0
>Reporter: Danny Chen
>Assignee: Danny Chen
>Priority: Major
> Labels: pull-request-available
> Attachments: image-2021-09-30-11-04-33-474.png,
> image-2021-09-30-11-05-12-400.png, image-2021-09-30-11-05-42-033.png,
> image-2021-10-13-20-19-55-855.png, image-2021-10-13-20-22-42-675.png,
> image-2021-10-13-20-23-26-890.png
>
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> An example from the SQL standard 2016 Polymorphic Table Functions:
> {code:sql}
> SELECT W.wstart, W.wend, OI.customer, SUM(OI.price)
> FROM TABLE(SESSION(
> data => TABLE(order_item) AS OI PARTITION BY customer,
> timecol => DESCRIPTOR(order_time),
> timeout => INTERVAL '10' MINUTE)) W
> GROUP BY 1, 2, 3
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-4337) Support PARTITION BY clause in table function call
[
https://issues.apache.org/jira/browse/CALCITE-4337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
JING ZHANG updated CALCITE-4337:
Attachment: image-2021-10-13-20-22-42-675.png
> Support PARTITION BY clause in table function call
> --
>
> Key: CALCITE-4337
> URL: https://issues.apache.org/jira/browse/CALCITE-4337
> Project: Calcite
> Issue Type: New Feature
> Components: core
>Affects Versions: 1.26.0
>Reporter: Danny Chen
>Assignee: Danny Chen
>Priority: Major
> Labels: pull-request-available
> Attachments: image-2021-09-30-11-04-33-474.png,
> image-2021-09-30-11-05-12-400.png, image-2021-09-30-11-05-42-033.png,
> image-2021-10-13-20-19-55-855.png, image-2021-10-13-20-22-42-675.png
>
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> An example from the SQL standard 2016 Polymorphic Table Functions:
> {code:sql}
> SELECT W.wstart, W.wend, OI.customer, SUM(OI.price)
> FROM TABLE(SESSION(
> data => TABLE(order_item) AS OI PARTITION BY customer,
> timecol => DESCRIPTOR(order_time),
> timeout => INTERVAL '10' MINUTE)) W
> GROUP BY 1, 2, 3
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-4337) Support PARTITION BY clause in table function call
[
https://issues.apache.org/jira/browse/CALCITE-4337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
JING ZHANG updated CALCITE-4337:
Attachment: image-2021-10-13-20-19-55-855.png
> Support PARTITION BY clause in table function call
> --
>
> Key: CALCITE-4337
> URL: https://issues.apache.org/jira/browse/CALCITE-4337
> Project: Calcite
> Issue Type: New Feature
> Components: core
>Affects Versions: 1.26.0
>Reporter: Danny Chen
>Assignee: Danny Chen
>Priority: Major
> Labels: pull-request-available
> Attachments: image-2021-09-30-11-04-33-474.png,
> image-2021-09-30-11-05-12-400.png, image-2021-09-30-11-05-42-033.png,
> image-2021-10-13-20-19-55-855.png
>
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> An example from the SQL standard 2016 Polymorphic Table Functions:
> {code:sql}
> SELECT W.wstart, W.wend, OI.customer, SUM(OI.price)
> FROM TABLE(SESSION(
> data => TABLE(order_item) AS OI PARTITION BY customer,
> timecol => DESCRIPTOR(order_time),
> timeout => INTERVAL '10' MINUTE)) W
> GROUP BY 1, 2, 3
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-4337) Support PARTITION BY clause in table function call
[
https://issues.apache.org/jira/browse/CALCITE-4337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17428157#comment-17428157
]
JING ZHANG commented on CALCITE-4337:
-
[~julianhyde] I think it's a good idea to update
`[server/.../config.fmpp|https://github.com/apache/calcite/blob/2916b83712b517430e71c1c22042e484ee900589/server/src/main/codegen/config.fmpp#L72]
` in order to support define a TableFunction. For example, we could use the
following SQL to define a Table Function named `TopNplus`.
{code:java}
CREATE FUNCTION TopNplus (
Input TABLE NO PASS THROUGH WITH SET SEMANTICS PRUNE WHEN EMPTY,
Howmany INTEGER
) RETURNS TABLE
NOT DETERMINISTIC
READS SQL DATA{code}
The DDL defines the following characteristics:
# Function name
# Function arguments
# Input table characteristics:
## Input table semantics: ROW SEMANTICS or SET SEMANTICS, SET SEMANTICS is
default behavior.
## prunability : The characteristics is required if input table semantics is
SET semantic. PTF can generate a result row on empty input, the table is said
to be "keep when empty". The alternative is called "prune when empty". The
prunability characteristic is not applied for ROW SEMANTICS input table.
## PASS-THROUGH COLUMNS: "Pass-through" columns is a mechanism enabling the
PTF to copy every column of an input row into columns of an output row. The
alternative is "NO PASS THROUGH".
Besides, I still have three questions.
# Should we only define user defined table function based in DDL? Do we need
to define existed builtin window table function (e.g Tumbling Window TVF/HOP
Window TVF/Session Window TVF) in DDL or not?
# I think we should also change query parser in Core module (Parser.jj),
right? A user should write the following SQL query to use the `TopNplus`
function defined in the above example. So we need to update query parser in
order to allow `PARTITION BY` clause and `ORDER BY` clause.
{code:java}
SELECT S.Region, T.*
FROM TABLE ( TopNplus ( Input => TABLE (My.Sales) AS S
PARTITION BY Region
ORDER BY Sales DESC,
Howmany => 3
)
) AS T{code}
# In addition, we also need validate whether PTF query is valid. For example,
throw exception if define `PARTITION BY` clause or `ORDER BY` clause for input
table parameter with ROW SEMANTICS.
What do you think?
> Support PARTITION BY clause in table function call
> --
>
> Key: CALCITE-4337
> URL: https://issues.apache.org/jira/browse/CALCITE-4337
> Project: Calcite
> Issue Type: New Feature
> Components: core
>Affects Versions: 1.26.0
>Reporter: Danny Chen
>Assignee: Danny Chen
>Priority: Major
> Labels: pull-request-available
> Attachments: image-2021-09-30-11-04-33-474.png,
> image-2021-09-30-11-05-12-400.png, image-2021-09-30-11-05-42-033.png
>
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> An example from the SQL standard 2016 Polymorphic Table Functions:
> {code:sql}
> SELECT W.wstart, W.wend, OI.customer, SUM(OI.price)
> FROM TABLE(SESSION(
> data => TABLE(order_item) AS OI PARTITION BY customer,
> timecol => DESCRIPTOR(order_time),
> timeout => INTERVAL '10' MINUTE)) W
> GROUP BY 1, 2, 3
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-4848) Adding a HAVING condition to a query with a dynamic parameter makes the result always empty
[
https://issues.apache.org/jira/browse/CALCITE-4848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-4848:
Labels: pull-request-available (was: )
> Adding a HAVING condition to a query with a dynamic parameter makes the
> result always empty
> ---
>
> Key: CALCITE-4848
> URL: https://issues.apache.org/jira/browse/CALCITE-4848
> Project: Calcite
> Issue Type: Bug
>Affects Versions: 1.27.0
>Reporter: Thomas Rebele
>Assignee: Thomas Rebele
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.28.0
>
> Attachments: CALCITE-4848.patch
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The query
> {code:java}
> SELECT sal, COUNT(1) AS count_val
> FROM emp t WHERE sal = ?
> GROUP BY sal HAVING sal < 1000 {code}
> gets translated to the following logical plan:
> {code:java}
> LogicalFilter(condition=[<($0, 1000)])
> LogicalAggregate(group=[{0}], COUNT_VAL=[COUNT()])
> LogicalProject(SAL=[$5], $f1=[1])
> LogicalFilter(condition=[=($5, ?0)])
> LogicalTableScan(table=[[CATALOG, SALES, EMP]]) {code}
> However, applying CoreRules.FILTER_REDUCE_EXPRESSIONS to the plan it just
> becomes
> {code:java}
> LogicalValues(tuples=[[]]) {code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-4337) Support PARTITION BY clause in table function call
[
https://issues.apache.org/jira/browse/CALCITE-4337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17428144#comment-17428144
]
Viliam Durina commented on CALCITE-4337:
My understanding is this: The SQL standard about PTFs introduced two orthogonal
features:
* ability to take and return tables with row type _not_ declared at design
time (the whole feature is named after this)
* ability to parallelize functions with table arguments based on partitioning
The PARTITION BY clause is about the 2nd feature, Calcite already has the 1st
feature. Traditionally, tables were passed into functions as a single value (as
a `List` in Java). `PARTITION BY 0` would implement the traditional
behavior, all rows passed in one set. Partitioning by some expression allows
parallel execution of the function. It also allows stream processing, if
partitioning by some time column. The ROW semantics is a special case of
partitioning where each row is its own partition (as in `PARTITION BY
primaryKey`).
Stating this, we can think of each table argument to a function to be
partitioned in some way.
Second point: in general, you can't partition a collection of rows by two
arbitrary partitioning keys at the same time. These two partitionings have to
be "compatible", i.e. every partition of rows from one partitioning expression
must be contained entirely in a partition of rows from the other partitioning
expression. (Maybe there's a mathematical term for this, Julian might help with
that :)). For example, if one table is partitioned by surname and name (in this
order) and the other table is partitioned only by surname, the partitioning is
compatible. So if a function has multiple table arguments, their partitioning
must be compatible. Note that ROW semantics and the traditional one-value
semantics are compatible with any other partitioning.
And after writing this, third problem came up to my mind: whether the input to
the SESSION function should be partitioned by time first. If it is, the
function will receive a set of rows for each time in a separate set, and then
it cannot evaluate the session end. If it's not partitioned by time, then the
function is supposed to receive the whole set of rows for one key, and that's
not possible in unbounded streams. Intuitively it seems that the table
shouldn't be partitioned by the time column, but the data for each partition
should be streamed into the function. I don't know how to resolve this. But
this discussion should be a part of the second issue about the SESSION function.
> Support PARTITION BY clause in table function call
> --
>
> Key: CALCITE-4337
> URL: https://issues.apache.org/jira/browse/CALCITE-4337
> Project: Calcite
> Issue Type: New Feature
> Components: core
>Affects Versions: 1.26.0
>Reporter: Danny Chen
>Assignee: Danny Chen
>Priority: Major
> Labels: pull-request-available
> Attachments: image-2021-09-30-11-04-33-474.png,
> image-2021-09-30-11-05-12-400.png, image-2021-09-30-11-05-42-033.png
>
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> An example from the SQL standard 2016 Polymorphic Table Functions:
> {code:sql}
> SELECT W.wstart, W.wend, OI.customer, SUM(OI.price)
> FROM TABLE(SESSION(
> data => TABLE(order_item) AS OI PARTITION BY customer,
> timecol => DESCRIPTOR(order_time),
> timeout => INTERVAL '10' MINUTE)) W
> GROUP BY 1, 2, 3
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-4848) Adding a HAVING condition to a query with a dynamic parameter makes the result always empty
[
https://issues.apache.org/jira/browse/CALCITE-4848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Rebele updated CALCITE-4848:
---
Summary: Adding a HAVING condition to a query with a dynamic parameter
makes the result always empty (was: Adding a HAVING condition to a query with
a dynamic parameter makes the result empty)
> Adding a HAVING condition to a query with a dynamic parameter makes the
> result always empty
> ---
>
> Key: CALCITE-4848
> URL: https://issues.apache.org/jira/browse/CALCITE-4848
> Project: Calcite
> Issue Type: Bug
>Affects Versions: 1.27.0
>Reporter: Thomas Rebele
>Assignee: Thomas Rebele
>Priority: Major
> Fix For: 1.28.0
>
> Attachments: CALCITE-4848.patch
>
>
> The query
> {code:java}
> SELECT sal, COUNT(1) AS count_val
> FROM emp t WHERE sal = ?
> GROUP BY sal HAVING sal < 1000 {code}
> gets translated to the following logical plan:
> {code:java}
> LogicalFilter(condition=[<($0, 1000)])
> LogicalAggregate(group=[{0}], COUNT_VAL=[COUNT()])
> LogicalProject(SAL=[$5], $f1=[1])
> LogicalFilter(condition=[=($5, ?0)])
> LogicalTableScan(table=[[CATALOG, SALES, EMP]]) {code}
> However, applying CoreRules.FILTER_REDUCE_EXPRESSIONS to the plan it just
> becomes
> {code:java}
> LogicalValues(tuples=[[]]) {code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (CALCITE-4848) Adding a HAVING condition to a query with a dynamic parameter makes the result empty
[
https://issues.apache.org/jira/browse/CALCITE-4848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Rebele reassigned CALCITE-4848:
--
Assignee: Thomas Rebele
> Adding a HAVING condition to a query with a dynamic parameter makes the
> result empty
>
>
> Key: CALCITE-4848
> URL: https://issues.apache.org/jira/browse/CALCITE-4848
> Project: Calcite
> Issue Type: Bug
>Affects Versions: 1.27.0
>Reporter: Thomas Rebele
>Assignee: Thomas Rebele
>Priority: Major
> Fix For: 1.28.0
>
> Attachments: CALCITE-4848.patch
>
>
> The query
> {code:java}
> SELECT sal, COUNT(1) AS count_val
> FROM emp t WHERE sal = ?
> GROUP BY sal HAVING sal < 1000 {code}
> gets translated to the following logical plan:
> {code:java}
> LogicalFilter(condition=[<($0, 1000)])
> LogicalAggregate(group=[{0}], COUNT_VAL=[COUNT()])
> LogicalProject(SAL=[$5], $f1=[1])
> LogicalFilter(condition=[=($5, ?0)])
> LogicalTableScan(table=[[CATALOG, SALES, EMP]]) {code}
> However, applying CoreRules.FILTER_REDUCE_EXPRESSIONS to the plan it just
> becomes
> {code:java}
> LogicalValues(tuples=[[]]) {code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-4848) Adding a HAVING condition to a query with a dynamic parameter makes the result empty
[
https://issues.apache.org/jira/browse/CALCITE-4848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ruben Q L updated CALCITE-4848:
---
Fix Version/s: 1.28.0
> Adding a HAVING condition to a query with a dynamic parameter makes the
> result empty
>
>
> Key: CALCITE-4848
> URL: https://issues.apache.org/jira/browse/CALCITE-4848
> Project: Calcite
> Issue Type: Bug
>Affects Versions: 1.27.0
>Reporter: Thomas Rebele
>Priority: Major
> Fix For: 1.28.0
>
> Attachments: CALCITE-4848.patch
>
>
> The query
> {code:java}
> SELECT sal, COUNT(1) AS count_val
> FROM emp t WHERE sal = ?
> GROUP BY sal HAVING sal < 1000 {code}
> gets translated to the following logical plan:
> {code:java}
> LogicalFilter(condition=[<($0, 1000)])
> LogicalAggregate(group=[{0}], COUNT_VAL=[COUNT()])
> LogicalProject(SAL=[$5], $f1=[1])
> LogicalFilter(condition=[=($5, ?0)])
> LogicalTableScan(table=[[CATALOG, SALES, EMP]]) {code}
> However, applying CoreRules.FILTER_REDUCE_EXPRESSIONS to the plan it just
> becomes
> {code:java}
> LogicalValues(tuples=[[]]) {code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-4841) Support numeric column type in CSV and File adapter
[ https://issues.apache.org/jira/browse/CALCITE-4841?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17428060#comment-17428060 ] Julian Hyde commented on CALCITE-4841: -- I don't think I am confused. You call it 'numeric' everywhere, including in the .csv file, and nowhere do you link it to java.sql.Types.DECIMAL or to SqlTypeName.DECIMAL. > Support numeric column type in CSV and File adapter > --- > > Key: CALCITE-4841 > URL: https://issues.apache.org/jira/browse/CALCITE-4841 > Project: Calcite > Issue Type: Improvement > Components: csv-adapter, file-adapter >Reporter: Louis Kuang >Priority: Minor > Labels: pull-request-available > Time Spent: 40m > Remaining Estimate: 0h > > Currently, the csv adapter does not support the numeric column type (see > supported types in > [CsvFieldType|https://github.com/apache/calcite/blob/4bc916619fd286b2c0cc4d5c653c96a68801d74e/file/src/main/java/org/apache/calcite/adapter/file/CsvFieldType.java#L35]. > Any type that is not supported will be interpreted by the > [CsvEnumerator|https://github.com/apache/calcite/blob/master/file/src/main/java/org/apache/calcite/adapter/file/CsvEnumerator.java] > as string. > When dealing with decimal numbers, the currently most appropriate type is > `double`. However, this is not accurate enough for financial data. This > feature request proposes adding a `numeric` column type that will be > implemented by the Java `BigDecimal` type (and by conversion in > [JavaToSqlTypeConversionRules|https://github.com/apache/calcite/blob/4bc916619fd286b2c0cc4d5c653c96a68801d74e/core/src/main/java/org/apache/calcite/sql/type/JavaToSqlTypeConversionRules.java#L74] > be represented as a `Decimal` SQL type). This allow financial data to be > represented and computed more accurately (`BigDecimal` has higher precision > than `double`). > Please see sample implementation in PR. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CALCITE-4740) JDBC adapter generates incorrect HAVING clause in BigQuery dialect
[
https://issues.apache.org/jira/browse/CALCITE-4740?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde updated CALCITE-4740:
-
Fix Version/s: 1.28.0
> JDBC adapter generates incorrect HAVING clause in BigQuery dialect
> --
>
> Key: CALCITE-4740
> URL: https://issues.apache.org/jira/browse/CALCITE-4740
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.27.0
> Environment: jdk8
> macos
>Reporter: yanjing.wang
>Priority: Minor
> Labels: pull-request-available
> Fix For: 1.28.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> I'm converting
> {code:java}
> String query = select
> "product_id" , sum("shelf_width")
> from "foodmart"."product"
> where "product_id" > 0
> group by "product_id" having sum("shelf_width") > 1{code}
> with big query dialect, but results
> {code:java}
> SELECT product_id, SUM(shelf_width)
> FROM foodmart.product
> WHERE product_id > 0
> GROUP BY product_id
> HAVING `EXPR$1` > 1
> {code}
> Maybe we need replace having clause aliases when stripping trivial aliases.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-4844) when the value of sub-query threshold smaller than IN list size the In list include columns return wrong result.
[
https://issues.apache.org/jira/browse/CALCITE-4844?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17428047#comment-17428047
]
duan xiong commented on CALCITE-4844:
-
[~julianhyde] Hi. I don't have a good idea about how to optimize 'x in (a, b,
c)' for now.
So I choose to ignore the list size condition to convert all this SQL to
'x = a or x = b or x = c'
(AS PR). Do you have any idea about this?
> when the value of sub-query threshold smaller than IN list size the In list
> include columns return wrong result.
>
>
> Key: CALCITE-4844
> URL: https://issues.apache.org/jira/browse/CALCITE-4844
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.27.0
>Reporter: duan xiong
>Assignee: duan xiong
>Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> According CALCITE-1155[Support columns for IN list]. We support
> {code:java}
> 'x in (a, b, c)' {code}
> by expands to
> {code:java}
> 'x = a or x = b or x = c'{code}
> In Calcite. Only the list size smaller than the value of the sub-query
> threshold can convert. We should ignore the the value of the sub-query
> threshold to convert this.
>
> This issue can reproduce by add a unit test in SqlToRelConverterTest:
> {code:java}
> @Test void testInListIncludeColumns() {
> final String sql = "SELECT empno\n"
> + "FROM emp AS e\n"
> + "WHERE 130 in (empno, deptno)";
> sql(sql).withConfig(b -> b.withInSubQueryThreshold(3))
> .convertsTo(
> "\n" +
> "LogicalProject(EMPNO=[$0])\n" +
> " LogicalFilter(condition=[OR(=(130, $0), =(130, $7))])\n" +
> "LogicalTableScan(table=[[CATALOG, SALES, EMP]])\n");
> sql(sql).withConfig(b -> b.withInSubQueryThreshold(1))
> .throws_("java.lang.NullPointerException: scope");
> }{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-4828) Standard Avatica build exception console output
[
https://issues.apache.org/jira/browse/CALCITE-4828?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17428042#comment-17428042
]
duan xiong commented on CALCITE-4828:
-
[~julianhyde] Hi. This PR is very easy to review and I have asked in the dev
list before. So If you have more time please review this. Thanks.
> Standard Avatica build exception console output
> ---
>
> Key: CALCITE-4828
> URL: https://issues.apache.org/jira/browse/CALCITE-4828
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Affects Versions: avatica-1.19.0
>Reporter: duan xiong
>Assignee: duan xiong
>Priority: Major
> Labels: pull-request-available
> Fix For: avatica-1.20.0
>
> Attachments: Build Avatica Apply the PR after.png, Build Avatica
> Apply this PR before.png
>
>
> When building Avatica In Idea, A lot of messages have been output in the
> console. The error doesn't affect the proceeding of the test suite and
> doesn't fail the test. It's not standard. For example:
> {noformat}
> org.apache.calcite.avatica.RemoteDriverTest >
> testPrepareBindExecuteFetch[PROTOBUF]
> STANDARD_ERRORorg.apache.calcite.avatica.RemoteDriverTest >
> testPrepareBindExecuteFetch[PROTOBUF] STANDARD_ERROR
> java.lang.RuntimeException: java.lang.RuntimeException:
> java.sql.SQLException: exception while executing query: unbound parameter
> at
> org.apache.calcite.avatica.RemoteDriverTest$LoggingLocalProtobufService._apply(RemoteDriverTest.java:1875)
>
> at
> org.apache.calcite.avatica.remote.ProtobufService.apply(ProtobufService.java:97)
>
> at org.apache.calcite.avatica.remote.RemoteMeta$15.call(RemoteMeta.java:345)
> at org.apache.calcite.avatica.remote.RemoteMeta$15.call(RemoteMeta.java:343)
> at
> org.apache.calcite.avatica.AvaticaConnection.invokeWithRetries(AvaticaConnection.java:793)
> at org.apache.calcite.avatica.remote.RemoteMeta.execute(RemoteMeta.java:342)
> at
> org.apache.calcite.avatica.AvaticaConnection.executeQueryInternal(AvaticaConnection.java:548)
> at
> org.apache.calcite.avatica.AvaticaPreparedStatement.executeQuery(AvaticaPreparedStatement.java:137)
> at
> org.apache.calcite.avatica.RemoteDriverTest.checkPrepareBindExecuteFetch(RemoteDriverTest.java:913)
> at
> org.apache.calcite.avatica.RemoteDriverTest.testPrepareBindExecuteFetch(RemoteDriverTest.java:892)
> 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)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
