[jira] [Commented] (CALCITE-4274) Cascaded table-valued function windowing contains ambiguous window_start/window_end columns
[
https://issues.apache.org/jira/browse/CALCITE-4274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17201906#comment-17201906
]
Rui Wang commented on CALCITE-4274:
---
Per discussion in email thread, the right approach is to differentiate two
window starts (and ends) by alias. For example:
SELECT T.window_start, T.window_end, T.timestamp, F.window_start,
F.window_end
FROM TABLE(TUMBLE(TABLE(input_table) AS T, DESCRIPTOR(timestamp),
INTERVAL '5' MINUTES)) AS F
> Cascaded table-valued function windowing contains ambiguous
> window_start/window_end columns
> ---
>
> Key: CALCITE-4274
> URL: https://issues.apache.org/jira/browse/CALCITE-4274
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.23.0
>Reporter: liupengcheng
>Priority: Major
>
> When executing the following sql, the ValidationException is thrown:
> sql:
> {code:java}
> with subquery1 as (select * from table(TUMBLE(table MyTable3, " +
> "descriptor(eventtime1), interval '1' minute))) " +
> "select window_end from table(TUMBLE(table subquery1, " +
> "descriptor(eventtime1), interval '1' minute))
> {code}
> exceptions:
> {code:java}
> org.apache.calcite.runtime.CalciteContextException: From line 1, column 117
> to line 1, column 126: Column 'window_end' is
> ambiguousorg.apache.calcite.runtime.CalciteContextException: From line 1,
> column 117 to line 1, column 126: Column 'window_end' is ambiguous 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:457)
> at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:857) at
> org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:842) at
> org.apache.calcite.sql.validate.SqlValidatorImpl.newValidationError(SqlValidatorImpl.java:5114)
> at
> org.apache.calcite.sql.validate.DelegatingScope.fullyQualify(DelegatingScope.java:278)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl$Expander.visit(SqlValidatorImpl.java:6012)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl$SelectExpander.visit(SqlValidatorImpl.java:6175)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl$SelectExpander.visit(SqlValidatorImpl.java:6161)
> at org.apache.calcite.sql.SqlIdentifier.accept(SqlIdentifier.java:321) at
> org.apache.calcite.sql.validate.SqlValidatorImpl.expandSelectExpr(SqlValidatorImpl.java:5595)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.expandSelectItem(SqlValidatorImpl.java:454)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateSelectList(SqlValidatorImpl.java:4279)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateSelect(SqlValidatorImpl.java:3538)
> at
> org.apache.calcite.sql.validate.SelectNamespace.validateImpl(SelectNamespace.java:60)
> at
> org.apache.calcite.sql.validate.AbstractNamespace.validate(AbstractNamespace.java:84)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateNamespace(SqlValidatorImpl.java:)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateQuery(SqlValidatorImpl.java:1085)
> at
> org.apache.calcite.sql.validate.WithNamespace.validateImpl(WithNamespace.java:57)
> at
> org.apache.calcite.sql.validate.AbstractNamespace.validate(AbstractNamespace.java:84)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateNamespace(SqlValidatorImpl.java:)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateWith(SqlValidatorImpl.java:3929)
> at org.apache.calcite.sql.SqlWith.validate(SqlWith.java:71) at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateScopedExpression(SqlValidatorImpl.java:1060)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validate(SqlValidatorImpl.java:767)
> {code}
> I looked into the code, I think it's because we are now appending
> `window_start`/`window_end` directly when deriving row type.
> I think it's a bug in Calcite, we can fix it by deduplicate the
> window_start/window_end columns.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-4267) Add filed "output" for RelJsonWriter.
[ https://issues.apache.org/jira/browse/CALCITE-4267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17201878#comment-17201878 ] Jiatao Tao commented on CALCITE-4267: - Hi [~zabetak], sorry for the late reply, here's the background: Clickhouse want us to help them opt SQL, so they needed a serialized RelNode, we give them the JSON format, but still miss some info to desc this plan(In Calcite, we need validator to desc this). > Add filed "output" for RelJsonWriter. > - > > Key: CALCITE-4267 > URL: https://issues.apache.org/jira/browse/CALCITE-4267 > Project: Calcite > Issue Type: Improvement >Reporter: Jiatao Tao >Assignee: Jiatao Tao >Priority: Minor > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-4277) skip rule match when rel's relset is obsolete
[ https://issues.apache.org/jira/browse/CALCITE-4277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17201849#comment-17201849 ] Jiatao Tao commented on CALCITE-4277: - when we merge set, the set may be obsolete, but the rule match is still in the rule queue. > skip rule match when rel's relset is obsolete > - > > Key: CALCITE-4277 > URL: https://issues.apache.org/jira/browse/CALCITE-4277 > Project: Calcite > Issue Type: Improvement >Reporter: Jiatao Tao >Assignee: Jiatao Tao >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CALCITE-4277) skip rule match when rel's relset is obsolete
Jiatao Tao created CALCITE-4277: --- Summary: skip rule match when rel's relset is obsolete Key: CALCITE-4277 URL: https://issues.apache.org/jira/browse/CALCITE-4277 Project: Calcite Issue Type: Improvement Reporter: Jiatao Tao Assignee: Jiatao Tao -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-4259) Support JDK 15
[ https://issues.apache.org/jira/browse/CALCITE-4259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17201808#comment-17201808 ] Julian Hyde commented on CALCITE-4259: -- It is highly desirable that we do this for the next release. Now log4j has reached end of life, there are accumulating security issues. I don't want to go into specifics. The best thing is to remove it (log4j version 1, not log4j2) from Calcite. > Support JDK 15 > -- > > Key: CALCITE-4259 > URL: https://issues.apache.org/jira/browse/CALCITE-4259 > Project: Calcite > Issue Type: Bug >Reporter: Julian Hyde >Assignee: Julian Hyde >Priority: Major > Labels: pull-request-available > Fix For: 1.26.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > JDK 15 is now GA (released 2020/09/15). We should support it (and OpenJDK 15) > as a build- and run-time platform. > Also: > * Upgrade to latest Guava (guava-29.0-jre, released on 2020/04/13); > * Upgrade log4j2 to latest (2.13.3, release 2020/05/10); > * Remove log4j (we're on the last release, 1.2.17, which was 2012/05/26, but > I assume the project is now unsupported and dead). > If there are any other important upgrades to be done before 1.26, please add > them here. > Must fix in next release (1.26) or justify why not in this thread. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (CALCITE-4275) EnumerableMergeJoin#create does not set EnumerableConvention in the trait set
[
https://issues.apache.org/jira/browse/CALCITE-4275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ruben Q L resolved CALCITE-4275.
Resolution: Fixed
Fixed via
https://github.com/apache/calcite/commit/8ca4d86bfb69be7369ad34be11594efdb2ec0956
> EnumerableMergeJoin#create does not set EnumerableConvention in the trait set
> -
>
> Key: CALCITE-4275
> URL: https://issues.apache.org/jira/browse/CALCITE-4275
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.25.0
>Reporter: Ruben Q L
>Assignee: Ruben Q L
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.26.0
>
> Time Spent: 2h 40m
> Remaining Estimate: 0h
>
> {{EnumerableMergeJoin#create}} does not set {{EnumerableConvention}} in the
> trait set that will be passed to {{EnumerableMergeJoin}}'s constructor, so it
> effectively creates an {{EnumerableMergeJoin}} with {{Convention.NONE}}.
> So far, this problem had been unnoticed because {{EnumerableMergeJoinRule}}
> calls directly {{EnumerableMergeJoin}}'s constructor (and not
> {{EnumerableMergeJoin#create}}).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-4276) Rewriting for materialized view will project wrong input
[
https://issues.apache.org/jira/browse/CALCITE-4276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Swett updated CALCITE-4276:
--
Description:
When MaterializedViewOnlyAggregateRule does its rewrite it will sometimes
produce a project above the materialized view that references the incorrect
input. For example,
Materialization Rel:
{noformat}
LogicalAggregate(group=[{0}], ORDER_ITEMS.ORDER_SIZE=[COUNT()],
ORDER_ITEMS.ORDER_SUM=[$SUM0($1)])
LogicalProject(ORDER_ID=[$1], AMOUNT=[$2])
2(table=[[orders_items]]){noformat}
Query Rel:
{noformat}
LogicalAggregate(group=[{0}], agg#0=[COUNT()])
LogicalProject($f0=[FLOOR($1, FLAG(YEAR))])
LogicalJoin(condition=[=($0, $1)], joinType=[inner])
LogicalProject(ORDER_ID=[$1])
2(table=[[orders_items]])
LogicalProject(ID=[$0], CREATED_AT=[$4])
4(table=[[orders]]){noformat}
Will Produce the following rel after MaterializedViewOnlyAggregateRule fires:
{noformat}
LogicalAggregate(group=[{8}], agg#0=[$SUM0($1)])
LogicalProject(ORDER_ID=[$0], ORDER_ITEMS.ORDER_SIZE=[$1],
ORDER_ITEMS.ORDER_SUM=[$2], ID=[$3], USER_ID=[$4], ORDER_AMOUNT=[$5],
STATUS=[$6], CREATED_AT=[$7], $f8=[FLOOR($0, FLAG(YEAR))])
LogicalFilter(condition=[=($0, $3)])
LogicalJoin(condition=[true], joinType=[inner])
6(table=[[testing_mv]])
4(table=[[orders]]){noformat}
Notice the "*$f8=[FLOOR($0, FLAG(YEAR))*" the $0 is pointing to the test_mv
order_id field. It should be point to $7 for this test, so perhaps something
with the filter?
The attached test case reproduces the issue.
was:
When MaterializedViewOnlyAggregateRule does its rewrite it will sometimes
produce a project above the materialized view that references the incorrect
input. For example,
Materialization Rel:
{noformat}
LogicalAggregate(group=[{0}], ORDER_ITEMS.ORDER_SIZE=[COUNT()],
ORDER_ITEMS.ORDER_SUM=[$SUM0($1)])
LogicalProject(ORDER_ID=[$1], AMOUNT=[$2])
2(table=[[orders_items]]){noformat}
Query Rel:
{noformat}
LogicalAggregate(group=[{0}], agg#0=[COUNT()])
LogicalProject($f0=[FLOOR($1, FLAG(YEAR))])
LogicalJoin(condition=[=($0, $1)], joinType=[inner])
LogicalProject(ORDER_ID=[$1])
2(table=[[orders_items]])
LogicalProject(ID=[$0], CREATED_AT=[$4])
4(table=[[orders]]){noformat}
Will Produce the following rel after MaterializedViewOnlyAggregateRule fires:
{noformat}
LogicalAggregate(group=[{8}], agg#0=[$SUM0($1)])
LogicalProject(ORDER_ID=[$0], ORDER_ITEMS.ORDER_SIZE=[$1],
ORDER_ITEMS.ORDER_SUM=[$2], ID=[$3], USER_ID=[$4], ORDER_AMOUNT=[$5],
STATUS=[$6], CREATED_AT=[$7], $f8=[FLOOR($0, FLAG(YEAR))])
LogicalFilter(condition=[=($0, $3)])
LogicalJoin(condition=[true], joinType=[inner])
6(table=[[testing_mv]])
4(table=[[orders]]){noformat}
Notice the "*$f8=[FLOOR($0, FLAG(YEAR))*" the $0 is pointing to the test_mv
order_id field, so perhaps something with the filter?
The attached test case reproduces the issue.
> Rewriting for materialized view will project wrong input
>
>
> Key: CALCITE-4276
> URL: https://issues.apache.org/jira/browse/CALCITE-4276
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Justin Swett
>Priority: Major
> Attachments: TemporalMaterializationWithJoinsTest.java
>
>
> When MaterializedViewOnlyAggregateRule does its rewrite it will sometimes
> produce a project above the materialized view that references the incorrect
> input. For example,
> Materialization Rel:
> {noformat}
> LogicalAggregate(group=[{0}], ORDER_ITEMS.ORDER_SIZE=[COUNT()],
> ORDER_ITEMS.ORDER_SUM=[$SUM0($1)])
> LogicalProject(ORDER_ID=[$1], AMOUNT=[$2])
> 2(table=[[orders_items]]){noformat}
> Query Rel:
> {noformat}
> LogicalAggregate(group=[{0}], agg#0=[COUNT()])
> LogicalProject($f0=[FLOOR($1, FLAG(YEAR))])
> LogicalJoin(condition=[=($0, $1)], joinType=[inner])
> LogicalProject(ORDER_ID=[$1])
> 2(table=[[orders_items]])
> LogicalProject(ID=[$0], CREATED_AT=[$4])
> 4(table=[[orders]]){noformat}
> Will Produce the following rel after MaterializedViewOnlyAggregateRule fires:
> {noformat}
> LogicalAggregate(group=[{8}], agg#0=[$SUM0($1)])
> LogicalProject(ORDER_ID=[$0], ORDER_ITEMS.ORDER_SIZE=[$1],
> ORDER_ITEMS.ORDER_SUM=[$2], ID=[$3], USER_ID=[$4], ORDER_AMOUNT=[$5],
> STATUS=[$6], CREATED_AT=[$7], $f8=[FLOOR($0, FLAG(YEAR))])
> LogicalFilter(condition=[=($0, $3)])
> LogicalJoin(condition=[true], joinType=[inner])
> 6(table=[[testing_mv]])
> 4(table=[[orders]]){noformat}
> Notice the "*$f8=[FLOOR($0, FLAG(YEAR))*" the $0 is pointing to the test_mv
> order_id field. It should be point to $7 for this test, so perhaps something
> with the filter?
> The attached test case reproduces the issue.
--
[jira] [Created] (CALCITE-4276) Rewriting for materialized view will project wrong input
Justin Swett created CALCITE-4276:
-
Summary: Rewriting for materialized view will project wrong input
Key: CALCITE-4276
URL: https://issues.apache.org/jira/browse/CALCITE-4276
Project: Calcite
Issue Type: Bug
Components: core
Reporter: Justin Swett
Attachments: TemporalMaterializationWithJoinsTest.java
When MaterializedViewOnlyAggregateRule does its rewrite it will sometimes
produce a project above the materialized view that references the incorrect
input. For example,
Materialization Rel:
{noformat}
LogicalAggregate(group=[{0}], ORDER_ITEMS.ORDER_SIZE=[COUNT()],
ORDER_ITEMS.ORDER_SUM=[$SUM0($1)])
LogicalProject(ORDER_ID=[$1], AMOUNT=[$2])
2(table=[[orders_items]]){noformat}
Query Rel:
{noformat}
LogicalAggregate(group=[{0}], agg#0=[COUNT()])
LogicalProject($f0=[FLOOR($1, FLAG(YEAR))])
LogicalJoin(condition=[=($0, $1)], joinType=[inner])
LogicalProject(ORDER_ID=[$1])
2(table=[[orders_items]])
LogicalProject(ID=[$0], CREATED_AT=[$4])
4(table=[[orders]]){noformat}
Will Produce the following rel after MaterializedViewOnlyAggregateRule fires:
{noformat}
LogicalAggregate(group=[{8}], agg#0=[$SUM0($1)])
LogicalProject(ORDER_ID=[$0], ORDER_ITEMS.ORDER_SIZE=[$1],
ORDER_ITEMS.ORDER_SUM=[$2], ID=[$3], USER_ID=[$4], ORDER_AMOUNT=[$5],
STATUS=[$6], CREATED_AT=[$7], $f8=[FLOOR($0, FLAG(YEAR))])
LogicalFilter(condition=[=($0, $3)])
LogicalJoin(condition=[true], joinType=[inner])
6(table=[[testing_mv]])
4(table=[[orders]]){noformat}
Notice the "*$f8=[FLOOR($0, FLAG(YEAR))*" the $0 is pointing to the test_mv
order_id field, so perhaps something with the filter?
The attached test case reproduces the issue.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-4275) EnumerableMergeJoin#create does not set EnumerableConvention in the trait set
[
https://issues.apache.org/jira/browse/CALCITE-4275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-4275:
Labels: pull-request-available (was: )
> EnumerableMergeJoin#create does not set EnumerableConvention in the trait set
> -
>
> Key: CALCITE-4275
> URL: https://issues.apache.org/jira/browse/CALCITE-4275
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.25.0
>Reporter: Ruben Q L
>Assignee: Ruben Q L
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.26.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {{EnumerableMergeJoin#create}} does not set {{EnumerableConvention}} in the
> trait set that will be passed to {{EnumerableMergeJoin}}'s constructor, so it
> effectively creates an {{EnumerableMergeJoin}} with {{Convention.NONE}}.
> So far, this problem had been unnoticed because {{EnumerableMergeJoinRule}}
> calls directly {{EnumerableMergeJoin}}'s constructor (and not
> {{EnumerableMergeJoin#create}}).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (CALCITE-4275) EnumerableMergeJoin#create does not set EnumerableConvention in the trait set
[
https://issues.apache.org/jira/browse/CALCITE-4275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ruben Q L reassigned CALCITE-4275:
--
Assignee: Ruben Q L
> EnumerableMergeJoin#create does not set EnumerableConvention in the trait set
> -
>
> Key: CALCITE-4275
> URL: https://issues.apache.org/jira/browse/CALCITE-4275
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.25.0
>Reporter: Ruben Q L
>Assignee: Ruben Q L
>Priority: Major
> Fix For: 1.26.0
>
>
> {{EnumerableMergeJoin#create}} does not set {{EnumerableConvention}} in the
> trait set that will be passed to {{EnumerableMergeJoin}}'s constructor, so it
> effectively creates an {{EnumerableMergeJoin}} with {{Convention.NONE}}.
> So far, this problem had been unnoticed because {{EnumerableMergeJoinRule}}
> calls directly {{EnumerableMergeJoin}}'s constructor (and not
> {{EnumerableMergeJoin#create}}).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (CALCITE-4275) EnumerableMergeJoin#create does not set EnumerableConvention in the trait set
Ruben Q L created CALCITE-4275:
--
Summary: EnumerableMergeJoin#create does not set
EnumerableConvention in the trait set
Key: CALCITE-4275
URL: https://issues.apache.org/jira/browse/CALCITE-4275
Project: Calcite
Issue Type: Bug
Components: core
Affects Versions: 1.25.0
Reporter: Ruben Q L
Fix For: 1.26.0
{{EnumerableMergeJoin#create}} does not set {{EnumerableConvention}} in the
trait set that will be passed to {{EnumerableMergeJoin}}'s constructor, so it
effectively creates an {{EnumerableMergeJoin}} with {{Convention.NONE}}.
So far, this problem had been unnoticed because {{EnumerableMergeJoinRule}}
calls directly {{EnumerableMergeJoin}}'s constructor (and not
{{EnumerableMergeJoin#create}}).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-4270) Elasticsearch Collapse Query is not supported
[
https://issues.apache.org/jira/browse/CALCITE-4270?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shlok Srivastava updated CALCITE-4270:
--
Description:
Allows to collapse search results based on field values. The collapsing is done
by selecting only the top sorted document per collapse key. This can be used
while querying on multi-indices and get top sorted results.
Query for collapse -
{"query": {"match": {"message": "elasticsearch"}},"collapse" : {"field" :
"user"
}}
Currently we can query on multiple indices via calcite but collapse is not
supported -
[https://www.elastic.co/guide/en/elasticsearch/reference/6.8/search-request-collapse.html]
was:Currently collapse queries are not supported with search API -
https://www.elastic.co/guide/en/elasticsearch/reference/6.8/search-request-collapse.html
> Elasticsearch Collapse Query is not supported
> --
>
> Key: CALCITE-4270
> URL: https://issues.apache.org/jira/browse/CALCITE-4270
> Project: Calcite
> Issue Type: Improvement
> Components: elasticsearch-adapter
>Reporter: Shlok Srivastava
>Priority: Major
> Labels: QueryBuilder, calcite, collapse, elasticsearch
>
> Allows to collapse search results based on field values. The collapsing is
> done by selecting only the top sorted document per collapse key. This can be
> used while querying on multi-indices and get top sorted results.
> Query for collapse -
> {"query": {"match": {"message": "elasticsearch"}},"collapse" : {"field" :
> "user"
> }}
>
> Currently we can query on multiple indices via calcite but collapse is not
> supported -
> [https://www.elastic.co/guide/en/elasticsearch/reference/6.8/search-request-collapse.html]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-4259) Support JDK 15
[ https://issues.apache.org/jira/browse/CALCITE-4259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17201337#comment-17201337 ] Danny Chen commented on CALCITE-4259: - I'm not sure yet, is this a blocker ? We can disable the test first i think, the warns feature is not that critical, i can open the test later on if i find time, but not now because i'm crazily busy these days. > Support JDK 15 > -- > > Key: CALCITE-4259 > URL: https://issues.apache.org/jira/browse/CALCITE-4259 > Project: Calcite > Issue Type: Bug >Reporter: Julian Hyde >Assignee: Julian Hyde >Priority: Major > Labels: pull-request-available > Fix For: 1.26.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > JDK 15 is now GA (released 2020/09/15). We should support it (and OpenJDK 15) > as a build- and run-time platform. > Also: > * Upgrade to latest Guava (guava-29.0-jre, released on 2020/04/13); > * Upgrade log4j2 to latest (2.13.3, release 2020/05/10); > * Remove log4j (we're on the last release, 1.2.17, which was 2012/05/26, but > I assume the project is now unsupported and dead). > If there are any other important upgrades to be done before 1.26, please add > them here. > Must fix in next release (1.26) or justify why not in this thread. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-4240) SqlTypeUtil#getMaxPrecisionScaleDecimal will create decimal that has the same precision and scale
[ https://issues.apache.org/jira/browse/CALCITE-4240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17201333#comment-17201333 ] Jiatao Tao commented on CALCITE-4240: - Hi [~danny0405], let's discuss in PR, and I'll ynchronization conclusion here when we get one. > SqlTypeUtil#getMaxPrecisionScaleDecimal will create decimal that has the same > precision and scale > - > > Key: CALCITE-4240 > URL: https://issues.apache.org/jira/browse/CALCITE-4240 > Project: Calcite > Issue Type: Bug >Reporter: Jiatao Tao >Assignee: Jiatao Tao >Priority: Major > Labels: pull-request-available > Time Spent: 4h 40m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CALCITE-4240) SqlTypeUtil#getMaxPrecisionScaleDecimal will create decimal that has the same precision and scale
[ https://issues.apache.org/jira/browse/CALCITE-4240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jiatao Tao updated CALCITE-4240: Attachment: (was: image-2020-09-24-15-38-54-377.png) > SqlTypeUtil#getMaxPrecisionScaleDecimal will create decimal that has the same > precision and scale > - > > Key: CALCITE-4240 > URL: https://issues.apache.org/jira/browse/CALCITE-4240 > Project: Calcite > Issue Type: Bug >Reporter: Jiatao Tao >Assignee: Jiatao Tao >Priority: Major > Labels: pull-request-available > Time Spent: 4h 40m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CALCITE-4240) SqlTypeUtil#getMaxPrecisionScaleDecimal will create decimal that has the same precision and scale
[ https://issues.apache.org/jira/browse/CALCITE-4240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jiatao Tao updated CALCITE-4240: Attachment: image-2020-09-24-15-38-54-377.png > SqlTypeUtil#getMaxPrecisionScaleDecimal will create decimal that has the same > precision and scale > - > > Key: CALCITE-4240 > URL: https://issues.apache.org/jira/browse/CALCITE-4240 > Project: Calcite > Issue Type: Bug >Reporter: Jiatao Tao >Assignee: Jiatao Tao >Priority: Major > Labels: pull-request-available > Attachments: image-2020-09-24-15-38-54-377.png > > Time Spent: 4h 40m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005)
