[jira] [Commented] (CALCITE-4840) Avatica readme for source release should have better build instructions
[
https://issues.apache.org/jira/browse/CALCITE-4840?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17426005#comment-17426005
]
Julian Hyde commented on CALCITE-4840:
--
README.md is for GitHub. We don't remove README.md because, as a general
principle, the source distro mirrors what is in GitHub.
README is there because every source distro should have a README.
I don't want to finish this process with two different sets of build
instructions that will drift apart over time. (Already I am regretting putting
"JDK 8 or higher" in howto.md and "this release is tested ... on Oracle JDK 8,
... 15" in history.md.)
I also don't want to direct people to "build on JDK 8" because I don't want to
be one of those projects that gets stuck on a particular JDK version forever.
> Avatica readme for source release should have better build instructions
> ---
>
> Key: CALCITE-4840
> URL: https://issues.apache.org/jira/browse/CALCITE-4840
> Project: Calcite
> Issue Type: Improvement
> Components: avatica
>Reporter: Jacques Nadeau
>Assignee: Jacques Nadeau
>Priority: Major
> Labels: newbie
>
> Right now, trying to figure out how you should build from the source release
> is too difficult (unless I missed something). To find the rather meagre
> instructions, you have to:
> # Open the README and see it says use README.md
> # Open README.md and follow the link to the avatica home
> # Click develop
> # Click avatica development guide link
> # Find and click "build from a source distribution"
> Good luck to someone to find that path :)
> When you get there, it states java 8 or later but trying to build with Java
> 17 fails. For reference, jvm I was using:
> {{% java --version}}
> {{openjdk 17 2021-09-14 LTS}}
> {{OpenJDK Runtime Environment Corretto-17.0.0.35.2 (build 17+35-LTS)}}
> {{OpenJDK 64-Bit Server VM Corretto-17.0.0.35.2 (build 17+35-LTS, mixed mode,
> sharing)}}
>
> Ideally the readme (or an install.md or a single click) should include:
> * Prerequisites to build (gradle 6.8.1 and Java 8?)
> * How to check signature
> * How to build & test
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (CALCITE-4777) Casting from DECIMAL to BOOLEAN throws an exception
[
https://issues.apache.org/jira/browse/CALCITE-4777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17425986#comment-17425986
]
Julian Hyde edited comment on CALCITE-4777 at 10/8/21, 6:29 AM:
I don't think we should cast INTEGER to BOOLEAN. I didn't think we supported
it, and there don't seem to be any tests. There doesn't seem to be a good
reason to treat INTEGER differently from other numeric types.
was (Author: julianhyde):
I don't think we should cast integer to boolean. I didn't think we supported
it, and there don't seem to be any tests. There doesn't seem to be a good
reason to treat integer differently from other numeric types.
> Casting from DECIMAL to BOOLEAN throws an exception
> ---
>
> Key: CALCITE-4777
> URL: https://issues.apache.org/jira/browse/CALCITE-4777
> Project: Calcite
> Issue Type: Bug
>Reporter: xuyangzhong
>Assignee: xuyangzhong
>Priority: Major
> Labels: pull-request-available
> Attachments: calcite.png
>
> Time Spent: 2h 40m
> Remaining Estimate: 0h
>
> My sql is the following:
> {code:java}
> // code placeholder
> select * from test where cast (0.10915913549909961 as boolean){code}
>
> I want to simplify the cast. An exception is thrown:
>
> {code:java}
> // code placeholder
> Exception in thread "main" java.lang.RuntimeException: while resolving method
> 'booleanValue' in class class java.math.BigDecimal at
> org.apache.calcite.linq4j.tree.Expressions.call(Expressions.java:424) at
> org.apache.calcite.linq4j.tree.Expressions.call(Expressions.java:435) at
> org.apache.calcite.linq4j.tree.Expressions.unbox(Expressions.java:1453) at
> org.apache.calcite.adapter.enumerable.EnumUtils.convert(EnumUtils.java:398)
> at
> org.apache.calcite.adapter.enumerable.EnumUtils.convert(EnumUtils.java:326)
> at
> org.apache.calcite.adapter.enumerable.RexToLixTranslator.translateCast(RexToLixTranslator.java:543)
> at
> org.apache.calcite.adapter.enumerable.RexImpTable$CastImplementor.implementSafe(RexImpTable.java:2450)
> at
> org.apache.calcite.adapter.enumerable.RexImpTable$AbstractRexCallImplementor.genValueStatement(RexImpTable.java:2894)
> at
> org.apache.calcite.adapter.enumerable.RexImpTable$AbstractRexCallImplementor.implement(RexImpTable.java:2859)
> at
> org.apache.calcite.adapter.enumerable.RexToLixTranslator.visitCall(RexToLixTranslator.java:1089)
> at
> org.apache.calcite.adapter.enumerable.RexToLixTranslator.visitCall(RexToLixTranslator.java:90)
> at org.apache.calcite.rex.RexCall.accept(RexCall.java:174) at
> org.apache.calcite.adapter.enumerable.RexToLixTranslator.visitLocalRef(RexToLixTranslator.java:975)
> at
> org.apache.calcite.adapter.enumerable.RexToLixTranslator.visitLocalRef(RexToLixTranslator.java:90)
> at org.apache.calcite.rex.RexLocalRef.accept(RexLocalRef.java:75) at
> org.apache.calcite.adapter.enumerable.RexToLixTranslator.translate(RexToLixTranslator.java:237)
> at
> org.apache.calcite.adapter.enumerable.RexToLixTranslator.translate(RexToLixTranslator.java:231)
> at
> org.apache.calcite.adapter.enumerable.RexToLixTranslator.translateList(RexToLixTranslator.java:823)
> at
> org.apache.calcite.adapter.enumerable.RexToLixTranslator.translateProjects(RexToLixTranslator.java:198)
> at org.apache.calcite.rex.RexExecutorImpl.compile(RexExecutorImpl.java:90)
> at org.apache.calcite.rex.RexExecutorImpl.compile(RexExecutorImpl.java:66) at
> org.apache.calcite.rex.RexExecutorImpl.reduce(RexExecutorImpl.java:128) at
> org.apache.calcite.rex.RexSimplify.simplifyCast(RexSimplify.java:2101) at
> org.apache.calcite.rex.RexSimplify.simplify(RexSimplify.java:326) at
> org.apache.calcite.rex.RexSimplify.simplifyUnknownAs(RexSimplify.java:287) at
> org.apache.flink.table.examples.java.tests.CalciteTest.main(CalciteTest.java:47)
> Caused by: java.lang.NoSuchMethodException:
> java.math.BigDecimal.booleanValue() at
> java.lang.Class.getMethod(Class.java:1786) at
> org.apache.calcite.linq4j.tree.Expressions.call(Expressions.java:421) ... 25
> more
> {code}
> In order to avoid that I used the wrong rule or it caused by my bad coding, i
> write the test case following:
>
> {code:java}
> // code placeholder
> JavaTypeFactory typeFactory = new
> JavaTypeFactoryImpl(RelDataTypeSystem.DEFAULT);
> RexBuilder rexBuilder = new RexBuilder(typeFactory);
> final RexSimplify simplify = new RexSimplify(rexBuilder,
> RelOptPredicateList.EMPTY, RexUtil.EXECUTOR);
> RelDataType type = new BasicSqlType(typeFactory.getTypeSystem(),
> SqlTypeName.BOOLEAN);
> RelDataType bb = new
> BasicSqlType(typeFactory.getTypeSystem(),SqlTypeName.DECIMAL,18,17);
> SqlOperator op = new SqlCastFunction();
> RexLiteral lt =
> rexBuilder.makeExactLiteral(BigDecimal.valueOf(0.10915913549
[jira] [Commented] (CALCITE-4777) Casting from DECIMAL to BOOLEAN throws an exception
[
https://issues.apache.org/jira/browse/CALCITE-4777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17425986#comment-17425986
]
Julian Hyde commented on CALCITE-4777:
--
I don't think we should cast integer to boolean. I didn't think we supported
it, and there don't seem to be any tests. There doesn't seem to be a good
reason to treat integer differently from other numeric types.
> Casting from DECIMAL to BOOLEAN throws an exception
> ---
>
> Key: CALCITE-4777
> URL: https://issues.apache.org/jira/browse/CALCITE-4777
> Project: Calcite
> Issue Type: Bug
>Reporter: xuyangzhong
>Assignee: xuyangzhong
>Priority: Major
> Labels: pull-request-available
> Attachments: calcite.png
>
> Time Spent: 2h 40m
> Remaining Estimate: 0h
>
> My sql is the following:
> {code:java}
> // code placeholder
> select * from test where cast (0.10915913549909961 as boolean){code}
>
> I want to simplify the cast. An exception is thrown:
>
> {code:java}
> // code placeholder
> Exception in thread "main" java.lang.RuntimeException: while resolving method
> 'booleanValue' in class class java.math.BigDecimal at
> org.apache.calcite.linq4j.tree.Expressions.call(Expressions.java:424) at
> org.apache.calcite.linq4j.tree.Expressions.call(Expressions.java:435) at
> org.apache.calcite.linq4j.tree.Expressions.unbox(Expressions.java:1453) at
> org.apache.calcite.adapter.enumerable.EnumUtils.convert(EnumUtils.java:398)
> at
> org.apache.calcite.adapter.enumerable.EnumUtils.convert(EnumUtils.java:326)
> at
> org.apache.calcite.adapter.enumerable.RexToLixTranslator.translateCast(RexToLixTranslator.java:543)
> at
> org.apache.calcite.adapter.enumerable.RexImpTable$CastImplementor.implementSafe(RexImpTable.java:2450)
> at
> org.apache.calcite.adapter.enumerable.RexImpTable$AbstractRexCallImplementor.genValueStatement(RexImpTable.java:2894)
> at
> org.apache.calcite.adapter.enumerable.RexImpTable$AbstractRexCallImplementor.implement(RexImpTable.java:2859)
> at
> org.apache.calcite.adapter.enumerable.RexToLixTranslator.visitCall(RexToLixTranslator.java:1089)
> at
> org.apache.calcite.adapter.enumerable.RexToLixTranslator.visitCall(RexToLixTranslator.java:90)
> at org.apache.calcite.rex.RexCall.accept(RexCall.java:174) at
> org.apache.calcite.adapter.enumerable.RexToLixTranslator.visitLocalRef(RexToLixTranslator.java:975)
> at
> org.apache.calcite.adapter.enumerable.RexToLixTranslator.visitLocalRef(RexToLixTranslator.java:90)
> at org.apache.calcite.rex.RexLocalRef.accept(RexLocalRef.java:75) at
> org.apache.calcite.adapter.enumerable.RexToLixTranslator.translate(RexToLixTranslator.java:237)
> at
> org.apache.calcite.adapter.enumerable.RexToLixTranslator.translate(RexToLixTranslator.java:231)
> at
> org.apache.calcite.adapter.enumerable.RexToLixTranslator.translateList(RexToLixTranslator.java:823)
> at
> org.apache.calcite.adapter.enumerable.RexToLixTranslator.translateProjects(RexToLixTranslator.java:198)
> at org.apache.calcite.rex.RexExecutorImpl.compile(RexExecutorImpl.java:90)
> at org.apache.calcite.rex.RexExecutorImpl.compile(RexExecutorImpl.java:66) at
> org.apache.calcite.rex.RexExecutorImpl.reduce(RexExecutorImpl.java:128) at
> org.apache.calcite.rex.RexSimplify.simplifyCast(RexSimplify.java:2101) at
> org.apache.calcite.rex.RexSimplify.simplify(RexSimplify.java:326) at
> org.apache.calcite.rex.RexSimplify.simplifyUnknownAs(RexSimplify.java:287) at
> org.apache.flink.table.examples.java.tests.CalciteTest.main(CalciteTest.java:47)
> Caused by: java.lang.NoSuchMethodException:
> java.math.BigDecimal.booleanValue() at
> java.lang.Class.getMethod(Class.java:1786) at
> org.apache.calcite.linq4j.tree.Expressions.call(Expressions.java:421) ... 25
> more
> {code}
> In order to avoid that I used the wrong rule or it caused by my bad coding, i
> write the test case following:
>
> {code:java}
> // code placeholder
> JavaTypeFactory typeFactory = new
> JavaTypeFactoryImpl(RelDataTypeSystem.DEFAULT);
> RexBuilder rexBuilder = new RexBuilder(typeFactory);
> final RexSimplify simplify = new RexSimplify(rexBuilder,
> RelOptPredicateList.EMPTY, RexUtil.EXECUTOR);
> RelDataType type = new BasicSqlType(typeFactory.getTypeSystem(),
> SqlTypeName.BOOLEAN);
> RelDataType bb = new
> BasicSqlType(typeFactory.getTypeSystem(),SqlTypeName.DECIMAL,18,17);
> SqlOperator op = new SqlCastFunction();
> RexLiteral lt =
> rexBuilder.makeExactLiteral(BigDecimal.valueOf(0.10915913549909961),bb);
> List list = new ArrayList<>();
> list.add(lt);
> RexNode rexNode = rexBuilder.makeCall(type,op,list);
> simplify.simplifyUnknownAs(rexNode, RexUnknownAs.UNKNOWN);
> {code}
> and it throws the same exception.
>
> Actually, the cast simplify operation will enter the function _tr
[jira] [Commented] (CALCITE-4837) FLOOR and CEIL of DATE/TIMESTAMP return wrong results for DECADE, CENTURY and MILLENNIUM
[
https://issues.apache.org/jira/browse/CALCITE-4837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17425963#comment-17425963
]
Sergey Nuyanzin commented on CALCITE-4837:
--
thanks, I updated expected values in description accordingly
> FLOOR and CEIL of DATE/TIMESTAMP return wrong results for DECADE, CENTURY and
> MILLENNIUM
>
>
> Key: CALCITE-4837
> URL: https://issues.apache.org/jira/browse/CALCITE-4837
> Project: Calcite
> Issue Type: Bug
> Components: avatica, core
>Reporter: Sergey Nuyanzin
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> The query to reproduce
> {code:sql}
> select floor(t to decade) as floor_decade,
> ceil(t to decade) as ceil_decade,
> floor(t to century) as floor_century,
> ceil(t to century) as ceil_century,
> floor(t to millennium) as floor_millennium,
> ceil(t to millennium) as ceil_millennium
> from (values(date '2021-10-07')) t;
> {code}
> it produces output
> {noformat}
> +--+-+--+--+--+-+
> | FLOOR_DECADE | CEIL_DECADE | FLOOR_CENTURY | CEIL_CENTURY |
> FLOOR_MILLENNIUM | CEIL_MILLENNIUM |
> +--+-+--+--+--+-+
> | 2021-08-01 | 2021-11-29 | 2019-04-14 | 2022-07-27 | 2002-11-09
> | 2035-09-17 |
> +--+-+--+--+--+-+
> {noformat}
> expected
> {noformat}
> +--+-+--+--+--+-+
> | FLOOR_DECADE | CEIL_DECADE | FLOOR_CENTURY | CEIL_CENTURY |
> FLOOR_MILLENNIUM | CEIL_MILLENNIUM |
> +--+-+--+--+--+-+
> | 2020-01-01 | 2030-01-01 | 2001-01-01 | 2101-01-01 | 2001-01-01
> | 3001-01-01 |
> +--+-+--+--+--+-+
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-4837) FLOOR and CEIL of DATE/TIMESTAMP return wrong results for DECADE, CENTURY and MILLENNIUM
[
https://issues.apache.org/jira/browse/CALCITE-4837?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Nuyanzin updated CALCITE-4837:
-
Description:
The query to reproduce
{code:sql}
select floor(t to decade) as floor_decade,
ceil(t to decade) as ceil_decade,
floor(t to century) as floor_century,
ceil(t to century) as ceil_century,
floor(t to millennium) as floor_millennium,
ceil(t to millennium) as ceil_millennium
from (values(date '2021-10-07')) t;
{code}
it produces output
{noformat}
+--+-+--+--+--+-+
| FLOOR_DECADE | CEIL_DECADE | FLOOR_CENTURY | CEIL_CENTURY | FLOOR_MILLENNIUM
| CEIL_MILLENNIUM |
+--+-+--+--+--+-+
| 2021-08-01 | 2021-11-29 | 2019-04-14 | 2022-07-27 | 2002-11-09 |
2035-09-17 |
+--+-+--+--+--+-+
{noformat}
expected
{noformat}
+--+-+--+--+--+-+
| FLOOR_DECADE | CEIL_DECADE | FLOOR_CENTURY | CEIL_CENTURY | FLOOR_MILLENNIUM
| CEIL_MILLENNIUM |
+--+-+--+--+--+-+
| 2020-01-01 | 2030-01-01 | 2001-01-01 | 2101-01-01 | 2001-01-01 |
3001-01-01 |
+--+-+--+--+--+-+
{noformat}
was:
The query to reproduce
{code:sql}
select floor(t to decade) as floor_decade,
ceil(t to decade) as ceil_decade,
floor(t to century) as floor_century,
ceil(t to century) as ceil_century,
floor(t to millennium) as floor_millennium,
ceil(t to millennium) as ceil_millennium
from (values(date '2021-10-07')) t;
{code}
it produces output
{noformat}
+--+-+--+--+--+-+
| FLOOR_DECADE | CEIL_DECADE | FLOOR_CENTURY | CEIL_CENTURY | FLOOR_MILLENNIUM
| CEIL_MILLENNIUM |
+--+-+--+--+--+-+
| 2021-08-01 | 2021-11-29 | 2019-04-14 | 2022-07-27 | 2002-11-09 |
2035-09-17 |
+--+-+--+--+--+-+
{noformat}
expected
{noformat}
+--+-+--+--+--+-+
| FLOOR_DECADE | CEIL_DECADE | FLOOR_CENTURY | CEIL_CENTURY | FLOOR_MILLENNIUM
| CEIL_MILLENNIUM |
+--+-+--+--+--+-+
| 2020-01-01 | 2030-01-01 | 2000-01-01 | 2100-01-01 | 2000-01-01 |
3000-01-01 |
+--+-+--+--+--+-+
{noformat}
> FLOOR and CEIL of DATE/TIMESTAMP return wrong results for DECADE, CENTURY and
> MILLENNIUM
>
>
> Key: CALCITE-4837
> URL: https://issues.apache.org/jira/browse/CALCITE-4837
> Project: Calcite
> Issue Type: Bug
> Components: avatica, core
>Reporter: Sergey Nuyanzin
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> The query to reproduce
> {code:sql}
> select floor(t to decade) as floor_decade,
> ceil(t to decade) as ceil_decade,
> floor(t to century) as floor_century,
> ceil(t to century) as ceil_century,
> floor(t to millennium) as floor_millennium,
> ceil(t to millennium) as ceil_millennium
> from (values(date '2021-10-07')) t;
> {code}
> it produces output
> {noformat}
> +--+-+--+--+--+-+
> | FLOOR_DECADE | CEIL_DECADE | FLOOR_CENTURY | CEIL_CENTURY |
> FLOOR_MILLENNIUM | CEIL_MILLENNIUM |
> +--+-+--+--+--+-+
> | 2021-08-01 | 2021-11-29 | 2019-04-14 | 2022-07-27 | 2002-11-09
> | 2035-09-17 |
> +--+-+--+--+--+-+
> {noformat}
> expected
> {noformat}
> +--+-+--+--+--+-+
> | FLOOR_DECADE | CEIL_DECADE | FLOOR_CENTURY | CEIL_CENTURY |
> FLOOR_MILLENNIUM | CEIL_MILLENNIUM |
> +--+-+--+--+--+-+
> | 2020-01-01 | 2030-01-01 | 2001-01-01 | 2101-01-01 | 2001-01-01
> | 3001-01-01 |
> +--+-+--
[jira] [Commented] (CALCITE-4810) Failed to cast a double field (which isn't a literal) to boolean in the test case.
[
https://issues.apache.org/jira/browse/CALCITE-4810?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17425909#comment-17425909
]
xuyangzhong commented on CALCITE-4810:
--
Maybe this issue can be closed because now we all support that casting from
double to boolean is invalid.
> Failed to cast a double field (which isn't a literal) to boolean in the test
> case.
> --
>
> Key: CALCITE-4810
> URL: https://issues.apache.org/jira/browse/CALCITE-4810
> Project: Calcite
> Issue Type: Bug
>Reporter: xuyangzhong
>Priority: Minor
>
> The cause of this matter is that when I add a test case in
> SqlOperatorBaseTest:
> {code:java}
> // code placeholder
> @Test void myTest(){
> tester.checkBoolean("cast(0.1e0 as boolean)",false);
> }
> {code}
> The tester will turn the single sql to these two SQLs which will be all
> tested:
> {code:java}
> // SQL 1
> values (cast(0.1e0 as boolean))
> // SQL 2
> select cast(p0 as boolean) from (values (0.1e0)) as t(p0)
> {code}
> The SQL1 passed by the RexSimplify. But The SQL2 throws a exception following:
> {code:java}
> // code placeholder
> java.sql.SQLException: Error while executing SQL "select cast(p0 as boolean)
> from (values (0.1e0)) as t(p0)": Error while compiling generated Java code:
> public org.apache.calcite.linq4j.Enumerable bind(final
> org.apache.calcite.DataContext root) {
> final org.apache.calcite.linq4j.Enumerable _inputEnumerable =
> org.apache.calcite.linq4j.Linq4j.asEnumerable(new Double[] {
> 0.1D});
> return new org.apache.calcite.linq4j.AbstractEnumerable(){
> public org.apache.calcite.linq4j.Enumerator enumerator() {
> return new org.apache.calcite.linq4j.Enumerator(){
> public final org.apache.calcite.linq4j.Enumerator
> inputEnumerator = _inputEnumerable.enumerator();
> public void reset() {
> inputEnumerator.reset();
> }
>
> public boolean moveNext() {
> return inputEnumerator.moveNext();
> }
>
> public void close() {
> inputEnumerator.close();
> }
>
> public Object current() {
> return (boolean)
> org.apache.calcite.runtime.SqlFunctions.toDouble(inputEnumerator.current());
> }
>
> };
> }
>
> };
> }
>
>
> public Class getElementType() {
> return boolean.class;
> }
>
>
>
> at org.apache.calcite.avatica.Helper.createException(Helper.java:56)
> at org.apache.calcite.avatica.Helper.createException(Helper.java:41)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:163)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeQuery(AvaticaStatement.java:227)
> at
> org.apache.calcite.sql.test.SqlOperatorBaseTest$TesterImpl.check(SqlOperatorBaseTest.java:10371)
> at
> org.apache.calcite.sql.test.AbstractSqlTester.check(AbstractSqlTester.java:464)
> at
> org.apache.calcite.sql.test.AbstractSqlTester.checkBoolean(AbstractSqlTester.java:433)
> at
> org.apache.calcite.sql.test.SqlOperatorBaseTest.myTest(SqlOperatorBaseTest.java:1619)
> at
> org.junit.platform.commons.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:675)
> at
> org.junit.jupiter.engine.execution.MethodInvocation.proceed(MethodInvocation.java:60)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain$ValidatingInvocation.proceed(InvocationInterceptorChain.java:125)
> at
> org.junit.jupiter.engine.extension.TimeoutInvocation.proceed(TimeoutInvocation.java:46)
> at
> org.junit.jupiter.engine.extension.TimeoutExtension.intercept(TimeoutExtension.java:139)
> at
> org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestableMethod(TimeoutExtension.java:131)
> at
> org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestMethod(TimeoutExtension.java:81)
> at
> org.junit.jupiter.engine.execution.ExecutableInvoker$ReflectiveInterceptorCall.lambda$ofVoidMethod$0(ExecutableInvoker.java:115)
> at
> org.junit.jupiter.engine.execution.ExecutableInvoker.lambda$invoke$0(ExecutableInvoker.java:105)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain$InterceptedInvocation.proceed(InvocationInterceptorChain.java:104)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain.proceed(InvocationInterceptorChain.java:62)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain.chainAndInvoke(InvocationInterceptorChain.java
[jira] [Assigned] (CALCITE-4840) Avatica readme for source release should have better build instructions
[
https://issues.apache.org/jira/browse/CALCITE-4840?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacques Nadeau reassigned CALCITE-4840:
---
Assignee: Jacques Nadeau
> Avatica readme for source release should have better build instructions
> ---
>
> Key: CALCITE-4840
> URL: https://issues.apache.org/jira/browse/CALCITE-4840
> Project: Calcite
> Issue Type: Improvement
> Components: avatica
>Reporter: Jacques Nadeau
>Assignee: Jacques Nadeau
>Priority: Major
> Labels: newbie
>
> Right now, trying to figure out how you should build from the source release
> is too difficult (unless I missed something). To find the rather meagre
> instructions, you have to:
> # Open the README and see it says use README.md
> # Open README.md and follow the link to the avatica home
> # Click develop
> # Click avatica development guide link
> # Find and click "build from a source distribution"
> Good luck to someone to find that path :)
> When you get there, it states java 8 or later but trying to build with Java
> 17 fails. For reference, jvm I was using:
> {{% java --version}}
> {{openjdk 17 2021-09-14 LTS}}
> {{OpenJDK Runtime Environment Corretto-17.0.0.35.2 (build 17+35-LTS)}}
> {{OpenJDK 64-Bit Server VM Corretto-17.0.0.35.2 (build 17+35-LTS, mixed mode,
> sharing)}}
>
> Ideally the readme (or an install.md or a single click) should include:
> * Prerequisites to build (gradle 6.8.1 and Java 8?)
> * How to check signature
> * How to build & test
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-4840) Avatica readme for source release should have better build instructions
[
https://issues.apache.org/jira/browse/CALCITE-4840?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17425877#comment-17425877
]
Jacques Nadeau commented on CALCITE-4840:
-
One other note, it's weird that there are two readmes and they have different
information. Any rationale? I think most projects just have a single md (I
don't have any numbers to back this up).
> Avatica readme for source release should have better build instructions
> ---
>
> Key: CALCITE-4840
> URL: https://issues.apache.org/jira/browse/CALCITE-4840
> Project: Calcite
> Issue Type: Improvement
> Components: avatica
>Reporter: Jacques Nadeau
>Priority: Major
> Labels: newbie
>
> Right now, trying to figure out how you should build from the source release
> is too difficult (unless I missed something). To find the rather meagre
> instructions, you have to:
> # Open the README and see it says use README.md
> # Open README.md and follow the link to the avatica home
> # Click develop
> # Click avatica development guide link
> # Find and click "build from a source distribution"
> Good luck to someone to find that path :)
> When you get there, it states java 8 or later but trying to build with Java
> 17 fails. For reference, jvm I was using:
> {{% java --version}}
> {{openjdk 17 2021-09-14 LTS}}
> {{OpenJDK Runtime Environment Corretto-17.0.0.35.2 (build 17+35-LTS)}}
> {{OpenJDK 64-Bit Server VM Corretto-17.0.0.35.2 (build 17+35-LTS, mixed mode,
> sharing)}}
>
> Ideally the readme (or an install.md or a single click) should include:
> * Prerequisites to build (gradle 6.8.1 and Java 8?)
> * How to check signature
> * How to build & test
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-4840) Avatica readme for source release should have better build instructions
[
https://issues.apache.org/jira/browse/CALCITE-4840?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17425874#comment-17425874
]
Jacques Nadeau commented on CALCITE-4840:
-
You're right, I missed it. :)
It could be the I'm the only one too impatient to find it but I bet others
might miss it too. I'm inclined to post a patch adjusting the readme so the
information is more hierarchical.
> Avatica readme for source release should have better build instructions
> ---
>
> Key: CALCITE-4840
> URL: https://issues.apache.org/jira/browse/CALCITE-4840
> Project: Calcite
> Issue Type: Improvement
> Components: avatica
>Reporter: Jacques Nadeau
>Priority: Major
> Labels: newbie
>
> Right now, trying to figure out how you should build from the source release
> is too difficult (unless I missed something). To find the rather meagre
> instructions, you have to:
> # Open the README and see it says use README.md
> # Open README.md and follow the link to the avatica home
> # Click develop
> # Click avatica development guide link
> # Find and click "build from a source distribution"
> Good luck to someone to find that path :)
> When you get there, it states java 8 or later but trying to build with Java
> 17 fails. For reference, jvm I was using:
> {{% java --version}}
> {{openjdk 17 2021-09-14 LTS}}
> {{OpenJDK Runtime Environment Corretto-17.0.0.35.2 (build 17+35-LTS)}}
> {{OpenJDK 64-Bit Server VM Corretto-17.0.0.35.2 (build 17+35-LTS, mixed mode,
> sharing)}}
>
> Ideally the readme (or an install.md or a single click) should include:
> * Prerequisites to build (gradle 6.8.1 and Java 8?)
> * How to check signature
> * How to build & test
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-4840) Avatica readme for source release should have better build instructions
[
https://issues.apache.org/jira/browse/CALCITE-4840?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17425870#comment-17425870
]
Julian Hyde commented on CALCITE-4840:
--
{quote}unless I missed something{quote}
Yes, you missed something. In the {{README}}, it says
{quote}
If this is a source distribution, you can find instructions how to
build the release in the "Building from a source distribution" section
in site/_docs/howto.md.
{quote}
In {{README}}, the only reference to {{README.md}} is
{quote}
README.md contains examples of running Avatica.
{quote}
so I'm not sure why you went there for build instructions.
{quote}
When you get there, it states java 8 or later but trying to build with Java 17
fails.
{quote}
Yes, we should fix that. Until recently we could build on all versions of Java,
but then they released JDK 16 and 17 and we didn't do the necessary to support
them.
> Avatica readme for source release should have better build instructions
> ---
>
> Key: CALCITE-4840
> URL: https://issues.apache.org/jira/browse/CALCITE-4840
> Project: Calcite
> Issue Type: Improvement
> Components: avatica
>Reporter: Jacques Nadeau
>Priority: Major
> Labels: newbie
>
> Right now, trying to figure out how you should build from the source release
> is too difficult (unless I missed something). To find the rather meagre
> instructions, you have to:
> # Open the README and see it says use README.md
> # Open README.md and follow the link to the avatica home
> # Click develop
> # Click avatica development guide link
> # Find and click "build from a source distribution"
> Good luck to someone to find that path :)
> When you get there, it states java 8 or later but trying to build with Java
> 17 fails. For reference, jvm I was using:
> {{% java --version}}
> {{openjdk 17 2021-09-14 LTS}}
> {{OpenJDK Runtime Environment Corretto-17.0.0.35.2 (build 17+35-LTS)}}
> {{OpenJDK 64-Bit Server VM Corretto-17.0.0.35.2 (build 17+35-LTS, mixed mode,
> sharing)}}
>
> Ideally the readme (or an install.md or a single click) should include:
> * Prerequisites to build (gradle 6.8.1 and Java 8?)
> * How to check signature
> * How to build & test
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-4840) Avatica readme for source release should have better build instructions
[
https://issues.apache.org/jira/browse/CALCITE-4840?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacques Nadeau updated CALCITE-4840:
Labels: newbie (was: )
> Avatica readme for source release should have better build instructions
> ---
>
> Key: CALCITE-4840
> URL: https://issues.apache.org/jira/browse/CALCITE-4840
> Project: Calcite
> Issue Type: Improvement
> Components: avatica
>Reporter: Jacques Nadeau
>Priority: Major
> Labels: newbie
>
> Right now, trying to figure out how you should build from the source release
> is too difficult (unless I missed something). To find the rather meagre
> instructions, you have to:
> # Open the README and see it says use README.md
> # Open README.md and follow the link to the avatica home
> # Click develop
> # Click avatica development guide link
> # Find and click "build from a source distribution"
> Good luck to someone to find that path :)
> When you get there, it states java 8 or later but trying to build with Java
> 17 fails. For reference, jvm I was using:
> {{% java --version}}
> {{openjdk 17 2021-09-14 LTS}}
> {{OpenJDK Runtime Environment Corretto-17.0.0.35.2 (build 17+35-LTS)}}
> {{OpenJDK 64-Bit Server VM Corretto-17.0.0.35.2 (build 17+35-LTS, mixed mode,
> sharing)}}
>
> Ideally the readme (or an install.md or a single click) should include:
> * Prerequisites to build (gradle 6.8.1 and Java 8?)
> * How to check signature
> * How to build & test
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-4840) Avatica readme for source release should have better build instructions
[
https://issues.apache.org/jira/browse/CALCITE-4840?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacques Nadeau updated CALCITE-4840:
Summary: Avatica readme for source release should have better build
instructions (was: Avatica readme from source release should have better build
instructions)
> Avatica readme for source release should have better build instructions
> ---
>
> Key: CALCITE-4840
> URL: https://issues.apache.org/jira/browse/CALCITE-4840
> Project: Calcite
> Issue Type: Improvement
> Components: avatica
>Reporter: Jacques Nadeau
>Priority: Major
>
> Right now, trying to figure out how you should build from the source release
> is too difficult (unless I missed something). To find the rather meagre
> instructions, you have to:
> # Open the README and see it says use README.md
> # Open README.md and follow the link to the avatica home
> # Click develop
> # Click avatica development guide link
> # Find and click "build from a source distribution"
> Good luck to someone to find that path :)
> When you get there, it states java 8 or later but trying to build with Java
> 17 fails. For reference, jvm I was using:
> {{% java --version}}
> {{openjdk 17 2021-09-14 LTS}}
> {{OpenJDK Runtime Environment Corretto-17.0.0.35.2 (build 17+35-LTS)}}
> {{OpenJDK 64-Bit Server VM Corretto-17.0.0.35.2 (build 17+35-LTS, mixed mode,
> sharing)}}
>
> Ideally the readme (or an install.md or a single click) should include:
> * Prerequisites to build (gradle 6.8.1 and Java 8?)
> * How to check signature
> * How to build & test
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-4840) Avatica readme from source release should have better build instructions
[
https://issues.apache.org/jira/browse/CALCITE-4840?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacques Nadeau updated CALCITE-4840:
Summary: Avatica readme from source release should have better build
instructions (was: Readme from source release clearly state how to build)
> Avatica readme from source release should have better build instructions
>
>
> Key: CALCITE-4840
> URL: https://issues.apache.org/jira/browse/CALCITE-4840
> Project: Calcite
> Issue Type: Improvement
> Components: avatica
>Reporter: Jacques Nadeau
>Priority: Major
>
> Right now, trying to figure out how you should build from the source release
> is too difficult (unless I missed something). To find the rather meagre
> instructions, you have to:
> # Open the README and see it says use README.md
> # Open README.md and follow the link to the avatica home
> # Click develop
> # Click avatica development guide link
> # Find and click "build from a source distribution"
> Good luck to someone to find that path :)
> When you get there, it states java 8 or later but trying to build with Java
> 17 fails. For reference, jvm I was using:
> {{% java --version}}
> {{openjdk 17 2021-09-14 LTS}}
> {{OpenJDK Runtime Environment Corretto-17.0.0.35.2 (build 17+35-LTS)}}
> {{OpenJDK 64-Bit Server VM Corretto-17.0.0.35.2 (build 17+35-LTS, mixed mode,
> sharing)}}
>
> Ideally the readme (or an install.md or a single click) should include:
> * Prerequisites to build (gradle 6.8.1 and Java 8?)
> * How to check signature
> * How to build & test
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (CALCITE-4840) Readme from source release clearly state how to build
Jacques Nadeau created CALCITE-4840:
---
Summary: Readme from source release clearly state how to build
Key: CALCITE-4840
URL: https://issues.apache.org/jira/browse/CALCITE-4840
Project: Calcite
Issue Type: Improvement
Components: avatica
Reporter: Jacques Nadeau
Right now, trying to figure out how you should build from the source release is
too difficult (unless I missed something). To find the rather meagre
instructions, you have to:
# Open the README and see it says use README.md
# Open README.md and follow the link to the avatica home
# Click develop
# Click avatica development guide link
# Find and click "build from a source distribution"
Good luck to someone to find that path :)
When you get there, it states java 8 or later but trying to build with Java 17
fails. For reference, jvm I was using:
{{% java --version}}
{{openjdk 17 2021-09-14 LTS}}
{{OpenJDK Runtime Environment Corretto-17.0.0.35.2 (build 17+35-LTS)}}
{{OpenJDK 64-Bit Server VM Corretto-17.0.0.35.2 (build 17+35-LTS, mixed mode,
sharing)}}
Ideally the readme (or an install.md or a single click) should include:
* Prerequisites to build (gradle 6.8.1 and Java 8?)
* How to check signature
* How to build & test
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (CALCITE-4837) FLOOR and CEIL of DATE/TIMESTAMP return wrong results for DECADE, CENTURY and MILLENNIUM
[
https://issues.apache.org/jira/browse/CALCITE-4837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17425769#comment-17425769
]
Julian Hyde edited comment on CALCITE-4837 at 10/7/21, 8:00 PM:
Ok, so the following formulas probably work:
* {{millennium\(y) = floor((y + 999) / 1000)}},
* {{century\(y) = floor((y + 99) / 100)}}.
Just in case people misunderstand what you wrote. For SQL's purposes, it
doesn't matter whether we are in a 'Gregorian calendar country'. EXTRACT, FLOOR
and CEIL do not consult timezone or locale, just work on a zoneless DATE or
TIMESTAMP value.
was (Author: julianhyde):
Ok, so the following formulas probably work:
* {{millennium(y) = floor((y + 999) / 1000)}},
* {{century(y) = floor((y + 99) / 100)}}.
Just in case people misunderstand what you wrote. For SQL's purposes, it
doesn't matter whether we are in a 'Gregorian calendar country'. EXTRACT, FLOOR
and CEIL do not consult timezone or locale, just work on a zoneless DATE or
TIMESTAMP value.
> FLOOR and CEIL of DATE/TIMESTAMP return wrong results for DECADE, CENTURY and
> MILLENNIUM
>
>
> Key: CALCITE-4837
> URL: https://issues.apache.org/jira/browse/CALCITE-4837
> Project: Calcite
> Issue Type: Bug
> Components: avatica, core
>Reporter: Sergey Nuyanzin
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The query to reproduce
> {code:sql}
> select floor(t to decade) as floor_decade,
> ceil(t to decade) as ceil_decade,
> floor(t to century) as floor_century,
> ceil(t to century) as ceil_century,
> floor(t to millennium) as floor_millennium,
> ceil(t to millennium) as ceil_millennium
> from (values(date '2021-10-07')) t;
> {code}
> it produces output
> {noformat}
> +--+-+--+--+--+-+
> | FLOOR_DECADE | CEIL_DECADE | FLOOR_CENTURY | CEIL_CENTURY |
> FLOOR_MILLENNIUM | CEIL_MILLENNIUM |
> +--+-+--+--+--+-+
> | 2021-08-01 | 2021-11-29 | 2019-04-14 | 2022-07-27 | 2002-11-09
> | 2035-09-17 |
> +--+-+--+--+--+-+
> {noformat}
> expected
> {noformat}
> +--+-+--+--+--+-+
> | FLOOR_DECADE | CEIL_DECADE | FLOOR_CENTURY | CEIL_CENTURY |
> FLOOR_MILLENNIUM | CEIL_MILLENNIUM |
> +--+-+--+--+--+-+
> | 2020-01-01 | 2030-01-01 | 2000-01-01 | 2100-01-01 | 2000-01-01
> | 3000-01-01 |
> +--+-+--+--+--+-+
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-4837) FLOOR and CEIL of DATE/TIMESTAMP return wrong results for DECADE, CENTURY and MILLENNIUM
[
https://issues.apache.org/jira/browse/CALCITE-4837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17425769#comment-17425769
]
Julian Hyde commented on CALCITE-4837:
--
Ok, so the following formulas probably work:
* {{millennium(y) = floor((y + 999) / 1000)}},
* {{century(y) = floor((y + 99) / 100)}}.
Just in case people misunderstand what you wrote. For SQL's purposes, it
doesn't matter whether we are in a 'Gregorian calendar country'. EXTRACT, FLOOR
and CEIL do not consult timezone or locale, just work on a zoneless DATE or
TIMESTAMP value.
> FLOOR and CEIL of DATE/TIMESTAMP return wrong results for DECADE, CENTURY and
> MILLENNIUM
>
>
> Key: CALCITE-4837
> URL: https://issues.apache.org/jira/browse/CALCITE-4837
> Project: Calcite
> Issue Type: Bug
> Components: avatica, core
>Reporter: Sergey Nuyanzin
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The query to reproduce
> {code:sql}
> select floor(t to decade) as floor_decade,
> ceil(t to decade) as ceil_decade,
> floor(t to century) as floor_century,
> ceil(t to century) as ceil_century,
> floor(t to millennium) as floor_millennium,
> ceil(t to millennium) as ceil_millennium
> from (values(date '2021-10-07')) t;
> {code}
> it produces output
> {noformat}
> +--+-+--+--+--+-+
> | FLOOR_DECADE | CEIL_DECADE | FLOOR_CENTURY | CEIL_CENTURY |
> FLOOR_MILLENNIUM | CEIL_MILLENNIUM |
> +--+-+--+--+--+-+
> | 2021-08-01 | 2021-11-29 | 2019-04-14 | 2022-07-27 | 2002-11-09
> | 2035-09-17 |
> +--+-+--+--+--+-+
> {noformat}
> expected
> {noformat}
> +--+-+--+--+--+-+
> | FLOOR_DECADE | CEIL_DECADE | FLOOR_CENTURY | CEIL_CENTURY |
> FLOOR_MILLENNIUM | CEIL_MILLENNIUM |
> +--+-+--+--+--+-+
> | 2020-01-01 | 2030-01-01 | 2000-01-01 | 2100-01-01 | 2000-01-01
> | 3000-01-01 |
> +--+-+--+--+--+-+
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-4837) FLOOR and CEIL of DATE/TIMESTAMP return wrong results for DECADE, CENTURY and MILLENNIUM
[
https://issues.apache.org/jira/browse/CALCITE-4837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17425766#comment-17425766
]
Sergey Nuyanzin commented on CALCITE-4837:
--
Agree, I also have a look across dbs. PostgreSQL[1] and Vertica[2] support
{{DECADE}}, {{CENTURY}}, {{MILLENNIUM}}
And for both the definition is the same
{{DECADE}} - The year field divided by 10
{{CENTURY}} - The first century starts at 0001-01-01 00:00:00 AD, although they
did not know it at the time. This definition applies to all Gregorian calendar
countries. There is no century number 0, you go from -1 century to 1 century.
{{MILLENNIUM}} - The millennium number, where the first millennium is 1 and
each millenium starts on 01-01-y001. For example, millennium 2 starts on
01-01-1001.
[1]
https://www.postgresql.org/docs/14/functions-datetime.html#FUNCTIONS-DATETIME-EXTRACT
[2]
https://www.vertica.com/docs/9.2.x/HTML/Content/Authoring/SQLReferenceManual/Functions/Date-Time/DATE_PART.htm
> FLOOR and CEIL of DATE/TIMESTAMP return wrong results for DECADE, CENTURY and
> MILLENNIUM
>
>
> Key: CALCITE-4837
> URL: https://issues.apache.org/jira/browse/CALCITE-4837
> Project: Calcite
> Issue Type: Bug
> Components: avatica, core
>Reporter: Sergey Nuyanzin
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The query to reproduce
> {code:sql}
> select floor(t to decade) as floor_decade,
> ceil(t to decade) as ceil_decade,
> floor(t to century) as floor_century,
> ceil(t to century) as ceil_century,
> floor(t to millennium) as floor_millennium,
> ceil(t to millennium) as ceil_millennium
> from (values(date '2021-10-07')) t;
> {code}
> it produces output
> {noformat}
> +--+-+--+--+--+-+
> | FLOOR_DECADE | CEIL_DECADE | FLOOR_CENTURY | CEIL_CENTURY |
> FLOOR_MILLENNIUM | CEIL_MILLENNIUM |
> +--+-+--+--+--+-+
> | 2021-08-01 | 2021-11-29 | 2019-04-14 | 2022-07-27 | 2002-11-09
> | 2035-09-17 |
> +--+-+--+--+--+-+
> {noformat}
> expected
> {noformat}
> +--+-+--+--+--+-+
> | FLOOR_DECADE | CEIL_DECADE | FLOOR_CENTURY | CEIL_CENTURY |
> FLOOR_MILLENNIUM | CEIL_MILLENNIUM |
> +--+-+--+--+--+-+
> | 2020-01-01 | 2030-01-01 | 2000-01-01 | 2100-01-01 | 2000-01-01
> | 3000-01-01 |
> +--+-+--+--+--+-+
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-4837) FLOOR and CEIL of DATE/TIMESTAMP return wrong results for DECADE, CENTURY and MILLENNIUM
[
https://issues.apache.org/jira/browse/CALCITE-4837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17425765#comment-17425765
]
Julian Hyde commented on CALCITE-4837:
--
I'll answer my own question. The semantics of CENTURY are clear in the fix to
CALCITE-1613. 2000 is in the 20th century, and 2001 is in the 21st century.
> FLOOR and CEIL of DATE/TIMESTAMP return wrong results for DECADE, CENTURY and
> MILLENNIUM
>
>
> Key: CALCITE-4837
> URL: https://issues.apache.org/jira/browse/CALCITE-4837
> Project: Calcite
> Issue Type: Bug
> Components: avatica, core
>Reporter: Sergey Nuyanzin
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The query to reproduce
> {code:sql}
> select floor(t to decade) as floor_decade,
> ceil(t to decade) as ceil_decade,
> floor(t to century) as floor_century,
> ceil(t to century) as ceil_century,
> floor(t to millennium) as floor_millennium,
> ceil(t to millennium) as ceil_millennium
> from (values(date '2021-10-07')) t;
> {code}
> it produces output
> {noformat}
> +--+-+--+--+--+-+
> | FLOOR_DECADE | CEIL_DECADE | FLOOR_CENTURY | CEIL_CENTURY |
> FLOOR_MILLENNIUM | CEIL_MILLENNIUM |
> +--+-+--+--+--+-+
> | 2021-08-01 | 2021-11-29 | 2019-04-14 | 2022-07-27 | 2002-11-09
> | 2035-09-17 |
> +--+-+--+--+--+-+
> {noformat}
> expected
> {noformat}
> +--+-+--+--+--+-+
> | FLOOR_DECADE | CEIL_DECADE | FLOOR_CENTURY | CEIL_CENTURY |
> FLOOR_MILLENNIUM | CEIL_MILLENNIUM |
> +--+-+--+--+--+-+
> | 2020-01-01 | 2030-01-01 | 2000-01-01 | 2100-01-01 | 2000-01-01
> | 3000-01-01 |
> +--+-+--+--+--+-+
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (CALCITE-4839) Remove remnants of ImmutableBeans post 1.28 release
Jacques Nadeau created CALCITE-4839: --- Summary: Remove remnants of ImmutableBeans post 1.28 release Key: CALCITE-4839 URL: https://issues.apache.org/jira/browse/CALCITE-4839 Project: Calcite Issue Type: Task Reporter: Jacques Nadeau Assignee: Jacques Nadeau This is final piece of work related to moving to Immutables. Once we release, we need to go through and remove all the shims to support deprecation. This includes deleting ImmutableBeans and the associated tests and annotations. We also need to remove the deprecated Config interfaces (where they have new names). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (CALCITE-4830) Remove remaining uses of ImmutableBeans and deprecate
[ https://issues.apache.org/jira/browse/CALCITE-4830?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacques Nadeau resolved CALCITE-4830. - Fix Version/s: 1.28.0 Resolution: Fixed Resolved in [3170c3f21687cf75045572844dcd51e19f41d40a|https://github.com/apache/calcite/commit/3170c3f21687cf75045572844dcd51e19f41d40a] Thanks to everyone for their assistance! > Remove remaining uses of ImmutableBeans and deprecate > - > > Key: CALCITE-4830 > URL: https://issues.apache.org/jira/browse/CALCITE-4830 > Project: Calcite > Issue Type: Improvement >Reporter: Jacques Nadeau >Assignee: Jacques Nadeau >Priority: Major > Labels: pull-request-available > Fix For: 1.28.0 > > Time Spent: 50m > Remaining Estimate: 0h > > Follow-on work from CALCITE-4787 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-4837) FLOOR and CEIL of DATE/TIMESTAMP return wrong results for DECADE, CENTURY and MILLENNIUM
[
https://issues.apache.org/jira/browse/CALCITE-4837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17425738#comment-17425738
]
Julian Hyde commented on CALCITE-4837:
--
Regarding MILLENNIUM. In our semantics, does the 3rd millennium starts on
2000-01-01 or 2001-01-01? Similarly CENTURY and DECADE.
Are our semantics consistent with other DBs? Reading [JooQ's implementation of
the MILLENNIUM
function|https://www.jooq.org/doc/latest/manual/sql-building/column-expressions/datetime-functions/millennium-function/]
it seems there is not consensus among other DBs. (Note that '(... + 999) /
1000' occurs in a few places.)
> FLOOR and CEIL of DATE/TIMESTAMP return wrong results for DECADE, CENTURY and
> MILLENNIUM
>
>
> Key: CALCITE-4837
> URL: https://issues.apache.org/jira/browse/CALCITE-4837
> Project: Calcite
> Issue Type: Bug
> Components: avatica, core
>Reporter: Sergey Nuyanzin
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The query to reproduce
> {code:sql}
> select floor(t to decade) as floor_decade,
> ceil(t to decade) as ceil_decade,
> floor(t to century) as floor_century,
> ceil(t to century) as ceil_century,
> floor(t to millennium) as floor_millennium,
> ceil(t to millennium) as ceil_millennium
> from (values(date '2021-10-07')) t;
> {code}
> it produces output
> {noformat}
> +--+-+--+--+--+-+
> | FLOOR_DECADE | CEIL_DECADE | FLOOR_CENTURY | CEIL_CENTURY |
> FLOOR_MILLENNIUM | CEIL_MILLENNIUM |
> +--+-+--+--+--+-+
> | 2021-08-01 | 2021-11-29 | 2019-04-14 | 2022-07-27 | 2002-11-09
> | 2035-09-17 |
> +--+-+--+--+--+-+
> {noformat}
> expected
> {noformat}
> +--+-+--+--+--+-+
> | FLOOR_DECADE | CEIL_DECADE | FLOOR_CENTURY | CEIL_CENTURY |
> FLOOR_MILLENNIUM | CEIL_MILLENNIUM |
> +--+-+--+--+--+-+
> | 2020-01-01 | 2030-01-01 | 2000-01-01 | 2100-01-01 | 2000-01-01
> | 3000-01-01 |
> +--+-+--+--+--+-+
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-4833) Complex nested correlated subquery failed.
[
https://issues.apache.org/jira/browse/CALCITE-4833?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-4833:
Labels: pull-request-available (was: )
> Complex nested correlated subquery failed.
> --
>
> Key: CALCITE-4833
> URL: https://issues.apache.org/jira/browse/CALCITE-4833
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.27.0
>Reporter: Evgeny Stanilovsky
>Priority: Major
> Labels: pull-request-available
> Attachments: test.patch
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Query like:
> {noformat}
> SELECT t1.empid FROM emps t1 LEFT JOIN emps t2 ON (SELECT t2.empid)<=100
> {noformat}
> failed with :
> {noformat}
> Required columns {5} not subset of left columns {0}
> java.lang.AssertionError: Required columns {5} not subset of left columns {0}
> at org.apache.calcite.util.Litmus$1.fail(Litmus.java:32)
> at org.apache.calcite.util.Litmus$1.check(Litmus.java:44)
> at org.apache.calcite.rel.core.Correlate.isValid(Correlate.java:127)
> at org.apache.calcite.rel.core.Correlate.(Correlate.java:104)
> at
> org.apache.calcite.rel.logical.LogicalCorrelate.(LogicalCorrelate.java:66)
> at
> org.apache.calcite.rel.logical.LogicalCorrelate.create(LogicalCorrelate.java:94)
> {noformat}
> failed test attached.
> The equal request forks fine:
> {noformat}
> SELECT t1.empid FROM emps t1 LEFT JOIN emps t2 ON t2.empid<=100
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-4838) add roundingMode in SqlConformance to document the rounding mode when cast an approximate numeric to int
[
https://issues.apache.org/jira/browse/CALCITE-4838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
duan xiong updated CALCITE-4838:
Description:
According to the SQL Strandard about how to cast an approximate numeric to int
in different database have different RoundingMode. for example:
In PostgreSQL、Mysql、Oracle(RoundingMode.HALF_UP):
{code:java}
select cast(5.1 as int) return 5
select cast(5.5 as int) return 6
select cast(-5.5 as int) return -6{code}
In Calcite、Sql Server 2008(RoundingMode.DOWN):
{code:java}
select cast(5.1 as int) return 5
select cast(5.5 as int) return 5
select cast(-5.5 as int) return -5
{code}
was:
According to the SQL Strandard about how to cast an approximate numeric to int
in different database have different RoundingMode. for example:
In PostgreSQL、Mysql、Oracle(RoundingMode.HALF_UP):
{code:java}
select cast(5.1 as int) return 5
select cast(5.5 as int) return 6
select cast(-5.5 as int) return -6{code}
In Calcite、Sql Server 2008(RoundingMode.DOWN):
{code:java}
select cast(5.1 as int) return 5
select cast(5.5 as int) return 5
{code}
> add roundingMode in SqlConformance to document the rounding mode when cast
> an approximate numeric to int
> -
>
> Key: CALCITE-4838
> URL: https://issues.apache.org/jira/browse/CALCITE-4838
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.27.0
>Reporter: duan xiong
>Assignee: duan xiong
>Priority: Major
>
> According to the SQL Strandard about how to cast an approximate numeric to
> int in different database have different RoundingMode. for example:
> In PostgreSQL、Mysql、Oracle(RoundingMode.HALF_UP):
> {code:java}
> select cast(5.1 as int) return 5
> select cast(5.5 as int) return 6
> select cast(-5.5 as int) return -6{code}
> In Calcite、Sql Server 2008(RoundingMode.DOWN):
> {code:java}
> select cast(5.1 as int) return 5
> select cast(5.5 as int) return 5
> select cast(-5.5 as int) return -5
> {code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-4838) add roundingMode in SqlConformance to document the rounding mode when cast an approximate numeric to int
[
https://issues.apache.org/jira/browse/CALCITE-4838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
duan xiong updated CALCITE-4838:
Description:
According to the SQL Strandard about how to cast an approximate numeric to int
in different database have different RoundingMode. for example:
In PostgreSQL、Mysql、Oracle(RoundingMode.HALF_UP):
{code:java}
select cast(5.1 as int) return 5
select cast(5.5 as int) return 6
select cast(-5.5 as int) return -6{code}
In Calcite、Sql Server 2008(RoundingMode.DOWN):
{code:java}
select cast(5.1 as int) return 5
select cast(5.5 as int) return 5
{code}
was:
According to the SQL Strandard about how to cast an approximate numeric to int
in different database have different RoundingMode. for example:
In PostgreSQL、Mysql、Oracle(RoundingMode.HALF_UP):
{code:java}
select cast(5.1 as int) return 5
select cast(5.5 as int) return 6
{code}
In Calcite、Sql Server 2008(RoundingMode.DOWN):
{code:java}
select cast(5.1 as int) return 5
select cast(5.5 as int) return 5
{code}
> add roundingMode in SqlConformance to document the rounding mode when cast
> an approximate numeric to int
> -
>
> Key: CALCITE-4838
> URL: https://issues.apache.org/jira/browse/CALCITE-4838
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.27.0
>Reporter: duan xiong
>Assignee: duan xiong
>Priority: Major
>
> According to the SQL Strandard about how to cast an approximate numeric to
> int in different database have different RoundingMode. for example:
> In PostgreSQL、Mysql、Oracle(RoundingMode.HALF_UP):
> {code:java}
> select cast(5.1 as int) return 5
> select cast(5.5 as int) return 6
> select cast(-5.5 as int) return -6{code}
> In Calcite、Sql Server 2008(RoundingMode.DOWN):
> {code:java}
> select cast(5.1 as int) return 5
> select cast(5.5 as int) return 5
> {code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-4838) add roundingMode in SqlConformance to document the rounding mode when cast an approximate numeric to int
[
https://issues.apache.org/jira/browse/CALCITE-4838?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17425715#comment-17425715
]
Julian Hyde commented on CALCITE-4838:
--
The minimum fix for this task would we support DOWN as rounding mode, and throw
if someone tries to set It to UP.
A more complete fix (or another JIRA case) would be to support both UP and
DOWN. Consider the query {{select cast(cast(deptno) as double) / 10 as integer)
from emp}}. Implementing that would affect Java code generation (if we are
implementing using Enumerable) and also affect SQL generation (if EMP is a
table from the JDBC adapter). We would probably need to know the rounding mode
of the target DB.
> add roundingMode in SqlConformance to document the rounding mode when cast
> an approximate numeric to int
> -
>
> Key: CALCITE-4838
> URL: https://issues.apache.org/jira/browse/CALCITE-4838
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.27.0
>Reporter: duan xiong
>Assignee: duan xiong
>Priority: Major
>
> According to the SQL Strandard about how to cast an approximate numeric to
> int in different database have different RoundingMode. for example:
> In PostgreSQL、Mysql、Oracle(RoundingMode.HALF_UP):
> {code:java}
> select cast(5.1 as int) return 5
> select cast(5.5 as int) return 6
> {code}
> In Calcite、Sql Server 2008(RoundingMode.DOWN):
> {code:java}
> select cast(5.1 as int) return 5
> select cast(5.5 as int) return 5
> {code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-4838) add roundingMode in SqlConformance to document the rounding mode when cast an approximate numeric to int
[
https://issues.apache.org/jira/browse/CALCITE-4838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
duan xiong updated CALCITE-4838:
Description:
According to the SQL Strandard about how to cast an approximate numeric to int
in different database have different RoundingMode. for example:
In PostgreSQL、Mysql、Oracle(RoundingMode.HALF_UP):
{code:java}
select cast(5.1 as int) return 5
select cast(5.5 as int) return 6
{code}
In Calcite、Sql Server 2008(RoundingMode.DOWN):
{code:java}
select cast(5.1 as int) return 5
select cast(5.5 as int) return 5
{code}
was:
According to the SQL Strandard about how to cast an approximate numeric to int
in different database have different RoundingMode. for example:
In PostgreSQL、Mysql、Oracle(RoundingMode.UP):
{code:java}
select cast(5.1 as int) return 5
select cast(5.5 as int) return 6
{code}
In Calcite、Sql Server 2008(RoundingMode.DOWN):
{code:java}
select cast(5.1 as int) return 5
select cast(5.5 as int) return 5
{code}
> add roundingMode in SqlConformance to document the rounding mode when cast
> an approximate numeric to int
> -
>
> Key: CALCITE-4838
> URL: https://issues.apache.org/jira/browse/CALCITE-4838
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.27.0
>Reporter: duan xiong
>Assignee: duan xiong
>Priority: Major
>
> According to the SQL Strandard about how to cast an approximate numeric to
> int in different database have different RoundingMode. for example:
> In PostgreSQL、Mysql、Oracle(RoundingMode.HALF_UP):
> {code:java}
> select cast(5.1 as int) return 5
> select cast(5.5 as int) return 6
> {code}
> In Calcite、Sql Server 2008(RoundingMode.DOWN):
> {code:java}
> select cast(5.1 as int) return 5
> select cast(5.5 as int) return 5
> {code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-4838) add roundingMode in SqlConformance to document the rounding mode when cast an approximate numeric to int
[
https://issues.apache.org/jira/browse/CALCITE-4838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
duan xiong updated CALCITE-4838:
Summary: add roundingMode in SqlConformance to document the rounding mode
when cast an approximate numeric to int (was: add roundingMode in
SqlConformance to document how to cast an approximate numeric to int)
> add roundingMode in SqlConformance to document the rounding mode when cast
> an approximate numeric to int
> -
>
> Key: CALCITE-4838
> URL: https://issues.apache.org/jira/browse/CALCITE-4838
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.27.0
>Reporter: duan xiong
>Assignee: duan xiong
>Priority: Major
>
> According to the SQL Strandard about how to cast an approximate numeric to
> int in different database have different RoundingMode. for example:
> In PostgreSQL、Mysql、Oracle(RoundingMode.UP):
> {code:java}
> select cast(5.1 as int) return 5
> select cast(5.5 as int) return 6
> {code}
> In Calcite、Sql Server 2008(RoundingMode.DOWN):
>
> {code:java}
> select cast(5.1 as int) return 5
> select cast(5.5 as int) return 5
> {code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-4838) add roundingMode in SqlConformance to document the rounding mode when cast an approximate numeric to int
[
https://issues.apache.org/jira/browse/CALCITE-4838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
duan xiong updated CALCITE-4838:
Description:
According to the SQL Strandard about how to cast an approximate numeric to int
in different database have different RoundingMode. for example:
In PostgreSQL、Mysql、Oracle(RoundingMode.UP):
{code:java}
select cast(5.1 as int) return 5
select cast(5.5 as int) return 6
{code}
In Calcite、Sql Server 2008(RoundingMode.DOWN):
{code:java}
select cast(5.1 as int) return 5
select cast(5.5 as int) return 5
{code}
was:
According to the SQL Strandard about how to cast an approximate numeric to int
in different database have different RoundingMode. for example:
In PostgreSQL、Mysql、Oracle(RoundingMode.UP):
{code:java}
select cast(5.1 as int) return 5
select cast(5.5 as int) return 6
{code}
In Calcite、Sql Server 2008(RoundingMode.DOWN):
{code:java}
select cast(5.1 as int) return 5
select cast(5.5 as int) return 5
{code}
> add roundingMode in SqlConformance to document the rounding mode when cast
> an approximate numeric to int
> -
>
> Key: CALCITE-4838
> URL: https://issues.apache.org/jira/browse/CALCITE-4838
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.27.0
>Reporter: duan xiong
>Assignee: duan xiong
>Priority: Major
>
> According to the SQL Strandard about how to cast an approximate numeric to
> int in different database have different RoundingMode. for example:
> In PostgreSQL、Mysql、Oracle(RoundingMode.UP):
> {code:java}
> select cast(5.1 as int) return 5
> select cast(5.5 as int) return 6
> {code}
> In Calcite、Sql Server 2008(RoundingMode.DOWN):
> {code:java}
> select cast(5.1 as int) return 5
> select cast(5.5 as int) return 5
> {code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (CALCITE-4838) add roundingMode in SqlConformance to document how to cast an approximate numeric to int
duan xiong created CALCITE-4838:
---
Summary: add roundingMode in SqlConformance to document how to
cast an approximate numeric to int
Key: CALCITE-4838
URL: https://issues.apache.org/jira/browse/CALCITE-4838
Project: Calcite
Issue Type: Bug
Components: core
Affects Versions: 1.27.0
Reporter: duan xiong
Assignee: duan xiong
According to the SQL Strandard about how to cast an approximate numeric to int
in different database have different RoundingMode. for example:
In PostgreSQL、Mysql、Oracle(RoundingMode.UP):
{code:java}
select cast(5.1 as int) return 5
select cast(5.5 as int) return 6
{code}
In Calcite、Sql Server 2008(RoundingMode.DOWN):
{code:java}
select cast(5.1 as int) return 5
select cast(5.5 as int) return 5
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-4837) FLOOR and CEIL of DATE/TIMESTAMP return wrong results for DECADE, CENTURY and MILLENNIUM
[
https://issues.apache.org/jira/browse/CALCITE-4837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17425674#comment-17425674
]
Alessandro Solimando commented on CALCITE-4837:
---
Oh I see [~Sergey Nuyanzin], thanks for the clarification, I confused "extract"
with "floor/ceil to" syntax!
> FLOOR and CEIL of DATE/TIMESTAMP return wrong results for DECADE, CENTURY and
> MILLENNIUM
>
>
> Key: CALCITE-4837
> URL: https://issues.apache.org/jira/browse/CALCITE-4837
> Project: Calcite
> Issue Type: Bug
> Components: avatica, core
>Reporter: Sergey Nuyanzin
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The query to reproduce
> {code:sql}
> select floor(t to decade) as floor_decade,
> ceil(t to decade) as ceil_decade,
> floor(t to century) as floor_century,
> ceil(t to century) as ceil_century,
> floor(t to millennium) as floor_millennium,
> ceil(t to millennium) as ceil_millennium
> from (values(date '2021-10-07')) t;
> {code}
> it produces output
> {noformat}
> +--+-+--+--+--+-+
> | FLOOR_DECADE | CEIL_DECADE | FLOOR_CENTURY | CEIL_CENTURY |
> FLOOR_MILLENNIUM | CEIL_MILLENNIUM |
> +--+-+--+--+--+-+
> | 2021-08-01 | 2021-11-29 | 2019-04-14 | 2022-07-27 | 2002-11-09
> | 2035-09-17 |
> +--+-+--+--+--+-+
> {noformat}
> expected
> {noformat}
> +--+-+--+--+--+-+
> | FLOOR_DECADE | CEIL_DECADE | FLOOR_CENTURY | CEIL_CENTURY |
> FLOOR_MILLENNIUM | CEIL_MILLENNIUM |
> +--+-+--+--+--+-+
> | 2020-01-01 | 2030-01-01 | 2000-01-01 | 2100-01-01 | 2000-01-01
> | 3000-01-01 |
> +--+-+--+--+--+-+
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-4837) FLOOR and CEIL of DATE/TIMESTAMP return wrong results for DECADE, CENTURY and MILLENNIUM
[
https://issues.apache.org/jira/browse/CALCITE-4837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17425669#comment-17425669
]
Sergey Nuyanzin commented on CALCITE-4837:
--
{quote}For instance, "decade" of "2020" is "202" for almost everyone, except
us.{quote}
In fact there are 3 possible functions here: {{EXTRACT}}, {{FLOOR}} and
{{CEIL}}.
{{EXTRACT}} does the thing as mentioned in links you provided, i.e.
{code:sql}
select extract(decade from date '2020-02-03'), extract(decade from date
'2021-10-07');
+++
| EXPR$0 | EXPR$1 |
+++
| 202| 202|
+++
{code}
>From the other side there are {{FLOOR}} and {{CEIL}} in Calcite. Frankly
>speaking I do not know the history how they appeared.
However the current documentation[1] says
{noformat}
| FLOOR(datetime TO timeUnit) | Rounds *datetime* down to *timeUnit*
| CEIL(datetime TO timeUnit) | Rounds *datetime* up to *timeUnit*
{noformat}
so it should be timeunit. And existing logic for {{YEAR}}, {{QUARTER}},
{{MONTH}} does rounding to the start of year, quarter, month.
[1]
https://github.com/apache/calcite/blob/50dbd12f14f330f57a321a2402a7dcb8124f5112/site/_docs/reference.md#L1353-L1354
> FLOOR and CEIL of DATE/TIMESTAMP return wrong results for DECADE, CENTURY and
> MILLENNIUM
>
>
> Key: CALCITE-4837
> URL: https://issues.apache.org/jira/browse/CALCITE-4837
> Project: Calcite
> Issue Type: Bug
> Components: avatica, core
>Reporter: Sergey Nuyanzin
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The query to reproduce
> {code:sql}
> select floor(t to decade) as floor_decade,
> ceil(t to decade) as ceil_decade,
> floor(t to century) as floor_century,
> ceil(t to century) as ceil_century,
> floor(t to millennium) as floor_millennium,
> ceil(t to millennium) as ceil_millennium
> from (values(date '2021-10-07')) t;
> {code}
> it produces output
> {noformat}
> +--+-+--+--+--+-+
> | FLOOR_DECADE | CEIL_DECADE | FLOOR_CENTURY | CEIL_CENTURY |
> FLOOR_MILLENNIUM | CEIL_MILLENNIUM |
> +--+-+--+--+--+-+
> | 2021-08-01 | 2021-11-29 | 2019-04-14 | 2022-07-27 | 2002-11-09
> | 2035-09-17 |
> +--+-+--+--+--+-+
> {noformat}
> expected
> {noformat}
> +--+-+--+--+--+-+
> | FLOOR_DECADE | CEIL_DECADE | FLOOR_CENTURY | CEIL_CENTURY |
> FLOOR_MILLENNIUM | CEIL_MILLENNIUM |
> +--+-+--+--+--+-+
> | 2020-01-01 | 2030-01-01 | 2000-01-01 | 2100-01-01 | 2000-01-01
> | 3000-01-01 |
> +--+-+--+--+--+-+
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Issue Comment Deleted] (CALCITE-4837) FLOOR and CEIL of DATE/TIMESTAMP return wrong results for DECADE, CENTURY and MILLENNIUM
[
https://issues.apache.org/jira/browse/CALCITE-4837?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alessandro Solimando updated CALCITE-4837:
--
Comment: was deleted
(was: We seem to differ for the "to *" semantics w.r.t. all the other DBs:
* [AWS
Redshift|https://docs.aws.amazon.com/redshift/latest/dg/r_Dateparts_for_datetime_functions.html]
*
[JOOQ|https://www.jooq.org/doc/3.1/manual/sql-building/column-expressions/datetime-functions/decade-function/]
(covering lots of DBs in the example)
For instance, "to decade" of "2020" is "202" for most DBs.
I agree with you for the floor/ceil behaviour, I am rather puzzled by the "to
*" semantics, do you have any example that behaves like we do or supporting
documentation?
I am just curious and it's not strictly related to the current ticket, but I
think it's worth understanding it better.)
> FLOOR and CEIL of DATE/TIMESTAMP return wrong results for DECADE, CENTURY and
> MILLENNIUM
>
>
> Key: CALCITE-4837
> URL: https://issues.apache.org/jira/browse/CALCITE-4837
> Project: Calcite
> Issue Type: Bug
> Components: avatica, core
>Reporter: Sergey Nuyanzin
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The query to reproduce
> {code:sql}
> select floor(t to decade) as floor_decade,
> ceil(t to decade) as ceil_decade,
> floor(t to century) as floor_century,
> ceil(t to century) as ceil_century,
> floor(t to millennium) as floor_millennium,
> ceil(t to millennium) as ceil_millennium
> from (values(date '2021-10-07')) t;
> {code}
> it produces output
> {noformat}
> +--+-+--+--+--+-+
> | FLOOR_DECADE | CEIL_DECADE | FLOOR_CENTURY | CEIL_CENTURY |
> FLOOR_MILLENNIUM | CEIL_MILLENNIUM |
> +--+-+--+--+--+-+
> | 2021-08-01 | 2021-11-29 | 2019-04-14 | 2022-07-27 | 2002-11-09
> | 2035-09-17 |
> +--+-+--+--+--+-+
> {noformat}
> expected
> {noformat}
> +--+-+--+--+--+-+
> | FLOOR_DECADE | CEIL_DECADE | FLOOR_CENTURY | CEIL_CENTURY |
> FLOOR_MILLENNIUM | CEIL_MILLENNIUM |
> +--+-+--+--+--+-+
> | 2020-01-01 | 2030-01-01 | 2000-01-01 | 2100-01-01 | 2000-01-01
> | 3000-01-01 |
> +--+-+--+--+--+-+
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-4837) FLOOR and CEIL of DATE/TIMESTAMP return wrong results for DECADE, CENTURY and MILLENNIUM
[
https://issues.apache.org/jira/browse/CALCITE-4837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17425633#comment-17425633
]
Alessandro Solimando commented on CALCITE-4837:
---
We seem to differ for the "to *" semantics w.r.t. all the other DBs:
* [AWS
Redshift|https://docs.aws.amazon.com/redshift/latest/dg/r_Dateparts_for_datetime_functions.html]
*
[JOOQ|https://www.jooq.org/doc/3.1/manual/sql-building/column-expressions/datetime-functions/decade-function/]
(covering lots of DBs in the example)
For instance, "to decade" of "2020" is "202" for most DBs.
I agree with you for the floor/ceil behaviour, I am rather puzzled by the "to
*" semantics, do you have any example that behaves like we do or supporting
documentation?
I am just curious and it's not strictly related to the current ticket, but I
think it's worth understanding it better.
> FLOOR and CEIL of DATE/TIMESTAMP return wrong results for DECADE, CENTURY and
> MILLENNIUM
>
>
> Key: CALCITE-4837
> URL: https://issues.apache.org/jira/browse/CALCITE-4837
> Project: Calcite
> Issue Type: Bug
> Components: avatica, core
>Reporter: Sergey Nuyanzin
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The query to reproduce
> {code:sql}
> select floor(t to decade) as floor_decade,
> ceil(t to decade) as ceil_decade,
> floor(t to century) as floor_century,
> ceil(t to century) as ceil_century,
> floor(t to millennium) as floor_millennium,
> ceil(t to millennium) as ceil_millennium
> from (values(date '2021-10-07')) t;
> {code}
> it produces output
> {noformat}
> +--+-+--+--+--+-+
> | FLOOR_DECADE | CEIL_DECADE | FLOOR_CENTURY | CEIL_CENTURY |
> FLOOR_MILLENNIUM | CEIL_MILLENNIUM |
> +--+-+--+--+--+-+
> | 2021-08-01 | 2021-11-29 | 2019-04-14 | 2022-07-27 | 2002-11-09
> | 2035-09-17 |
> +--+-+--+--+--+-+
> {noformat}
> expected
> {noformat}
> +--+-+--+--+--+-+
> | FLOOR_DECADE | CEIL_DECADE | FLOOR_CENTURY | CEIL_CENTURY |
> FLOOR_MILLENNIUM | CEIL_MILLENNIUM |
> +--+-+--+--+--+-+
> | 2020-01-01 | 2030-01-01 | 2000-01-01 | 2100-01-01 | 2000-01-01
> | 3000-01-01 |
> +--+-+--+--+--+-+
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-4837) FLOOR and CEIL of DATE/TIMESTAMP return wrong results for DECADE, CENTURY and MILLENNIUM
[
https://issues.apache.org/jira/browse/CALCITE-4837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17425628#comment-17425628
]
Alessandro Solimando commented on CALCITE-4837:
---
We seem to follow a different definition for "to decade"/"to millenium" w.r.t.
that of most other DBs:
* [Redshift
docs|https://docs.aws.amazon.com/redshift/latest/dg/r_Dateparts_for_datetime_functions.html]
* [JOOQ
docs|https://www.jooq.org/doc/3.1/manual/sql-building/column-expressions/datetime-functions/decade-function/]
(covering with examples most DBs)
For instance, "decade" of "2020" is "202" for almost everyone, except us.
Did you find other systems conforming to the expected behaviour you show in the
ticket?
I agree with you around floor/ceil behaviour, I am rather a bit puzzled by the
"to *" semantics, sorry if not strictly related to the ticket but I think it's
valuable clarification.
> FLOOR and CEIL of DATE/TIMESTAMP return wrong results for DECADE, CENTURY and
> MILLENNIUM
>
>
> Key: CALCITE-4837
> URL: https://issues.apache.org/jira/browse/CALCITE-4837
> Project: Calcite
> Issue Type: Bug
> Components: avatica, core
>Reporter: Sergey Nuyanzin
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The query to reproduce
> {code:sql}
> select floor(t to decade) as floor_decade,
> ceil(t to decade) as ceil_decade,
> floor(t to century) as floor_century,
> ceil(t to century) as ceil_century,
> floor(t to millennium) as floor_millennium,
> ceil(t to millennium) as ceil_millennium
> from (values(date '2021-10-07')) t;
> {code}
> it produces output
> {noformat}
> +--+-+--+--+--+-+
> | FLOOR_DECADE | CEIL_DECADE | FLOOR_CENTURY | CEIL_CENTURY |
> FLOOR_MILLENNIUM | CEIL_MILLENNIUM |
> +--+-+--+--+--+-+
> | 2021-08-01 | 2021-11-29 | 2019-04-14 | 2022-07-27 | 2002-11-09
> | 2035-09-17 |
> +--+-+--+--+--+-+
> {noformat}
> expected
> {noformat}
> +--+-+--+--+--+-+
> | FLOOR_DECADE | CEIL_DECADE | FLOOR_CENTURY | CEIL_CENTURY |
> FLOOR_MILLENNIUM | CEIL_MILLENNIUM |
> +--+-+--+--+--+-+
> | 2020-01-01 | 2030-01-01 | 2000-01-01 | 2100-01-01 | 2000-01-01
> | 3000-01-01 |
> +--+-+--+--+--+-+
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-4735) SubstitutionVisitor of Aggregate Failed, when aggcalls of query could be expressed by target's grouping
[
https://issues.apache.org/jira/browse/CALCITE-4735?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Xurenhe updated CALCITE-4735:
-
Description:
`SubstitutionVisitor` don't work for rewriting query by mv, let me show a
example of the current failure.
{code:java}
@Test void testAggCallArgExpressedByMvProjs2() {
final String mv = ""
+ "select \"deptno\""
+ "from \"emps\" group by \"deptno\"";
final String query = ""
+ "select \"deptno\", count(*)"
+ "from \"emps\" group by \"deptno\"";
sql(mv, query).ok();
}
{code}
I debug this issue, I found that: when `AggregateToAggregateUnifyRule`
executing `unifyAggregates`, code want to find agg-calls of query could be
equal or rollup by target's agg-calls.
Should we have other way to handle in `AggregateToAggregateUnifyRule` or
`AggregateOnCalcToAggregateUnifyRule`?
I will give some examples to explain the problem:
{code:sql}
-- schema
create table emps (
empid integer,
deptno integer,
name varchar,
salary float,
commission integer
)
{code}
AggregateToAggregateUnifyRule
case1: mv's group equal to query's group
{code:sql}
--mv
select deptno, commission
from emps
group by deptno, commission
--query
select deptno, commission, count(1), count(distinct commission)
from emps
group by deptno, commission
--rewrite
select deptno, commission, count(1), count(distinct commission)
from mv
group by deptno, commission
{code}
case2: mv's group rollup to query's group
{code:sql}
--mv
select deptno, commission
from emps
group by deptno, commission
--query
select deptno, max(commission)
from emps
group by deptno
--rewrite
select deptno, max(commission)
from mv
group by deptno
{code}
AggregateOnCalcToAggregateUnifyRule
case1: mv's group equal to query's group
{code:sql}
--mv
select deptno, commission, mix(salary)
from emps
group by deptno, commission
--query
select deptno, commission, count(1)
from emps
group by deptno, commission
--rewrite
select deptno, commission, count(1)
from mv
group by deptno, commission
{code}
case2: mv's group rollup to query's group
{code:sql}
--mv
select deptno, commission, name, mix(salary)
from emps
group by deptno, commission, name
--query
select deptno, commission, count(1), count(distinct name)
from emps
group by deptno, commission
--rewrite
select deptno, commission, count(1), count(distinct name)
from mv
group by deptno, commission
{code}
Here, Should we create new agg-calls to compensate missing agg-calls of query,
which is based on mv's agg-group?
Rewriting query's agg-call could be rewritten by equal agg-call of mv or
rollup agg-call of mv,
also could be {color:#FF}rewritten by emitted agg-group of mv{color}.
Please review this viewpoint, if this viewpoint is right, I can do it.
Thanks a lot.
was:
`SubstitutionVisitor` don't work for rewriting query by mv, let me show a
example of the current failure.
{code:java}
@Test void testAggCallArgExpressedByMvProjs() {
final String mv = ""
+ "select \"deptno\", \"name\""
+ "from \"emps\" group by \"deptno\", \"name\"";
final String query = ""
+ "select \"deptno\", \"name\", count(distinct \"name\")"
+ "from \"emps\" group by \"deptno\", \"name\"";
sql(mv, query).ok();
}
{code}
I debug this issue, I found that: when `AggregateToAggregateUnifyRule`
executing `unifyAggregates`, code want to find agg-calls of query could be
equal or rollup by target's agg-calls.
Should we have other way to handle in `AggregateToAggregateUnifyRule` or
`AggregateOnCalcToAggregateUnifyRule`?
I will give some examples to explain the problem:
{code:sql}
-- schema
create table emps (
empid integer,
deptno integer,
name varchar,
salary float,
commission integer
)
{code}
AggregateToAggregateUnifyRule
case1: mv's group equal to query's group
{code:sql}
--mv
select deptno, commission
from emps
group by deptno, commission
--query
select deptno, commission, count(1), count(distinct commission)
from emps
group by deptno, commission
--rewrite
select deptno, commission, count(1), count(distinct commission)
from mv
group by deptno, commission
{code}
case2: mv's group rollup to query's group
{code:sql}
--mv
select deptno, commission
from emps
group by deptno, commission
--query
select deptno, max(commission)
from emps
group by deptno
--rewrite
select deptno, max(commission)
from mv
group by deptno
{code}
AggregateOnCalcToAggregateUnifyRule
case1: mv's group equal to query's group
{code:sql}
--mv
select deptno, commission, mix(salary)
from emps
group by deptno, commission
--query
select deptno, commission, count(1)
from emps
group by deptno, commission
--rewrite
select deptno, commission, count(1)
from mv
group by deptno, commission
{code}
case2: mv's group rollup to query's group
{code:sql}
--mv
select deptno, commission, name, mix(salary)
from emps
group by deptno, commission, name
--query
select deptno, commission, co
[jira] [Commented] (CALCITE-4818) AggregateExpandDistinctAggregatesRule must infer correct data type for top aggregate calls
[
https://issues.apache.org/jira/browse/CALCITE-4818?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17425460#comment-17425460
]
Xurenhe commented on CALCITE-4818:
--
[~tledkov-gridgain] Sorry, it's my mistake. I try to code this test case, but I
forget to define a type system to write return's type of SUM. so, I meet some
error stack as above.
I thought it would affect the upper operator of project, if it exists. So, I
want more testes to cover, but there is no difference between the two test
cases.
I'm sorry to my carelessness.
> AggregateExpandDistinctAggregatesRule must infer correct data type for top
> aggregate calls
> --
>
> Key: CALCITE-4818
> URL: https://issues.apache.org/jira/browse/CALCITE-4818
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.27.0
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.28.0
>
>
> When SUM data type derivation is more complex, e.g.:
> {code}
> SUM(TINYINT | SMALLINT | INTEGER) -> BIGINT
> SUM(BIGINT) -> DECIMAL
> {code}
> The rule {{AggregateExpandDistinctAggregatesRule}} creates the top aggregate
> calls with invalid type for not distinct calls.
> e.g. {{SELECT SUM(comm), SUM(DISTINCT comm) FROM emp}}
> Please take a look at the reproducer in the PR.
> *Proposed fix:* infer type of top aggregates by input row type. Pass
> {{null}} type to the call method {{AggregateCall#create}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-4762) Upgrade Calcite to Avatica 1.19
[ https://issues.apache.org/jira/browse/CALCITE-4762?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17425444#comment-17425444 ] duan xiong commented on CALCITE-4762: - CALCITE-4626 upgrade the protobuf-java to 3.17.1 in Avatica. CALCITE-4836( [PR 2569|https://github.com/apache/calcite/pull/2569] ) needs to be merged after the upgrade which upgrades the protobuf-java to 3.17.1 in Calcite. > 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 >Priority: Major > > 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-4836) Upgrade protobuf-java 3.6.1 -> 3.17.1
[ https://issues.apache.org/jira/browse/CALCITE-4836?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] duan xiong updated CALCITE-4836: Labels: pull-request-available (was: ) > Upgrade protobuf-java 3.6.1 -> 3.17.1 > - > > Key: CALCITE-4836 > URL: https://issues.apache.org/jira/browse/CALCITE-4836 > Project: Calcite > Issue Type: Bug >Affects Versions: 1.27.0 >Reporter: duan xiong >Assignee: duan xiong >Priority: Major > Labels: pull-request-available > Fix For: 1.28.0 > > > As CALCITE-4626 upgrade the protobuf-java to 3.17.1 to resolve the compile > warning. In order to keep the same version as it, upgrade this version in > CALCITE too. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CALCITE-4837) FLOOR and CEIL of DATE/TIMESTAMP return wrong results for DECADE, CENTURY and MILLENNIUM
[
https://issues.apache.org/jira/browse/CALCITE-4837?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Nuyanzin updated CALCITE-4837:
-
Description:
The query to reproduce
{code:sql}
select floor(t to decade) as floor_decade,
ceil(t to decade) as ceil_decade,
floor(t to century) as floor_century,
ceil(t to century) as ceil_century,
floor(t to millennium) as floor_millennium,
ceil(t to millennium) as ceil_millennium
from (values(date '2021-10-07')) t;
{code}
it produces output
{noformat}
+--+-+--+--+--+-+
| FLOOR_DECADE | CEIL_DECADE | FLOOR_CENTURY | CEIL_CENTURY | FLOOR_MILLENNIUM
| CEIL_MILLENNIUM |
+--+-+--+--+--+-+
| 2021-08-01 | 2021-11-29 | 2019-04-14 | 2022-07-27 | 2002-11-09 |
2035-09-17 |
+--+-+--+--+--+-+
{noformat}
expected
{noformat}
+--+-+--+--+--+-+
| FLOOR_DECADE | CEIL_DECADE | FLOOR_CENTURY | CEIL_CENTURY | FLOOR_MILLENNIUM
| CEIL_MILLENNIUM |
+--+-+--+--+--+-+
| 2020-01-01 | 2030-01-01 | 2000-01-01 | 2100-01-01 | 2000-01-01 |
3000-01-01 |
+--+-+--+--+--+-+
{noformat}
was:
The query to reproduce
{code:sql}
select floor(t to decade) as floor_decade,
ceil(t to decade) as ceil_decade,
floor(t to century) as floor_century,
ceil(t to century) as ceil_century,
floor(t to millennium) as floor_millennium,
ceil(t to millennium) as ceil_millennium
from (values(date '2021-10-07'), (timestamp '2021-10-07 10:27:35')) t;
{code}
it produces output
{noformat}
+--+-+--+--+--+-+
| FLOOR_DECADE | CEIL_DECADE | FLOOR_CENTURY | CEIL_CENTURY | FLOOR_MILLENNIUM
| CEIL_MILLENNIUM |
+--+-+--+--+--+-+
| 2021-08-01 | 2021-11-29 | 2019-04-14 | 2022-07-27 | 2002-11-09 |
2035-09-17 |
+--+-+--+--+--+-+
{noformat}
expected
{noformat}
+--+-+--+--+--+-+
| FLOOR_DECADE | CEIL_DECADE | FLOOR_CENTURY | CEIL_CENTURY | FLOOR_MILLENNIUM
| CEIL_MILLENNIUM |
+--+-+--+--+--+-+
| 2020-01-01 | 2030-01-01 | 2000-01-01 | 2100-01-01 | 2000-01-01 |
3000-01-01 |
+--+-+--+--+--+-+
{noformat}
> FLOOR and CEIL of DATE/TIMESTAMP return wrong results for DECADE, CENTURY and
> MILLENNIUM
>
>
> Key: CALCITE-4837
> URL: https://issues.apache.org/jira/browse/CALCITE-4837
> Project: Calcite
> Issue Type: Bug
> Components: avatica, core
>Reporter: Sergey Nuyanzin
>Priority: Major
>
> The query to reproduce
> {code:sql}
> select floor(t to decade) as floor_decade,
> ceil(t to decade) as ceil_decade,
> floor(t to century) as floor_century,
> ceil(t to century) as ceil_century,
> floor(t to millennium) as floor_millennium,
> ceil(t to millennium) as ceil_millennium
> from (values(date '2021-10-07')) t;
> {code}
> it produces output
> {noformat}
> +--+-+--+--+--+-+
> | FLOOR_DECADE | CEIL_DECADE | FLOOR_CENTURY | CEIL_CENTURY |
> FLOOR_MILLENNIUM | CEIL_MILLENNIUM |
> +--+-+--+--+--+-+
> | 2021-08-01 | 2021-11-29 | 2019-04-14 | 2022-07-27 | 2002-11-09
> | 2035-09-17 |
> +--+-+--+--+--+-+
> {noformat}
> expected
> {noformat}
> +--+-+--+--+--+-+
> | FLOOR_DECADE | CEIL_DECADE | FLOOR_CENTURY | CEIL_CENTURY |
> FLOOR_MILLENNIUM | CEIL_MILLENNIUM |
> +--+-+--+--+--+-+
> | 2020-01-01 | 2030-01-01 | 2000-01-01 | 2100-01-01 | 2000-01-01
> | 3000-01-01 |
> +--+-+--+-
[jira] [Created] (CALCITE-4837) FLOOR and CEIL of DATE/TIMESTAMP return wrong results for DECADE, CENTURY and MILLENNIUM
Sergey Nuyanzin created CALCITE-4837:
Summary: FLOOR and CEIL of DATE/TIMESTAMP return wrong results for
DECADE, CENTURY and MILLENNIUM
Key: CALCITE-4837
URL: https://issues.apache.org/jira/browse/CALCITE-4837
Project: Calcite
Issue Type: Bug
Components: avatica, core
Reporter: Sergey Nuyanzin
The query to reproduce
{code:sql}
select floor(t to decade) as floor_decade,
ceil(t to decade) as ceil_decade,
floor(t to century) as floor_century,
ceil(t to century) as ceil_century,
floor(t to millennium) as floor_millennium,
ceil(t to millennium) as ceil_millennium
from (values(date '2021-10-07'), (timestamp '2021-10-07 10:27:35')) t;
{code}
it produces output
{noformat}
+--+-+--+--+--+-+
| FLOOR_DECADE | CEIL_DECADE | FLOOR_CENTURY | CEIL_CENTURY | FLOOR_MILLENNIUM
| CEIL_MILLENNIUM |
+--+-+--+--+--+-+
| 2021-08-01 | 2021-11-29 | 2019-04-14 | 2022-07-27 | 2002-11-09 |
2035-09-17 |
+--+-+--+--+--+-+
{noformat}
expected
{noformat}
+--+-+--+--+--+-+
| FLOOR_DECADE | CEIL_DECADE | FLOOR_CENTURY | CEIL_CENTURY | FLOOR_MILLENNIUM
| CEIL_MILLENNIUM |
+--+-+--+--+--+-+
| 2020-01-01 | 2030-01-01 | 2000-01-01 | 2100-01-01 | 2000-01-01 |
3000-01-01 |
+--+-+--+--+--+-+
{noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-4818) AggregateExpandDistinctAggregatesRule must infer correct data type for top aggregate calls
[
https://issues.apache.org/jira/browse/CALCITE-4818?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17425397#comment-17425397
]
Taras Ledkov commented on CALCITE-4818:
---
[~wojustme], thanks for review and propose the test case.
Please clarify what do you mean:
- replace SQL from {{SELECT SUM(comm), SUM(DISTINCT comm) FROM emp}} to
proposed {{SELECT s1+1 AS new_s1, s2+1 AS new_s2 FROM (SELECT SUM(comm) AS s1,
SUM(DISTINCT comm) AS s2 FROM emp)}} at the added test
- add new test.
What the key difference do you see between
{{SELECT SUM(comm), SUM(DISTINCT comm) FROM emp}}
and
{{SELECT s1+1 AS new_s1, s2+1 AS new_s2 FROM (SELECT SUM(comm) AS s1,
SUM(DISTINCT comm) AS s2 FROM emp)}}
for the issue at the {{AggregateExpandDistinctAggregatesRule}}?
> AggregateExpandDistinctAggregatesRule must infer correct data type for top
> aggregate calls
> --
>
> Key: CALCITE-4818
> URL: https://issues.apache.org/jira/browse/CALCITE-4818
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.27.0
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.28.0
>
>
> When SUM data type derivation is more complex, e.g.:
> {code}
> SUM(TINYINT | SMALLINT | INTEGER) -> BIGINT
> SUM(BIGINT) -> DECIMAL
> {code}
> The rule {{AggregateExpandDistinctAggregatesRule}} creates the top aggregate
> calls with invalid type for not distinct calls.
> e.g. {{SELECT SUM(comm), SUM(DISTINCT comm) FROM emp}}
> Please take a look at the reproducer in the PR.
> *Proposed fix:* infer type of top aggregates by input row type. Pass
> {{null}} type to the call method {{AggregateCall#create}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-4777) Casting from DECIMAL to BOOLEAN throws an exception
[
https://issues.apache.org/jira/browse/CALCITE-4777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17425381#comment-17425381
]
Alessandro Solimando commented on CALCITE-4777:
---
This is my understanding too [~rubenql]
> Casting from DECIMAL to BOOLEAN throws an exception
> ---
>
> Key: CALCITE-4777
> URL: https://issues.apache.org/jira/browse/CALCITE-4777
> Project: Calcite
> Issue Type: Bug
>Reporter: xuyangzhong
>Assignee: xuyangzhong
>Priority: Major
> Labels: pull-request-available
> Attachments: calcite.png
>
> Time Spent: 2h 10m
> Remaining Estimate: 0h
>
> My sql is the following:
> {code:java}
> // code placeholder
> select * from test where cast (0.10915913549909961 as boolean){code}
>
> I want to simplify the cast. An exception is thrown:
>
> {code:java}
> // code placeholder
> Exception in thread "main" java.lang.RuntimeException: while resolving method
> 'booleanValue' in class class java.math.BigDecimal at
> org.apache.calcite.linq4j.tree.Expressions.call(Expressions.java:424) at
> org.apache.calcite.linq4j.tree.Expressions.call(Expressions.java:435) at
> org.apache.calcite.linq4j.tree.Expressions.unbox(Expressions.java:1453) at
> org.apache.calcite.adapter.enumerable.EnumUtils.convert(EnumUtils.java:398)
> at
> org.apache.calcite.adapter.enumerable.EnumUtils.convert(EnumUtils.java:326)
> at
> org.apache.calcite.adapter.enumerable.RexToLixTranslator.translateCast(RexToLixTranslator.java:543)
> at
> org.apache.calcite.adapter.enumerable.RexImpTable$CastImplementor.implementSafe(RexImpTable.java:2450)
> at
> org.apache.calcite.adapter.enumerable.RexImpTable$AbstractRexCallImplementor.genValueStatement(RexImpTable.java:2894)
> at
> org.apache.calcite.adapter.enumerable.RexImpTable$AbstractRexCallImplementor.implement(RexImpTable.java:2859)
> at
> org.apache.calcite.adapter.enumerable.RexToLixTranslator.visitCall(RexToLixTranslator.java:1089)
> at
> org.apache.calcite.adapter.enumerable.RexToLixTranslator.visitCall(RexToLixTranslator.java:90)
> at org.apache.calcite.rex.RexCall.accept(RexCall.java:174) at
> org.apache.calcite.adapter.enumerable.RexToLixTranslator.visitLocalRef(RexToLixTranslator.java:975)
> at
> org.apache.calcite.adapter.enumerable.RexToLixTranslator.visitLocalRef(RexToLixTranslator.java:90)
> at org.apache.calcite.rex.RexLocalRef.accept(RexLocalRef.java:75) at
> org.apache.calcite.adapter.enumerable.RexToLixTranslator.translate(RexToLixTranslator.java:237)
> at
> org.apache.calcite.adapter.enumerable.RexToLixTranslator.translate(RexToLixTranslator.java:231)
> at
> org.apache.calcite.adapter.enumerable.RexToLixTranslator.translateList(RexToLixTranslator.java:823)
> at
> org.apache.calcite.adapter.enumerable.RexToLixTranslator.translateProjects(RexToLixTranslator.java:198)
> at org.apache.calcite.rex.RexExecutorImpl.compile(RexExecutorImpl.java:90)
> at org.apache.calcite.rex.RexExecutorImpl.compile(RexExecutorImpl.java:66) at
> org.apache.calcite.rex.RexExecutorImpl.reduce(RexExecutorImpl.java:128) at
> org.apache.calcite.rex.RexSimplify.simplifyCast(RexSimplify.java:2101) at
> org.apache.calcite.rex.RexSimplify.simplify(RexSimplify.java:326) at
> org.apache.calcite.rex.RexSimplify.simplifyUnknownAs(RexSimplify.java:287) at
> org.apache.flink.table.examples.java.tests.CalciteTest.main(CalciteTest.java:47)
> Caused by: java.lang.NoSuchMethodException:
> java.math.BigDecimal.booleanValue() at
> java.lang.Class.getMethod(Class.java:1786) at
> org.apache.calcite.linq4j.tree.Expressions.call(Expressions.java:421) ... 25
> more
> {code}
> In order to avoid that I used the wrong rule or it caused by my bad coding, i
> write the test case following:
>
> {code:java}
> // code placeholder
> JavaTypeFactory typeFactory = new
> JavaTypeFactoryImpl(RelDataTypeSystem.DEFAULT);
> RexBuilder rexBuilder = new RexBuilder(typeFactory);
> final RexSimplify simplify = new RexSimplify(rexBuilder,
> RelOptPredicateList.EMPTY, RexUtil.EXECUTOR);
> RelDataType type = new BasicSqlType(typeFactory.getTypeSystem(),
> SqlTypeName.BOOLEAN);
> RelDataType bb = new
> BasicSqlType(typeFactory.getTypeSystem(),SqlTypeName.DECIMAL,18,17);
> SqlOperator op = new SqlCastFunction();
> RexLiteral lt =
> rexBuilder.makeExactLiteral(BigDecimal.valueOf(0.10915913549909961),bb);
> List list = new ArrayList<>();
> list.add(lt);
> RexNode rexNode = rexBuilder.makeCall(type,op,list);
> simplify.simplifyUnknownAs(rexNode, RexUnknownAs.UNKNOWN);
> {code}
> and it throws the same exception.
>
> Actually, the cast simplify operation will enter the function _translateCast_
> in _RexToLixTranslator_.It misses the "case BOOLEAN" and uses the convert in
> EnumUtils. However, because the Decimal's Primitive is null a
[jira] [Commented] (CALCITE-4777) Casting from DECIMAL to BOOLEAN throws an exception
[
https://issues.apache.org/jira/browse/CALCITE-4777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17425375#comment-17425375
]
Ruben Q L commented on CALCITE-4777:
Just to confirm and to avoid any confusion, with the proposed PR:
- Casting decimal (and float, real, double) into boolean will be forbidden (it
will fail with an appropriate error message, and casting compatibility matrix
in the site will be updated).
- Casting integer types into boolean is (and will continue being) allowed. A
different issue is that currently casting integers into boolean always returns
false (instead of zero->false; non-zero->true), but there is another ticket to
deal with this problem: CALCITE-4782.
Do we all agree this is the intended behavior that we want to set?
> Casting from DECIMAL to BOOLEAN throws an exception
> ---
>
> Key: CALCITE-4777
> URL: https://issues.apache.org/jira/browse/CALCITE-4777
> Project: Calcite
> Issue Type: Bug
>Reporter: xuyangzhong
>Assignee: xuyangzhong
>Priority: Major
> Labels: pull-request-available
> Attachments: calcite.png
>
> Time Spent: 2h 10m
> Remaining Estimate: 0h
>
> My sql is the following:
> {code:java}
> // code placeholder
> select * from test where cast (0.10915913549909961 as boolean){code}
>
> I want to simplify the cast. An exception is thrown:
>
> {code:java}
> // code placeholder
> Exception in thread "main" java.lang.RuntimeException: while resolving method
> 'booleanValue' in class class java.math.BigDecimal at
> org.apache.calcite.linq4j.tree.Expressions.call(Expressions.java:424) at
> org.apache.calcite.linq4j.tree.Expressions.call(Expressions.java:435) at
> org.apache.calcite.linq4j.tree.Expressions.unbox(Expressions.java:1453) at
> org.apache.calcite.adapter.enumerable.EnumUtils.convert(EnumUtils.java:398)
> at
> org.apache.calcite.adapter.enumerable.EnumUtils.convert(EnumUtils.java:326)
> at
> org.apache.calcite.adapter.enumerable.RexToLixTranslator.translateCast(RexToLixTranslator.java:543)
> at
> org.apache.calcite.adapter.enumerable.RexImpTable$CastImplementor.implementSafe(RexImpTable.java:2450)
> at
> org.apache.calcite.adapter.enumerable.RexImpTable$AbstractRexCallImplementor.genValueStatement(RexImpTable.java:2894)
> at
> org.apache.calcite.adapter.enumerable.RexImpTable$AbstractRexCallImplementor.implement(RexImpTable.java:2859)
> at
> org.apache.calcite.adapter.enumerable.RexToLixTranslator.visitCall(RexToLixTranslator.java:1089)
> at
> org.apache.calcite.adapter.enumerable.RexToLixTranslator.visitCall(RexToLixTranslator.java:90)
> at org.apache.calcite.rex.RexCall.accept(RexCall.java:174) at
> org.apache.calcite.adapter.enumerable.RexToLixTranslator.visitLocalRef(RexToLixTranslator.java:975)
> at
> org.apache.calcite.adapter.enumerable.RexToLixTranslator.visitLocalRef(RexToLixTranslator.java:90)
> at org.apache.calcite.rex.RexLocalRef.accept(RexLocalRef.java:75) at
> org.apache.calcite.adapter.enumerable.RexToLixTranslator.translate(RexToLixTranslator.java:237)
> at
> org.apache.calcite.adapter.enumerable.RexToLixTranslator.translate(RexToLixTranslator.java:231)
> at
> org.apache.calcite.adapter.enumerable.RexToLixTranslator.translateList(RexToLixTranslator.java:823)
> at
> org.apache.calcite.adapter.enumerable.RexToLixTranslator.translateProjects(RexToLixTranslator.java:198)
> at org.apache.calcite.rex.RexExecutorImpl.compile(RexExecutorImpl.java:90)
> at org.apache.calcite.rex.RexExecutorImpl.compile(RexExecutorImpl.java:66) at
> org.apache.calcite.rex.RexExecutorImpl.reduce(RexExecutorImpl.java:128) at
> org.apache.calcite.rex.RexSimplify.simplifyCast(RexSimplify.java:2101) at
> org.apache.calcite.rex.RexSimplify.simplify(RexSimplify.java:326) at
> org.apache.calcite.rex.RexSimplify.simplifyUnknownAs(RexSimplify.java:287) at
> org.apache.flink.table.examples.java.tests.CalciteTest.main(CalciteTest.java:47)
> Caused by: java.lang.NoSuchMethodException:
> java.math.BigDecimal.booleanValue() at
> java.lang.Class.getMethod(Class.java:1786) at
> org.apache.calcite.linq4j.tree.Expressions.call(Expressions.java:421) ... 25
> more
> {code}
> In order to avoid that I used the wrong rule or it caused by my bad coding, i
> write the test case following:
>
> {code:java}
> // code placeholder
> JavaTypeFactory typeFactory = new
> JavaTypeFactoryImpl(RelDataTypeSystem.DEFAULT);
> RexBuilder rexBuilder = new RexBuilder(typeFactory);
> final RexSimplify simplify = new RexSimplify(rexBuilder,
> RelOptPredicateList.EMPTY, RexUtil.EXECUTOR);
> RelDataType type = new BasicSqlType(typeFactory.getTypeSystem(),
> SqlTypeName.BOOLEAN);
> RelDataType bb = new
> BasicSqlType(typeFactory.getTypeSystem(),SqlTypeName.DECIMAL,18,17);
> SqlOperator op = new SqlCastFunctio
