[jira] [Created] (CALCITE-6421) Calcite Avatica support JDK 22
Sergey Nuyanzin created CALCITE-6421: Summary: Calcite Avatica support JDK 22 Key: CALCITE-6421 URL: https://issues.apache.org/jira/browse/CALCITE-6421 Project: Calcite Issue Type: Bug Components: avatica Reporter: Sergey Nuyanzin Assignee: Sergey Nuyanzin -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CALCITE-6393) Byte code of SqlFunctions is invalid
Sergey Nuyanzin created CALCITE-6393:
Summary: Byte code of SqlFunctions is invalid
Key: CALCITE-6393
URL: https://issues.apache.org/jira/browse/CALCITE-6393
Project: Calcite
Issue Type: Bug
Reporter: Sergey Nuyanzin
The issue is a result of testing of Apache Calcite 1.37.0 rc 4 in this thread
[1]
There is test project andprocedure provided by [~MasseGuillaume]
it shows that since Calcite 1.36.0 it starts failing as
{noformat}
java.lang.ArrayIndexOutOfBoundsException: Index 65536 out of bounds for
length 297
at org.objectweb.asm.ClassReader.readLabel(ClassReader.java:2695)
at org.objectweb.asm.ClassReader.createLabel(ClassReader.java:2711)
at
org.objectweb.asm.ClassReader.readTypeAnnotations(ClassReader.java:2777)
at org.objectweb.asm.ClassReader.readCode(ClassReader.java:1929)
at org.objectweb.asm.ClassReader.readMethod(ClassReader.java:1515)
at org.objectweb.asm.ClassReader.accept(ClassReader.java:745)
{noformat}
Also since Calcite 1.27.0 it starts failing as
{noformat}
java.lang.IllegalArgumentException: Invalid end label (must be visited
first)
at
org.objectweb.asm.util.CheckMethodAdapter.checkLabel(CheckMethodAdapter.java:1453)
at
org.objectweb.asm.util.CheckMethodAdapter.visitLocalVariableAnnotation(CheckMethodAdapter.java:996)
at
org.objectweb.asm.MethodVisitor.visitLocalVariableAnnotation(MethodVisitor.java:757)
at
org.objectweb.asm.commons.MethodRemapper.visitLocalVariableAnnotation(MethodRemapper.java:257)
at org.objectweb.asm.ClassReader.readCode(ClassReader.java:2614)
at org.objectweb.asm.ClassReader.readMethod(ClassReader.java:1515)
{noformat}
[1] https://lists.apache.org/thread/n6cs1l86mt6fc5q8pcxr97czs3p6w65f
[2] https://github.com/MasseGuillaume/asm-remapper-bug
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CALCITE-6390) ArrowAdapterTest fails on Windows 11
Sergey Nuyanzin created CALCITE-6390:
Summary: ArrowAdapterTest fails on Windows 11
Key: CALCITE-6390
URL: https://issues.apache.org/jira/browse/CALCITE-6390
Project: Calcite
Issue Type: Bug
Reporter: Sergey Nuyanzin
That's seems somehow highlights the difference between Windows Server and non
Server
we have tests against Windows Server on gha (windows-latest) and they are green
At the same time local tests on Windows 11 show that {{ArrowAdapterTest}} fails
like
{noformat}
FAILURE 0.0sec, org.apache.calcite.adapter.arrow.ArrowAdapterTest >
executionError
java.io.IOException: Failed to delete temp directory
D:\MyConfiguration\cancai.cai\AppData\Local\Temp\junit5105379620525559011. The
following paths could not be deleted (see suppressed exceptions for details): ,
arrow
at
org.junit.jupiter.engine.extension.TempDirectory$CloseablePath.createIOExceptionWithAttachedFailures(TempDirectory.java:350)
at
org.junit.jupiter.engine.extension.TempDirectory$CloseablePath.close(TempDirectory.java:251)
at
org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
at
org.junit.jupiter.engine.execution.ExtensionValuesStore.lambda$closeAllStoredCloseableValues$3(ExtensionValuesStore.java:68)
at
java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:184)
at
java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
at java.util.ArrayList.forEach(ArrayList.java:1259)
at java.util.stream.SortedOps$RefSortingSink.end(SortedOps.java:390)
at java.util.stream.Sink$ChainedReference.end(Sink.java:258)
at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:483)
at
java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:472)
at
java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:151)
at
java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:174)
at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
at
java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:418)
at
org.junit.jupiter.engine.execution.ExtensionValuesStore.closeAllStoredCloseableValues(ExtensionValuesStore.java:68)
at
org.junit.jupiter.engine.descriptor.AbstractExtensionContext.close(AbstractExtensionContext.java:80)
at
org.junit.jupiter.engine.execution.JupiterEngineExecutionContext.close(JupiterEngineExecutionContext.java:53)
at
org.junit.jupiter.engine.descriptor.JupiterTestDescriptor.cleanUp(JupiterTestDescriptor.java:222)
at
org.junit.jupiter.engine.descriptor.JupiterTestDescriptor.cleanUp(JupiterTestDescriptor.java:57)
at
org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$cleanUp$10(NodeTestTask.java:167)
at
org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
at
org.junit.platform.engine.support.hierarchical.NodeTestTask.cleanUp(NodeTestTask.java:167)
at
org.junit.platform.engine.support.hierarchical.NodeTestTask.execute(NodeTestTask.java:98)
at
org.junit.platform.engine.support.hierarchical.ForkJoinPoolHierarchicalTestExecutorService$ExclusiveTask.compute(ForkJoinPoolHierarchicalTestExecutorService.java:185)
at
org.junit.platform.engine.support.hierarchical.ForkJoinPoolHierarchicalTestExecutorService.invokeAll(ForkJoinPoolHierarchicalTestExecutorService.java:129)
at
org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$6(NodeTestTask.java:155)
at
org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
at
org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$8(NodeTestTask.java:141)
at
org.junit.platform.engine.support.hierarchical.Node.around(Node.java:137)
at
org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$9(NodeTestTask.java:139)
at
org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
at
org.junit.platform.engine.support.hierarchical.NodeTestTask.executeRecursively(NodeTestTask.java:138)
at
org.junit.platform.engine.support.hierarchical.NodeTestTask.execute(NodeTestTask.java:95)
Suppressed: java.nio.file.DirectoryNotEmptyException:
D:\MyConfiguration\cancai.cai\AppData\Local\Temp\junit5105379620525559011
{noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CALCITE-6387) Calcite build while compiliation with jdk11+
Sergey Nuyanzin created CALCITE-6387:
Summary: Calcite build while compiliation with jdk11+
Key: CALCITE-6387
URL: https://issues.apache.org/jira/browse/CALCITE-6387
Project: Calcite
Issue Type: Bug
Affects Versions: 1.36.0
Reporter: Sergey Nuyanzin
The issue appears with newly added Arrow adapter which requires
{noformat}
--add-opens=java.base/java.nio=ALL-UNNAMED
{noformat}
could be fixed with adding
{noformat}
plugins.withType {
tasks {
configureEach {
jvmArgs("-XX:+IgnoreUnrecognizedVMOptions")
jvmArgs("--add-opens=java.base/java.nio=ALL-UNNAMED")
}
}
}
{noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CALCITE-6378) Since docker 26.x pushing and pulling with image manifest v2 schema 1 is disabled by default
Sergey Nuyanzin created CALCITE-6378:
Summary: Since docker 26.x pushing and pulling with image manifest
v2 schema 1 is disabled by default
Key: CALCITE-6378
URL: https://issues.apache.org/jira/browse/CALCITE-6378
Project: Calcite
Issue Type: Bug
Reporter: Sergey Nuyanzin
the source [1] also tells that it is going to be removed.
In Calcite it comes together with redis adapter which uses pretty old redis
docker image (2.8.19)
{noformat}
./gradlew clean build
{noformat}
is enough to reproduce (assuming there is docker 26+)
The fix is pretty straightforward: bumping docker image to e.g. 7.2.4 helps
[1]
https://docs.docker.com/engine/deprecated/#pushing-and-pulling-with-image-manifest-v2-schema-1
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CALCITE-6356) Upgrade Calcite to Avatica 1.25.0
Sergey Nuyanzin created CALCITE-6356:
Summary: Upgrade Calcite to Avatica 1.25.0
Key: CALCITE-6356
URL: https://issues.apache.org/jira/browse/CALCITE-6356
Project: Calcite
Issue Type: Improvement
Components: core
Reporter: Sergey Nuyanzin
Upgrade Calcite to Avatica 1.25.0
Also, as mentioned in comments for CALCITE-6053
{quote}
When the upgrade happens there are going to be some test failures in
SqlOperatorTest (CALCITE-5923) highlighting the part of the code that needs to
be updated. We left some comments to aid the cleanup.
{quote}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CALCITE-6302) Release Calcite 1.37.0
Sergey Nuyanzin created CALCITE-6302: Summary: Release Calcite 1.37.0 Key: CALCITE-6302 URL: https://issues.apache.org/jira/browse/CALCITE-6302 Project: Calcite Issue Type: Task Reporter: Sergey Nuyanzin Assignee: Sergey Nuyanzin Releasing Calcite 1.37.0 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CALCITE-6174) Upgrade gradle to 8.5
Sergey Nuyanzin created CALCITE-6174: Summary: Upgrade gradle to 8.5 Key: CALCITE-6174 URL: https://issues.apache.org/jira/browse/CALCITE-6174 Project: Calcite Issue Type: Sub-task Reporter: Sergey Nuyanzin Gradle 8.5 is the first fully supporting java 21 gradle based on docs -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CALCITE-6173) Support java 21
Sergey Nuyanzin created CALCITE-6173: Summary: Support java 21 Key: CALCITE-6173 URL: https://issues.apache.org/jira/browse/CALCITE-6173 Project: Calcite Issue Type: Improvement Reporter: Sergey Nuyanzin In case of Calcite it is a tricky task because of gradle upgrade from one side which also depends on kotlin and because of plenty of deprecations from another side for that reason I use this task as an umbrella -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CALCITE-6141) Add a dedicated gradle property for the checkstyle version to be used with jdk8
Sergey Nuyanzin created CALCITE-6141: Summary: Add a dedicated gradle property for the checkstyle version to be used with jdk8 Key: CALCITE-6141 URL: https://issues.apache.org/jira/browse/CALCITE-6141 Project: Calcite Issue Type: Improvement Components: avatica Affects Versions: avatica-1.23.0 Reporter: Sergey Nuyanzin Assignee: Sergey Nuyanzin The issue is that in case of jdk8 in order to compile it with jdk8 there should be specified checkstyle version. Since current java version could be detected during compilation it could also detect which checkstyle version should be used. This issue was also mentioned in ML https://lists.apache.org/thread/r27kdvvhr0222nqlog7xzn5y3yjvz6jp -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CALCITE-6137) Upgrade gradle to 8.4
Sergey Nuyanzin created CALCITE-6137: Summary: Upgrade gradle to 8.4 Key: CALCITE-6137 URL: https://issues.apache.org/jira/browse/CALCITE-6137 Project: Calcite Issue Type: Bug Components: avatica Reporter: Sergey Nuyanzin Gradle 8.4 is available and it supports java 21 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CALCITE-5748) Support Guava 32.0.0-jre
Sergey Nuyanzin created CALCITE-5748:
Summary: Support Guava 32.0.0-jre
Key: CALCITE-5748
URL: https://issues.apache.org/jira/browse/CALCITE-5748
Project: Calcite
Issue Type: Bug
Reporter: Sergey Nuyanzin
There is guava 32.0.0 available.
Besides version change there are a couple of issues:
1. Some methods start failing on {{CheckReturnValue}}
2. RedisTests start failing with NPE on Windows
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CALCITE-5613) Add assert for number of args for metadata methods at CacheGeneratorUtil
Sergey Nuyanzin created CALCITE-5613:
Summary: Add assert for number of args for metadata methods at
CacheGeneratorUtil
Key: CALCITE-5613
URL: https://issues.apache.org/jira/browse/CALCITE-5613
Project: Calcite
Issue Type: Improvement
Components: core
Affects Versions: 1.34.0
Reporter: Sergey Nuyanzin
The problem is that it implicitly implies that method should have 2+ args based
on
{{org.apache.calcite.rel.metadata.janino.CacheGeneratorUtil.CacheKeyStrategy#safeArgList}}.
At the same time different libs like JaCoCo could generate extra methods like
{{private static boolean[]
org.apache.calcite.rel.metadata.BuiltInMetadata$Predicates$Handler.$jacocoInit()}}.
It took several hours to realize it since currently it complains like
{noformat}
java.lang.IllegalArgumentException: fromIndex(2) > toIndex(0)
at
java.base/java.util.AbstractList.subListRangeCheck(AbstractList.java:509)
at java.base/java.util.AbstractList.subList(AbstractList.java:497)
at
org.apache.calcite.rel.metadata.janino.CacheGeneratorUtil$CacheKeyStrategy$1.safeArgList(CacheGeneratorUtil.java:213)
at
org.apache.calcite.rel.metadata.janino.CacheGeneratorUtil$CacheKeyStrategy$1.cacheKeyBlock(CacheGeneratorUtil.java:205)
...
{noformat}
The idea is to put assert something like that
{code:java}
assert method.getParameterCount() >= 2 : method.toString();
{code}
to simplify the process of finding the root cause
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CALCITE-5611) Show SQL query for failed tests for SqlOperatorTest
Sergey Nuyanzin created CALCITE-5611:
Summary: Show SQL query for failed tests for SqlOperatorTest
Key: CALCITE-5611
URL: https://issues.apache.org/jira/browse/CALCITE-5611
Project: Calcite
Issue Type: Improvement
Components: tests
Affects Versions: 1.34.0
Reporter: Sergey Nuyanzin
The issue is that there are lots of cases under each test in
{{SqlOperatorTest}} and it is not clear which of them is failing.
The idea is to print sql query from the test if it's failed besides type/result
comparison
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CALCITE-5570) Support nested map type for SqlDataTypeSpec
Sergey Nuyanzin created CALCITE-5570:
Summary: Support nested map type for SqlDataTypeSpec
Key: CALCITE-5570
URL: https://issues.apache.org/jira/browse/CALCITE-5570
Project: Calcite
Issue Type: Improvement
Components: core
Reporter: Sergey Nuyanzin
There was added a similar support for arrays/multisets at
https://issues.apache.org/jira/browse/CALCITE-3250
however there is no support for maps so far.
The issue is to add such support.
I think I'd like to clarify is syntax for maps since it has 2 internal subtypes
for keys and values may be something similar to ROW with delimiter like
{code:sql}
SELECT CAST(NULL AS MAP(INT, INT));
-- or with square brackets similar to map constructor
SELECT CAST(NULL AS MAP[INT, INT]);
-- or with angle (Flink syntax)
SELECT CAST(NULL AS MAP);
{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CALCITE-5491) Cannot apply 'TIMESTAMPDIFF' to arguments of type 'TIMESTAMPDIFF
Sergey Nuyanzin created CALCITE-5491:
Summary: Cannot apply 'TIMESTAMPDIFF' to arguments of type
'TIMESTAMPDIFF
Key: CALCITE-5491
URL: https://issues.apache.org/jira/browse/CALCITE-5491
Project: Calcite
Issue Type: Bug
Components: core
Affects Versions: 1.33.0
Reporter: Sergey Nuyanzin
Set to blocker since it is a regression (same queries work on 1.32.0)
Several queries with {{TIMESTAMPDIFF}} started to fail like
{noformat}
org.apache.calcite.runtime.CalciteContextException: From line 1, column 9
to line 1, column 66: Cannot apply 'TIMESTAMPDIFF' to arguments of type
'TIMESTAMPDIFF(, , )'. Supported form(s):
'TIMESTAMPDIFF(, , )'
at
org.apache.calcite.runtime.Resources$ExInstWithCause.ex(Resources.java:505)
at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:945)
at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:930)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.newValidationError(SqlValidatorImpl.java:5424)
at
org.apache.calcite.sql.SqlCallBinding.newValidationSignatureError(SqlCallBinding.java:401)
at
org.apache.calcite.sql.type.FamilyOperandTypeChecker.checkSingleOperandType(FamilyOperandTypeChecker.java:108)
at
org.apache.calcite.sql.type.FamilyOperandTypeChecker.checkOperandTypes(FamilyOperandTypeChecker.java:142)
at
org.apache.calcite.sql.SqlOperator.checkOperandTypes(SqlOperator.java:753)
at
org.apache.calcite.sql.SqlOperator.validateOperands(SqlOperator.java:499)
at org.apache.calcite.sql.SqlFunction.deriveType(SqlFunction.java:335)
at org.apache.calcite.sql.SqlFunction.deriveType(SqlFunction.java:231)
at
org.apache.calcite.sql.validate.SqlValidatorImpl$DeriveTypeVisitor.visit(SqlValidatorImpl.java:6451)
at
org.apache.calcite.sql.validate.SqlValidatorImpl$DeriveTypeVisitor.visit(SqlValidatorImpl.java:6438)
at org.apache.calcite.sql.SqlCall.accept(SqlCall.java:161)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.deriveTypeImpl(SqlValidatorImpl.java:1892)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.deriveType(SqlValidatorImpl.java:1877)
at org.apache.calcite.sql.SqlNode.validateExpr(SqlNode.java:276)
at org.apache.calcite.sql.SqlOperator.validateCall(SqlOperator.java:474)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validateCall(SqlValidatorImpl.java:6129)
at org.apache.calcite.sql.SqlCall.validate(SqlCall.java:138)
at org.apache.calcite.sql.SqlNode.validateExpr(SqlNode.java:275)
at org.apache.calcite.sql.SqlOperator.validateCall(SqlOperator.java:474)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validateCall(SqlValidatorImpl.java:6129)
at org.apache.calcite.sql.SqlCall.validate(SqlCall.java:138)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validateScopedExpression(SqlValidatorImpl.java:1076)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validate(SqlValidatorImpl.java:782)
at
org.apache.calcite.sql.test.AbstractSqlTester.parseAndValidate(AbstractSqlTester.java:160)
at
org.apache.calcite.sql.test.AbstractSqlTester.validateAndThen(AbstractSqlTester.java:248)
at
org.apache.calcite.test.SqlOperatorFixtureImpl.lambda$forEachQueryValidateAndThen$1(SqlOperatorFixtureImpl.java:154)
at
org.apache.calcite.sql.test.AbstractSqlTester.forEachQuery(AbstractSqlTester.java:441)
at
org.apache.calcite.test.SqlOperatorFixtureImpl.forEachQueryValidateAndThen(SqlOperatorFixtureImpl.java:153)
at
org.apache.calcite.test.SqlOperatorFixtureImpl.checkType(SqlOperatorFixtureImpl.java:130)
at
org.apache.calcite.sql.test.SqlOperatorFixture.checkScalar(SqlOperatorFixture.java:237)
at
org.apache.calcite.test.SqlOperatorTest.lambda$testTimestampDiff$96(SqlOperatorTest.java:8208)
{noformat}
an example of query
{code:sql}
SELECT TIMESTAMPDIFF(MONTH, TIME '00:00:00', TIMESTAMP '2021-02-04 12:00:00');
SELECT TIMESTAMPDIFF(MONTH, TIME '00:00:00', DATE '2021-02-04');
{code}
also in case of turned off type coercion
{code:sql}
SELECT TIMESTAMPDIFF(MONTH, DATE '2021-02-04', DATE '2021-02-04');
{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CALCITE-5489) Cannot convert TIMESTAMP literal to class org.apache.calcite.avatica.util.TimeUnit
Sergey Nuyanzin created CALCITE-5489:
Summary: Cannot convert TIMESTAMP literal to class
org.apache.calcite.avatica.util.TimeUnit
Key: CALCITE-5489
URL: https://issues.apache.org/jira/browse/CALCITE-5489
Project: Calcite
Issue Type: Bug
Affects Versions: 1.33.0
Reporter: Sergey Nuyanzin
It seems it stops working after {noformat}[CALCITE-5360] Add TIMESTAMP_ADD
function (enabled in BigQuery library){noformat} for {{RexCallBinding}}
e.g. this tests starts failing
{code:java}
@Test void testTimestampDiffCall() {
final RelDataTypeFactory typeFactory = new
SqlTypeFactoryImpl(RelDataTypeSystem.DEFAULT);
RexBuilder rexBuilder = new RexBuilder(typeFactory);
final RexImplicationCheckerFixtures.Fixture f = new
RexImplicationCheckerFixtures.Fixture();
final TimestampString ts =
TimestampString.fromCalendarFields(Util.calendar());
rexBuilder.makeCall(SqlStdOperatorTable.TIMESTAMP_DIFF,
ImmutableList.of(rexBuilder.makeFlag(TimeUnit.QUARTER),
f.timestampLiteral(ts), f.timestampLiteral(ts)));
}
{code}
like
{noformat}
cannot convert TIMESTAMP literal to class
org.apache.calcite.avatica.util.TimeUnit
java.lang.AssertionError: cannot convert TIMESTAMP literal to class
org.apache.calcite.avatica.util.TimeUnit
at org.apache.calcite.rex.RexLiteral.getValueAs(RexLiteral.java:1143)
at
org.apache.calcite.rex.RexCallBinding.getOperandLiteralValue(RexCallBinding.java:100)
at
org.apache.calcite.sql.fun.SqlTimestampDiffFunction.inferReturnType2(SqlTimestampDiffFunction.java:69)
at
org.apache.calcite.sql.SqlOperator.inferReturnType(SqlOperator.java:537)
at
org.apache.calcite.rex.RexBuilder.deriveReturnType(RexBuilder.java:292)
at org.apache.calcite.rex.RexBuilder.makeCall(RexBuilder.java:266)
at
org.apache.calcite.rex.RexBuilderTest.testTimestampDiffCall(RexBuilderTest.java:863)
...
{noformat}
It seems it recognise {{FLAG(QUARTER)}} as a literal...
at {{org.apache.calcite.sql.fun.SqlTimestampDiffFunction#inferReturnType2}}
{code:java}
if (opBinding.getOperandLiteralValue(2, Object.class) instanceof TimeUnit) {
type1 = opBinding.getOperandType(0);
type2 = opBinding.getOperandType(1);
timeUnit = opBinding.getOperandLiteralValue(2, TimeUnit.class);
} else {
timeUnit = opBinding.getOperandLiteralValue(0, TimeUnit.class);
type1 = opBinding.getOperandType(1);
type2 = opBinding.getOperandType(2);
}
{code}
Probably the condition ahould be something like that
{code:java}
if (opBinding.getOperandLiteralValue(2, Object.class) instanceof TimeUnit) {
...}
{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CALCITE-5440) Bump gradle to 7.6
Sergey Nuyanzin created CALCITE-5440: Summary: Bump gradle to 7.6 Key: CALCITE-5440 URL: https://issues.apache.org/jira/browse/CALCITE-5440 Project: Calcite Issue Type: Improvement Components: build Reporter: Sergey Nuyanzin Assignee: Sergey Nuyanzin Gradle 7.6 is available. Also one thing about kotlin should be added into readme since right now it is missing there. Kotlin version should be synced based on [https://docs.gradle.org/current/userguide/compatibility.html#kotlin] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CALCITE-5381) Add configuration via property to turn on/off check if correlated in RelBuilder
Sergey Nuyanzin created CALCITE-5381: Summary: Add configuration via property to turn on/off check if correlated in RelBuilder Key: CALCITE-5381 URL: https://issues.apache.org/jira/browse/CALCITE-5381 Project: Calcite Issue Type: Improvement Components: core Reporter: Sergey Nuyanzin The issue is that the change done in https://issues.apache.org/jira/browse/CALCITE-4668 is not supported now in Flink and requires some significant efforts to make it working. At the same time we would like to move it forward with Calcite update. Currently there is no way to turn this off via property e.g. or via overriding of methods. This jira issues proposes introducing such property (turn on by default) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CALCITE-5380) CompositeSingleOperandTypeChecker fails with index (1) must be less than size (1)
Sergey Nuyanzin created CALCITE-5380:
Summary: CompositeSingleOperandTypeChecker fails with index (1)
must be less than size (1)
Key: CALCITE-5380
URL: https://issues.apache.org/jira/browse/CALCITE-5380
Project: Calcite
Issue Type: Improvement
Components: core
Affects Versions: 1.33.0
Reporter: Sergey Nuyanzin
I try to check main branch against existing Flink tests.
One of the things I faced is that existing Flink function
{code:java}
public class SqlListAggFunction extends SqlAggFunction {
public SqlListAggFunction() {
super(
"LISTAGG",
null,
SqlKind.LISTAGG,
ReturnTypes.ARG0_NULLABLE,
null,
OperandTypes.or(
OperandTypes.CHARACTER,
OperandTypes.sequence(
"'LISTAGG(, )'",
OperandTypes.CHARACTER,
OperandTypes.and(OperandTypes.CHARACTER,
OperandTypes.LITERAL))),
SqlFunctionCategory.SYSTEM,
false,
false);
}
@Override
public List getParameterTypes(RelDataTypeFactory typeFactory) {
return ImmutableList.of(
typeFactory.createTypeWithNullability(
typeFactory.createSqlType(SqlTypeName.VARCHAR), true));
}
@Override
public RelDataType getReturnType(RelDataTypeFactory typeFactory) {
return typeFactory.createSqlType(SqlTypeName.VARCHAR);
}
}
{code}
started to fail with
{noformat}
org.apache.flink.table.api.ValidationException: SQL validation failed. index
(1) must be less than size (1)
at
org.apache.flink.table.planner.calcite.FlinkPlannerImpl.org$apache$flink$table$planner$calcite$FlinkPlannerImpl$$validate(FlinkPlannerImpl.scala:186)
at
org.apache.flink.table.planner.calcite.FlinkPlannerImpl.validate(FlinkPlannerImpl.scala:113)
at
org.apache.flink.table.planner.operations.SqlToOperationConverter.convert(SqlToOperationConverter.java:263)
at
org.apache.flink.table.planner.delegation.ParserImpl.parse(ParserImpl.java:106)
at
org.apache.flink.table.api.internal.TableEnvironmentImpl.sqlQuery(TableEnvironmentImpl.java:734)
at
org.apache.flink.table.api.stream.ExplainTest.testMiniBatchIntervalInfer(ExplainTest.scala:150)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at
org.junit.rules.ExpectedException$ExpectedExceptionStatement.evaluate(ExpectedException.java:258)
at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:61)
at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:54)
at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
at
org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
at org.junit.runners.Suite.runChild(Suite.java:128)
at org.junit.runners.Suite.runChild(Suite.java:27)
at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
at
[jira] [Created] (CALCITE-5379) Upgrade protobuf version to 3.21.9 because of CVE
Sergey Nuyanzin created CALCITE-5379: Summary: Upgrade protobuf version to 3.21.9 because of CVE Key: CALCITE-5379 URL: https://issues.apache.org/jira/browse/CALCITE-5379 Project: Calcite Issue Type: Improvement Components: avatica Affects Versions: avatica-1.22.0 Reporter: Sergey Nuyanzin There is a CVE in current version https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-3171 fixed in 3.21.7 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CALCITE-5374) Upgrade jackson version to 2.14.0
Sergey Nuyanzin created CALCITE-5374: Summary: Upgrade jackson version to 2.14.0 Key: CALCITE-5374 URL: https://issues.apache.org/jira/browse/CALCITE-5374 Project: Calcite Issue Type: Improvement Components: avatica Reporter: Sergey Nuyanzin Seems I forgot to make similar update for avatica. At the same time a newer version 2.14.0 is already available -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CALCITE-5373) Upgrade bouncycastle version to 1.70
Sergey Nuyanzin created CALCITE-5373: Summary: Upgrade bouncycastle version to 1.70 Key: CALCITE-5373 URL: https://issues.apache.org/jira/browse/CALCITE-5373 Project: Calcite Issue Type: Improvement Components: avatica Reporter: Sergey Nuyanzin It was not updated for a while and current version has a CVE https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-15522 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CALCITE-5361) Update janino version to 3.1.9
Sergey Nuyanzin created CALCITE-5361: Summary: Update janino version to 3.1.9 Key: CALCITE-5361 URL: https://issues.apache.org/jira/browse/CALCITE-5361 Project: Calcite Issue Type: Improvement Reporter: Sergey Nuyanzin This is a follow up task to update janino it is not released yet. while upgrade of Calcite to 1.28 for Flink (https://issues.apache.org/jira/browse/FLINK-21239) I faced a number of issues in janino https://github.com/janino-compiler/janino/issues/185 https://github.com/janino-compiler/janino/issues/186 https://github.com/janino-compiler/janino/issues/187 https://github.com/janino-compiler/janino/issues/188 would be great to update janino once the fix version will be released -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CALCITE-5356) Update junit4 to 4.13.2 and junit5 to 5.9.1
Sergey Nuyanzin created CALCITE-5356:
Summary: Update junit4 to 4.13.2 and junit5 to 5.9.1
Key: CALCITE-5356
URL: https://issues.apache.org/jira/browse/CALCITE-5356
Project: Calcite
Issue Type: Improvement
Components: tests
Reporter: Sergey Nuyanzin
Assignee: Sergey Nuyanzin
junit4 to 4.13.2
junit5 to 5.9.1
It seems there is an issue with {{org.apache.calcite.test.QuidemTest#data}}
The idea is to make test per class and parameterized method
abstract/implemented in each test
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CALCITE-5351) Bump jackson to 2.13.4 and jackson databind to 2.13.4.2 to avoid CVEs
Sergey Nuyanzin created CALCITE-5351: Summary: Bump jackson to 2.13.4 and jackson databind to 2.13.4.2 to avoid CVEs Key: CALCITE-5351 URL: https://issues.apache.org/jira/browse/CALCITE-5351 Project: Calcite Issue Type: Bug Components: core Affects Versions: 1.32.0 Reporter: Sergey Nuyanzin There are 2 CVEs in currently used jackson https://nvd.nist.gov/vuln/detail/CVE-2022-42003 https://nvd.nist.gov/vuln/detail/CVE-2022-42004 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CALCITE-5339) Use Method#getParameterCount rather than Method#getParameters to get length
Sergey Nuyanzin created CALCITE-5339:
Summary: Use Method#getParameterCount rather than
Method#getParameters to get length
Key: CALCITE-5339
URL: https://issues.apache.org/jira/browse/CALCITE-5339
Project: Calcite
Issue Type: Improvement
Components: core, tests
Reporter: Sergey Nuyanzin
The issue with {{Method#getParameters}} is that each time it creates a new
array by calling clone. It does not make sense for the cases when only
knowledge about number of parameters is required
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CALCITE-5197) Bump gradle to 7.4.2 and add checksum autoupdate
Sergey Nuyanzin created CALCITE-5197:
Summary: Bump gradle to 7.4.2 and add checksum autoupdate
Key: CALCITE-5197
URL: https://issues.apache.org/jira/browse/CALCITE-5197
Project: Calcite
Issue Type: Improvement
Components: build
Affects Versions: 1.30.0
Reporter: Sergey Nuyanzin
The problem with gradle update via
{code}
./gradlew wrapper --gradle-version && ./gradlew autostyleApply
{code}
it removes checksum from {{gradle/wrapper/gradle-wrapper.properties}}
there could be added a task which could update checksum as well, e.g.
{code:kotlin}
tasks.wrapper {
distributionType = Wrapper.DistributionType.BIN
doLast {
val sha256Uri = URI("$distributionUrl.sha256")
val sha256Sum = String(sha256Uri.toURL().readBytes())
propertiesFile.appendText("distributionSha256Sum=${sha256Sum}\n")
}
}
{code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Created] (CALCITE-5196) Bump apiguardian version to 1.1.2 (latest)
Sergey Nuyanzin created CALCITE-5196: Summary: Bump apiguardian version to 1.1.2 (latest) Key: CALCITE-5196 URL: https://issues.apache.org/jira/browse/CALCITE-5196 Project: Calcite Issue Type: Improvement Affects Versions: 1.30.0 Reporter: Sergey Nuyanzin Assignee: Sergey Nuyanzin -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Created] (CALCITE-4890) Enable mavenLocal for sqlline
Sergey Nuyanzin created CALCITE-4890:
Summary: Enable mavenLocal for sqlline
Key: CALCITE-4890
URL: https://issues.apache.org/jira/browse/CALCITE-4890
Project: Calcite
Issue Type: Bug
Reporter: Sergey Nuyanzin
currently with enabled {{enableMavenLocal=true}} it fails
with
{noformat}
Build calcite FAILURE reason:
Execution failed for task ':buildSqllineClasspath':
org.gradle.api.internal.artifacts.ivyservice.DefaultLenientConfiguration$ArtifactResolveException:
Could not resolve all files for configuration ':sqllineClasspath'.
at
org.gradle.api.internal.artifacts.configurations.DefaultConfiguration.rethrowFailure(DefaultConfiguration.java:1423)
at
org.gradle.api.internal.artifacts.configurations.DefaultConfiguration.access$3600(DefaultConfiguration.java:152)
at
org.gradle.api.internal.artifacts.configurations.DefaultConfiguration$DefaultResolutionHost.rethrowFailure(DefaultConfiguration.java:2035)
at
org.gradle.api.internal.artifacts.configurations.DefaultConfiguration$ConfigurationFileCollection.visitContents(DefaultConfiguration.java:1395)
at
org.gradle.api.internal.file.AbstractFileCollection.getFiles(AbstractFileCollection.java:130)
at
org.gradle.api.internal.file.AbstractFileCollection.iterator(AbstractFileCollection.java:176)
at
org.gradle.api.internal.artifacts.configurations.DefaultConfiguration.iterator(DefaultConfiguration.java:493)
at
kotlin.collections.CollectionsKt___CollectionsKt.joinTo(_Collections.kt:3341)
at
kotlin.collections.CollectionsKt___CollectionsKt.joinToString(_Collections.kt:3361)
at
kotlin.collections.CollectionsKt___CollectionsKt.joinToString$default(_Collections.kt:3360)
at
Build_gradle$buildSqllineClasspath$2$1$1.call(build.gradle.kts:231)
at
Build_gradle$buildSqllineClasspath$2$1$1.call(build.gradle.kts:30)
at
org.gradle.api.internal.provider.DefaultProvider.calculateOwnValue(DefaultProvider.java:66)
at
org.gradle.api.internal.provider.AbstractMinimalProvider.calculatePresence(AbstractMinimalProvider.java:79)
at
org.gradle.api.internal.provider.AbstractMinimalProvider.isPresent(AbstractMinimalProvider.java:74)
at
org.gradle.api.java.archives.internal.DefaultManifest.resolveValueToString(DefaultManifest.java:171)
at
org.gradle.api.java.archives.internal.DefaultManifest.fillAttributes(DefaultManifest.java:160)
at
org.gradle.api.java.archives.internal.DefaultManifest.addMainAttributesToJavaManifest(DefaultManifest.java:145)
at
org.gradle.api.java.archives.internal.DefaultManifest.generateJavaManifest(DefaultManifest.java:139)
at
org.gradle.api.java.archives.internal.DefaultManifest.writeTo(DefaultManifest.java:219)
at
org.gradle.api.java.archives.internal.DefaultManifest.writeTo(DefaultManifest.java:213)
at
org.gradle.jvm.tasks.Jar.lambda$manifestFileTree$b030d21f$1(Jar.java:74)
at
org.gradle.api.internal.file.collections.GeneratedSingletonFileTree$FileVisitDetailsImpl.copyTo(GeneratedSingletonFileTree.java:196)
at
org.gradle.api.internal.file.collections.GeneratedSingletonFileTree$FileVisitDetailsImpl.generateContent(GeneratedSingletonFileTree.java:174)
at
org.gradle.api.internal.file.collections.GeneratedSingletonFileTree$FileVisitDetailsImpl.updateFileOnlyWhenGeneratedContentChanges(GeneratedSingletonFileTree.java:161)
at
org.gradle.api.internal.file.collections.GeneratedSingletonFileTree$FileVisitDetailsImpl.getFile(GeneratedSingletonFileTree.java:149)
at
org.gradle.api.internal.file.collections.GeneratedSingletonFileTree.getFile(GeneratedSingletonFileTree.java:91)
at
org.gradle.api.internal.file.collections.GeneratedSingletonFileTree.visitStructure(GeneratedSingletonFileTree.java:109)
at
org.gradle.api.internal.file.collections.FileTreeAdapter.visitContents(FileTreeAdapter.java:101)
at
org.gradle.api.internal.file.AbstractFileCollection.visitStructure(AbstractFileCollection.java:330)
at
org.gradle.api.internal.file.CompositeFileCollection.lambda$visitContents$0(CompositeFileCollection.java:119)
at
org.gradle.api.internal.file.collections.UnpackingVisitor.add(UnpackingVisitor.java:64)
at
org.gradle.api.internal.file.collections.DefaultConfigurableFileCollection$UnresolvedItemsCollector.visitContents(DefaultConfigurableFileCollection.java:372)
at
org.gradle.api.internal.file.collections.DefaultConfigurableFileCollection.visitChildren(DefaultConfigurableFileCollection.java:284)
at
[jira] [Created] (CALCITE-4850) Wrong result retrieving from ARRAY with mixed INTEGER and DECIMAL elements
Sergey Nuyanzin created CALCITE-4850:
Summary: Wrong result retrieving from ARRAY with mixed INTEGER and
DECIMAL elements
Key: CALCITE-4850
URL: https://issues.apache.org/jira/browse/CALCITE-4850
Project: Calcite
Issue Type: Bug
Reporter: Sergey Nuyanzin
The issue is a follow-up for
https://issues.apache.org/jira/browse/CALCITE-4602?focusedCommentId=17427917=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17427917
to reproduce
{code:sql}
select array[1.1, 1];
+-+
| EXPR$0|
+-+
| [1.1, 0E+1] |
+-+
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (CALCITE-4842) Nested row type fails with unsupported type Record2_2
Sergey Nuyanzin created CALCITE-4842:
Summary: Nested row type fails with unsupported type Record2_2
Key: CALCITE-4842
URL: https://issues.apache.org/jira/browse/CALCITE-4842
Project: Calcite
Issue Type: Bug
Components: core
Affects Versions: 1.27.0
Reporter: Sergey Nuyanzin
Queries with nested rows fail with the exception below
for instance these queries could be used to reproduce
{code:sql}
select row(row(1));
select row(row(1, 2), row(3, 4));
{code}
At the same time
{code:sql}
select array[row(row(1))];
select array[row(row(1, 2), row(3, 4))];
{code}
are ok
{noformat}
java.sql.SQLException: Error while executing SQL "select row(row(1))":
unsupported type Record1_0
at org.apache.calcite.avatica.Helper.createException(Helper.java:56)
at org.apache.calcite.avatica.Helper.createException(Helper.java:41)
at
org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:163)
at
org.apache.calcite.avatica.AvaticaStatement.execute(AvaticaStatement.java:217)
at sqlline.Commands.executeSingleQuery(Commands.java:1130)
at sqlline.Commands.execute(Commands.java:1079)
at sqlline.Commands.sql(Commands.java:1033)
at sqlline.SqlLine.dispatch(SqlLine.java:822)
at sqlline.SqlLine.begin(SqlLine.java:596)
at sqlline.SqlLine.start(SqlLine.java:269)
at sqlline.SqlLine.main(SqlLine.java:208)
Caused by: java.lang.RuntimeException: unsupported type Record1_0
at org.apache.calcite.linq4j.tree.Types.toClass(Types.java:152)
at org.apache.calcite.linq4j.tree.Types.toClassArray(Types.java:166)
at org.apache.calcite.linq4j.tree.Expressions.call(Expressions.java:449)
at
org.apache.calcite.adapter.enumerable.EnumerableRelImplementor.classDecl(EnumerableRelImplementor.java:292)
at
org.apache.calcite.adapter.enumerable.EnumerableRelImplementor.access$000(EnumerableRelImplementor.java:79)
at
org.apache.calcite.adapter.enumerable.EnumerableRelImplementor$TypeRegistrar.register(EnumerableRelImplementor.java:562)
at
org.apache.calcite.adapter.enumerable.EnumerableRelImplementor$TypeRegistrar.register(EnumerableRelImplementor.java:566)
at
org.apache.calcite.adapter.enumerable.EnumerableRelImplementor$TypeRegistrar.go(EnumerableRelImplementor.java:576)
at
org.apache.calcite.adapter.enumerable.EnumerableRelImplementor.implementRoot(EnumerableRelImplementor.java:146)
at
org.apache.calcite.adapter.enumerable.EnumerableInterpretable.toBindable(EnumerableInterpretable.java:113)
at
org.apache.calcite.prepare.CalcitePrepareImpl$CalcitePreparingStmt.implement(CalcitePrepareImpl.java:1130)
at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:318)
at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:215)
at
org.apache.calcite.prepare.CalcitePrepareImpl.prepare2_(CalcitePrepareImpl.java:647)
at
org.apache.calcite.prepare.CalcitePrepareImpl.prepare_(CalcitePrepareImpl.java:513)
at
org.apache.calcite.prepare.CalcitePrepareImpl.prepareSql(CalcitePrepareImpl.java:483)
at
org.apache.calcite.jdbc.CalciteConnectionImpl.parseQuery(CalciteConnectionImpl.java:249)
at
org.apache.calcite.jdbc.CalciteMetaImpl.prepareAndExecute(CalciteMetaImpl.java:623)
at
org.apache.calcite.avatica.AvaticaConnection.prepareAndExecuteInternal(AvaticaConnection.java:675)
at
org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:156)
... 8 more
{noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [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] [Created] (CALCITE-4822) Add ARRAY_CONCAT, ARRAY_REVERSE, ARRAY_LENGTH for BigQuery dialect
Sergey Nuyanzin created CALCITE-4822:
Summary: Add ARRAY_CONCAT, ARRAY_REVERSE, ARRAY_LENGTH for
BigQuery dialect
Key: CALCITE-4822
URL: https://issues.apache.org/jira/browse/CALCITE-4822
Project: Calcite
Issue Type: Improvement
Components: core
Reporter: Sergey Nuyanzin
{{ARRAY_CONCAT}} - Concatenates one or more arrays with the same element type
into a single array.
{{ARRAY_LENGTH}} - Returns the size of the array. Synonym for {{CARDINALITY}}.
{{ARRAY_REVERSE}} - Returns the input ARRAY with elements in reverse order.
For more details
[https://cloud.google.com/bigquery/docs/reference/standard-sql/array_functions#array_concat]
[https://cloud.google.com/bigquery/docs/reference/standard-sql/array_functions#array_length]
[https://cloud.google.com/bigquery/docs/reference/standard-sql/array_functions#array_reverse]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (CALCITE-4813) ANY_VALUE assumes that arguments should be comparable
Sergey Nuyanzin created CALCITE-4813:
Summary: ANY_VALUE assumes that arguments should be comparable
Key: CALCITE-4813
URL: https://issues.apache.org/jira/browse/CALCITE-4813
Project: Calcite
Issue Type: Bug
Components: core
Affects Versions: 1.27.0
Reporter: Sergey Nuyanzin
ANY_VALUE reuses {{MinMaxImplementor}}, as a result it assumes that there are
corresponding {{greater}} methods.
In fact for non comparable input it fails, for instance every query from
{code:sql}
select any_value(r) over(), s from(select array[f, s] r, s from (select 1 as f,
2 as s) t) t;
select any_value(r) over(), s from(select map[f, s] r, s from (select 1 as f, 2
as s) t) t;
select any_value(r) over(), s from(select row(f, s) r, s from (select 1 as f, 2
as s) t) t;
{code}
will fail like
{noformat}
Caused by: java.lang.IllegalStateException: Unable to implement
EnumerableCalc(expr#0..2=[{inputs}], EXPR$0=[$t2], S=[$t0]): rowcount = 1.0,
cumulative cost = {4.0 rows, 13.0 cpu, 0.0 io}, id = 509
EnumerableWindow(window#0=[window(aggs [ANY_VALUE($1)])]): rowcount = 1.0,
cumulative cost = {3.0 rows, 8.0 cpu, 0.0 io}, id = 505
EnumerableCalc(expr#0..1=[{inputs}], expr#2=[ARRAY($t0, $t1)], S=[$t1],
$1=[$t2]): rowcount = 1.0, cumulative cost = {2.0 rows, 6.0 cpu, 0.0 io}, id =
511
EnumerableValues(tuples=[[{ 1, 2 }]]): rowcount = 1.0, cumulative cost =
{1.0 rows, 1.0 cpu, 0.0 io}, id = 480
at
org.apache.calcite.adapter.enumerable.EnumerableRelImplementor.implementRoot(EnumerableRelImplementor.java:114)
at
org.apache.calcite.adapter.enumerable.EnumerableInterpretable.toBindable(EnumerableInterpretable.java:113)
at
org.apache.calcite.prepare.CalcitePrepareImpl$CalcitePreparingStmt.implement(CalcitePrepareImpl.java:1130)
at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:318)
at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:215)
at
org.apache.calcite.prepare.CalcitePrepareImpl.prepare2_(CalcitePrepareImpl.java:647)
at
org.apache.calcite.prepare.CalcitePrepareImpl.prepare_(CalcitePrepareImpl.java:513)
at
org.apache.calcite.prepare.CalcitePrepareImpl.prepareSql(CalcitePrepareImpl.java:483)
at
org.apache.calcite.jdbc.CalciteConnectionImpl.parseQuery(CalciteConnectionImpl.java:249)
at
org.apache.calcite.jdbc.CalciteMetaImpl.prepareAndExecute(CalciteMetaImpl.java:623)
at
org.apache.calcite.avatica.AvaticaConnection.prepareAndExecuteInternal(AvaticaConnection.java:675)
at
org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:156)
... 8 more
Suppressed: java.lang.RuntimeException: while resolving method
'greater[interface java.util.List, interface java.util.List]' in class class
org.apache.calcite.runtime.SqlFunctions
at
org.apache.calcite.linq4j.tree.Types.lookupMethod(Types.java:318)
at
org.apache.calcite.linq4j.tree.Expressions.call(Expressions.java:448)
at
org.apache.calcite.linq4j.tree.Expressions.call(Expressions.java:460)
at
org.apache.calcite.adapter.enumerable.RexImpTable$MinMaxImplementor.implementNotNullAdd(RexImpTable.java:1113)
at
org.apache.calcite.adapter.enumerable.StrictAggImplementor.implementAdd(StrictAggImplementor.java:151)
at
org.apache.calcite.adapter.enumerable.EnumerableWindow.implementAdd(EnumerableWindow.java:880)
at
org.apache.calcite.adapter.enumerable.EnumerableWindow.implement(EnumerableWindow.java:464)
at
org.apache.calcite.adapter.enumerable.EnumerableRelImplementor.visitChild(EnumerableRelImplementor.java:104)
at
org.apache.calcite.adapter.enumerable.EnumerableCalc.implement(EnumerableCalc.java:118)
at
org.apache.calcite.adapter.enumerable.EnumerableRelImplementor.implementRoot(EnumerableRelImplementor.java:111)
... 19 more
Caused by: java.lang.NoSuchMethodException:
org.apache.calcite.runtime.SqlFunctions.greater(java.util.List, java.util.List)
at java.base/java.lang.Class.getMethod(Class.java:2108)
at
org.apache.calcite.linq4j.tree.Types.lookupMethod(Types.java:309)
... 28 more
{noformat}
>From one side ANY_VALUE does not guarantee being deterministic (however it
>looks like Calcite always picks min value),
from another side to avoid changing the existing behavior it could be redefine
for non comparable input like pick the first available value
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (CALCITE-4811) Coalesce(null, row) fails with NPE
Sergey Nuyanzin created CALCITE-4811:
Summary: Coalesce(null, row) fails with NPE
Key: CALCITE-4811
URL: https://issues.apache.org/jira/browse/CALCITE-4811
Project: Calcite
Issue Type: Bug
Components: core
Affects Versions: 1.27.0
Reporter: Sergey Nuyanzin
Case to reproduce
{code:sql}
select coalesce(null, row(1));
{code}
This and other similar queries fail with
{noformat}
java.sql.SQLException: Error while executing SQL "select coalesce(null,
row(1))": null
at org.apache.calcite.avatica.Helper.createException(Helper.java:56)
at org.apache.calcite.avatica.Helper.createException(Helper.java:41)
at
org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:163)
at
org.apache.calcite.avatica.AvaticaStatement.execute(AvaticaStatement.java:217)
at sqlline.Commands.executeSingleQuery(Commands.java:1130)
at sqlline.Commands.execute(Commands.java:1079)
at sqlline.Commands.sql(Commands.java:1033)
at sqlline.SqlLine.dispatch(SqlLine.java:822)
at sqlline.SqlLine.begin(SqlLine.java:596)
at sqlline.SqlLine.start(SqlLine.java:269)
at sqlline.SqlLine.main(SqlLine.java:208)
Caused by: java.lang.NullPointerException
at
org.apache.calcite.rel.type.RelDataTypeImpl.getFieldCount(RelDataTypeImpl.java:175)
at
org.apache.calcite.rel.type.RelDataTypeFactoryImpl.leastRestrictiveStructuredType(RelDataTypeFactoryImpl.java:228)
at
org.apache.calcite.sql.type.SqlTypeFactoryImpl.leastRestrictiveSqlType(SqlTypeFactoryImpl.java:292)
at
org.apache.calcite.sql.type.SqlTypeFactoryImpl.leastRestrictive(SqlTypeFactoryImpl.java:160)
at
org.apache.calcite.sql.fun.SqlCaseOperator.inferTypeFromValidator(SqlCaseOperator.java:263)
at
org.apache.calcite.sql.fun.SqlCaseOperator.inferReturnType(SqlCaseOperator.java:225)
at
org.apache.calcite.sql.SqlOperator.validateOperands(SqlOperator.java:502)
at
org.apache.calcite.sql.fun.SqlCaseOperator.deriveType(SqlCaseOperator.java:172)
at
org.apache.calcite.sql.validate.SqlValidatorImpl$DeriveTypeVisitor.visit(SqlValidatorImpl.java:6277)
at
org.apache.calcite.sql.validate.SqlValidatorImpl$DeriveTypeVisitor.visit(SqlValidatorImpl.java:6264)
at org.apache.calcite.sql.SqlCall.accept(SqlCall.java:161)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.deriveTypeImpl(SqlValidatorImpl.java:1862)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.deriveType(SqlValidatorImpl.java:1847)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.inferUnknownTypes(SqlValidatorImpl.java:2019)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.expandSelectItem(SqlValidatorImpl.java:461)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validateSelectList(SqlValidatorImpl.java:4409)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validateSelect(SqlValidatorImpl.java:3652)
at
org.apache.calcite.sql.validate.SelectNamespace.validateImpl(SelectNamespace.java:64)
at
org.apache.calcite.sql.validate.AbstractNamespace.validate(AbstractNamespace.java:89)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validateNamespace(SqlValidatorImpl.java:1100)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validateQuery(SqlValidatorImpl.java:1071)
at org.apache.calcite.sql.SqlSelect.validate(SqlSelect.java:247)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validateScopedExpression(SqlValidatorImpl.java:1046)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validate(SqlValidatorImpl.java:752)
at
org.apache.calcite.sql2rel.SqlToRelConverter.convertQuery(SqlToRelConverter.java:585)
at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:251)
at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:215)
at
org.apache.calcite.prepare.CalcitePrepareImpl.prepare2_(CalcitePrepareImpl.java:647)
at
org.apache.calcite.prepare.CalcitePrepareImpl.prepare_(CalcitePrepareImpl.java:513)
at
org.apache.calcite.prepare.CalcitePrepareImpl.prepareSql(CalcitePrepareImpl.java:483)
at
org.apache.calcite.jdbc.CalciteConnectionImpl.parseQuery(CalciteConnectionImpl.java:249)
at
org.apache.calcite.jdbc.CalciteMetaImpl.prepareAndExecute(CalciteMetaImpl.java:623)
at
org.apache.calcite.avatica.AvaticaConnection.prepareAndExecuteInternal(AvaticaConnection.java:675)
at
org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:156)
... 8 more
{noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (CALCITE-4603) Least restrictive type considers only the last element in collections of collections
Sergey Nuyanzin created CALCITE-4603:
Summary: Least restrictive type considers only the last element in
collections of collections
Key: CALCITE-4603
URL: https://issues.apache.org/jira/browse/CALCITE-4603
Project: Calcite
Issue Type: Bug
Components: core
Affects Versions: 1.26.0
Reporter: Sergey Nuyanzin
It seems least restrictive always returns the type of the last element from the
collection.
For instance for
{code:sql}
select array[array['hello'], array['world'], array['!']] as "array"
{code}
least restrictive gives {{CHAR(1) ARRAY ARRAY}} instead of {{CHAR(5) ARRAY
ARRAY}}
for
{code:sql}
select map[map[1.1, 2.1], map[1.1, 2.1], map[1, 1], map[1, 1]] as "map";
{code}
least restrictive gives {{((INTEGER, INTEGER) MAP, (INTEGER, INTEGER) MAP)
MAP}} instead of \{{((DECIMAL(2, 1), DECIMAL(2, 1)) MAP, (DECIMAL(2, 1),
DECIMAL(2, 1)) MAP) MAP }}
for
{code:sql}
select multiset[array['hello'], array['world'], array['!']] as "multiset";
{code}
least restrictive gives \{{CHAR(1) ARRAY MULTISET }} instead of \{{CHAR(5)
ARRAY MULTISET }}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (CALCITE-4602) ClassCastException for arrays with int and decimal elements within one array
Sergey Nuyanzin created CALCITE-4602:
Summary: ClassCastException for arrays with int and decimal
elements within one array
Key: CALCITE-4602
URL: https://issues.apache.org/jira/browse/CALCITE-4602
Project: Calcite
Issue Type: Bug
Affects Versions: avatica-1.17.0
Reporter: Sergey Nuyanzin
Cases to reproduce: any query with array containing both int and bigdecimal
elements for instance
{code:sql}
select array[1, 1.1];
select array[1.1, 1];
{code}
which leads to ClassCastException
{noformat}
class java.lang.Integer cannot be cast to class java.math.BigDecimal
(java.lang.Integer and java.math.BigDecimal are in module java.base of loader
'bootstrap')
java.lang.ClassCastException: class java.lang.Integer cannot be cast to class
java.math.BigDecimal (java.lang.Integer and java.math.BigDecimal are in module
java.base of loader 'bootstrap')
at
org.apache.calcite.avatica.util.AbstractCursor$BigDecimalAccessor.getBigDecimal(AbstractCursor.java:701)
at
org.apache.calcite.avatica.util.AbstractCursor$ArrayAccessor.convertValue(AbstractCursor.java:1338)
at
org.apache.calcite.avatica.util.AbstractCursor$ArrayAccessor.getObject(AbstractCursor.java:1299)
at
org.apache.calcite.avatica.util.AbstractCursor$ArrayAccessor.getArray(AbstractCursor.java:1352)
at
org.apache.calcite.avatica.util.AbstractCursor$ArrayAccessor.getString(AbstractCursor.java:1364)
at
org.apache.calcite.avatica.AvaticaResultSet.getString(AvaticaResultSet.java:239)
{noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (CALCITE-4600) ClassCastException for arrays with date/time/timestamp elements
Sergey Nuyanzin created CALCITE-4600:
Summary: ClassCastException for arrays with date/time/timestamp
elements
Key: CALCITE-4600
URL: https://issues.apache.org/jira/browse/CALCITE-4600
Project: Calcite
Issue Type: Bug
Components: avatica
Affects Versions: avatica-1.17.0
Reporter: Sergey Nuyanzin
cases to reproduce
{code:sql}
select array[current_date];
select array[cast('1900-1-1' as date)];
select array[current_timestamp];
select array[current_time];
{code}
each query fails with {{ClassCastException}} mentioned below.
It seems the reason is that date/time/timestamp could be both int/long and
java_sql_*.
{noformat}
class java.sql.Date cannot be cast to class java.lang.Number (java.sql.Date is
in module java.sql of loader 'platform'; java.lang.Number is in module
java.base of loader 'bootstrap')
java.lang.ClassCastException: class java.sql.Date cannot be cast to class
java.lang.Number (java.sql.Date is in module java.sql of loader 'platform';
java.lang.Number is in module java.base of loader 'bootstrap')
at
org.apache.calcite.avatica.util.AbstractCursor$NumberAccessor.getNumber(AbstractCursor.java:722)
at
org.apache.calcite.avatica.util.AbstractCursor$DateFromNumberAccessor.getString(AbstractCursor.java:928)
at org.apache.calcite.avatica.util.ArrayImpl.toString(ArrayImpl.java:62)
at
org.apache.calcite.avatica.util.AbstractCursor$ArrayAccessor.getString(AbstractCursor.java:1365)
at
org.apache.calcite.avatica.AvaticaResultSet.getString(AvaticaResultSet.java:239)
{noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (CALCITE-2754) LISTAGG support
Sergey Nuyanzin created CALCITE-2754: Summary: LISTAGG support Key: CALCITE-2754 URL: https://issues.apache.org/jira/browse/CALCITE-2754 Project: Calcite Issue Type: New Feature Components: core Affects Versions: 1.18.0 Reporter: Sergey Nuyanzin Assignee: Sergey Nuyanzin Inspired by CALCITE-2224. There is an implementation of LISTAGG mentioned in description of CALCITE-2224 Unfortunately there is no info about LISTAGG in public available SQL:2016 draft at [1] while there is some description about LISTAGG as feature T625 e.g.at [2] [1] http://jtc1sc32.org/doc/N2551-2600/32N2572T-text_for_ballot-DIS_9075-2.pdf [2] https://modern-sql.com/feature/listagg -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CALCITE-2728) Enable appveyor to test against JDK 11
Sergey Nuyanzin created CALCITE-2728: Summary: Enable appveyor to test against JDK 11 Key: CALCITE-2728 URL: https://issues.apache.org/jira/browse/CALCITE-2728 Project: Calcite Issue Type: Improvement Components: build Reporter: Sergey Nuyanzin Assignee: Sergey Nuyanzin Appveyor added support of build with jdk11 on Windows https://www.appveyor.com/docs/windows-images-software/#java -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CALCITE-2512) StreamTest#testStreamCancel fails in a flaky way
Sergey Nuyanzin created CALCITE-2512:
Summary: StreamTest#testStreamCancel fails in a flaky way
Key: CALCITE-2512
URL: https://issues.apache.org/jira/browse/CALCITE-2512
Project: Calcite
Issue Type: Bug
Reporter: Sergey Nuyanzin
Assignee: Julian Hyde
It fails only once while local build {{mvn clean install}}
the trace is below
it leads to the code
{code}
public static final Function0 ROW_GENERATOR =
new Function0() {
private int counter = 0;
private Iterator items =
Iterables.cycle("paint", "paper", "brush").iterator();
@Override public Object[] apply() {
return new Object[]{System.currentTimeMillis(), counter++,
items.next(), 10};
}
};
{code}
Unfortunately could not reproduce it again. The only thing that I have in mind:
could it happen that items was not initialized before {{items.next()}} call in
{{apply()}}. May be it makes sense to have {{items}} as {{final}}
{noformat}
[INFO] Tests run: 16, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 21.694
s - in org.apache.calcite.test.CoreQuidemTest
[INFO] Running org.apache.calcite.test.StreamTest
java.util.NoSuchElementException
at java.util.ArrayList$Itr.next(ArrayList.java:862)
at com.google.common.collect.Iterators$4.next(Iterators.java:422)
at org.apache.calcite.test.StreamTest$1.apply(StreamTest.java:460)
at org.apache.calcite.test.StreamTest$1.apply(StreamTest.java:454)
at
org.apache.calcite.test.StreamTest$InfiniteOrdersTable$1.next(StreamTest.java:476)
at
org.apache.calcite.test.StreamTest$InfiniteOrdersTable$1.next(StreamTest.java:470)
at
org.apache.calcite.linq4j.Linq4j$IterableEnumerator.moveNext(Linq4j.java:463)
at
org.apache.calcite.linq4j.EnumerableDefaults$11$1.moveNext(EnumerableDefaults.java:1875)
at
org.apache.calcite.linq4j.EnumerableDefaults$11$1.moveNext(EnumerableDefaults.java:1875)
at
org.apache.calcite.linq4j.TransformedEnumerator.moveNext(TransformedEnumerator.java:35)
at
org.apache.calcite.linq4j.Linq4j$EnumeratorIterator.next(Linq4j.java:685)
at
org.apache.calcite.avatica.util.IteratorCursor.next(IteratorCursor.java:46)
at
org.apache.calcite.avatica.AvaticaResultSet.next(AvaticaResultSet.java:217)
at
org.apache.calcite.test.StreamTest.lambda$testStreamCancel$1(StreamTest.java:251)
at
org.apache.calcite.test.CalciteAssert.assertQuery(CalciteAssert.java:552)
at
org.apache.calcite.test.CalciteAssert$AssertQuery.returns(CalciteAssert.java:1328)
at
org.apache.calcite.test.CalciteAssert$AssertQuery.returns(CalciteAssert.java:1305)
at
org.apache.calcite.test.StreamTest.testStreamCancel(StreamTest.java:248)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at
org.junit.internal.runners.statements.FailOnTimeout$CallableStatement.call(FailOnTimeout.java:298)
at
org.junit.internal.runners.statements.FailOnTimeout$CallableStatement.call(FailOnTimeout.java:292)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.lang.Thread.run(Thread.java:748)
[ERROR] Tests run: 9, Failures: 0, Errors: 1, Skipped: 2, Time elapsed: 0.33 s
<<< FAILURE! - in org.apache.calcite.test.StreamTest
[ERROR] testStreamCancel(org.apache.calcite.test.StreamTest) Time elapsed:
0.14 s <<< ERROR!
java.lang.RuntimeException: exception while executing [select stream * from
orders]
at
org.apache.calcite.test.StreamTest.testStreamCancel(StreamTest.java:248)
Caused by: java.util.NoSuchElementException
at
org.apache.calcite.test.StreamTest.lambda$testStreamCancel$1(StreamTest.java:251)
at
org.apache.calcite.test.StreamTest.testStreamCancel(StreamTest.java:248)
{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (CALCITE-2496) EXTRACT function: MILLI/MICRO/NANOSECOND parts of a DATE must be zero
Sergey Nuyanzin created CALCITE-2496:
Summary: EXTRACT function: MILLI/MICRO/NANOSECOND parts of a DATE
must be zero
Key: CALCITE-2496
URL: https://issues.apache.org/jira/browse/CALCITE-2496
Project: Calcite
Issue Type: Bug
Components: core
Affects Versions: 1.17.0
Reporter: Sergey Nuyanzin
Assignee: Julian Hyde
There was already a similar issue CALCITE-2324 but I'm sorry I did not take
into account 3 time units. Now I want to cover them here. So all existing
Timeunits from {{org.apache.calcite.avatica.util.TimeUnit}} which are less than
a day will be covered
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (CALCITE-2447) Power sqlfunction fails with NoSuchMethodException
Sergey Nuyanzin created CALCITE-2447:
Summary: Power sqlfunction fails with NoSuchMethodException
Key: CALCITE-2447
URL: https://issues.apache.org/jira/browse/CALCITE-2447
Project: Calcite
Issue Type: Bug
Reporter: Sergey Nuyanzin
Assignee: Julian Hyde
{code}values power(0.5, 2);{code}
fails like {noformat}> java.sql.SQLException: Error while executing SQL "values
power(0.5, 2)": while resolving method 'power[class java.math.BigDecimal, int]'
in class class org.apache.calcite.runtime.SqlFunctions
> at org.apache.calcite.avatica.Helper.createException(Helper.java:56)
> at org.apache.calcite.avatica.Helper.createException(Helper.java:41)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:163)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeQuery(AvaticaStatement.java:227)
> at net.hydromatic.quidem.Quidem.checkResult(Quidem.java:322)
> at net.hydromatic.quidem.Quidem.access$2800(Quidem.java:54)
> at
> net.hydromatic.quidem.Quidem$ContextImpl.checkResult(Quidem.java:1747)
> at
> net.hydromatic.quidem.Quidem$CheckResultCommand.execute(Quidem.java:1078)
> at
> net.hydromatic.quidem.Quidem$CompositeCommand.execute(Quidem.java:1548)
> at net.hydromatic.quidem.Quidem.execute(Quidem.java:216)
> at org.apache.calcite.test.QuidemTest.checkRun(QuidemTest.java:175)
> at
> org.apache.calcite.test.CoreQuidemTest.testSqlMisc(CoreQuidemTest.java:67)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at org.apache.calcite.test.QuidemTest.test(QuidemTest.java:210)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.junit.runners.Suite.runChild(Suite.java:128)
> at org.junit.runners.Suite.runChild(Suite.java:27)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> Caused by: java.lang.RuntimeException: while resolving method 'power[class
> java.math.BigDecimal, int]' in class class
> org.apache.calcite.runtime.SqlFunctions
> at org.apache.calcite.linq4j.tree.Types.lookupMethod(Types.java:347)
> at org.apache.calcite.linq4j.tree.Expressions.call(Expressions.java:444)
> at
> org.apache.calcite.adapter.enumerable.RexImpTable$MethodNameImplementor.implement(RexImpTable.java:1876)
> at
> org.apache.calcite.adapter.enumerable.RexImpTable.implementCall(RexImpTable.java:982)
> at
> org.apache.calcite.adapter.enumerable.RexImpTable.implementNullSemantics(RexImpTable.java:952)
> at
> org.apache.calcite.adapter.enumerable.RexImpTable.implementNullSemantics0(RexImpTable.java:864)
> at
>
[jira] [Created] (CALCITE-2436) Build site under Windows
Sergey Nuyanzin created CALCITE-2436: Summary: Build site under Windows Key: CALCITE-2436 URL: https://issues.apache.org/jira/browse/CALCITE-2436 Project: Calcite Issue Type: Improvement Components: site Affects Versions: 1.17.0 Reporter: Sergey Nuyanzin Assignee: Julian Hyde There are manual steps for site [1] building under linux but there are no the similar for Windows. I passed through this and suggest to have in docs also. [1] https://github.com/apache/calcite/blob/master/site/README.md -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CALCITE-2414) CUME_DIST/PERCENT_RUNK window functions
Sergey Nuyanzin created CALCITE-2414: Summary: CUME_DIST/PERCENT_RUNK window functions Key: CALCITE-2414 URL: https://issues.apache.org/jira/browse/CALCITE-2414 Project: Calcite Issue Type: New Feature Reporter: Sergey Nuyanzin Assignee: Julian Hyde iCUME_DIST/PERCENT_RUNK are mentioned in Not Implemented section in http://calcite.apache.org/docs/reference.html At the same time they come with SQL:2003 Here there is a suggestion to implement it -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CALCITE-2412) Avatica/Calcite tests against Windows via Appveyor
Sergey Nuyanzin created CALCITE-2412:
Summary: Avatica/Calcite tests against Windows via Appveyor
Key: CALCITE-2412
URL: https://issues.apache.org/jira/browse/CALCITE-2412
Project: Calcite
Issue Type: Improvement
Components: build
Reporter: Sergey Nuyanzin
Assignee: Julian Hyde
Unfortunately Travis does not support Windows
https://github.com/travis-ci/travis-ci/issues/2104. There is a suggestion to
use Appveyor.
There are PRs attached both for Avatica and Calcite (i tried to make similar to
travis.yml)
The only different Java option for Calcite is {code}-Djna.nosys=true{code}
which is required to overcome
https://github.com/java-native-access/jna/issues/384 while Appveyor build.
Also unfortunately there is no option to have parallel build even between
projects (at least for free accounts) => to speed up the process I use only
java8
+ in case of Calcite do not use cache as Appveyor fails to save because of the
size - I guess it is also free account limitation
P.S. it should be noted that to have successful build on Appveyor CALCITE-2409
should be fixed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (CALCITE-2402) COVAR_POP/COVAR_SAMP/REGR_SXX/REGR_SYY do not work
Sergey Nuyanzin created CALCITE-2402:
Summary: COVAR_POP/COVAR_SAMP/REGR_SXX/REGR_SYY do not work
Key: CALCITE-2402
URL: https://issues.apache.org/jira/browse/CALCITE-2402
Project: Calcite
Issue Type: Bug
Components: core
Reporter: Sergey Nuyanzin
Assignee: Julian Hyde
Any query from {code:sql}
select covar_samp(empno, deptno) from emps;
select covar_pop(empno, deptno) from emps;
select regr_sxx(empno, deptno) from emps;
select regr_syy(empno, deptno) from emps;
{code}
fails (the trace is below)
As I understand the reason is not fully implementation (did not find any
convertlet for them e.g.).
>From my point of view I could fix this issue however I have a question:
How these function should be handled? As reducible functions (like STDDEV_POP,
STDDEV_SAMP, VAR_POP, VAR_SAMP) or as Rex operators in RexImpTable?
Please give some advice here
{noformat}0: jdbc:calcite:model=target/test-classes/mod> select
covar_samp(empno, deptno) from emps;
Error: Error while executing SQL "select covar_samp(empno, deptno) from emps":
Node [rel#123:Subset#2.ENUMERABLE.[]] could not be implemented; planner state:
Root: rel#123:Subset#2.ENUMERABLE.[]
Original rel:
LogicalAggregate(subset=[rel#123:Subset#2.ENUMERABLE.[]], group=[{}],
EXPR$0=[COVAR_SAMP($0, $1)]): rowcount = 10.0, cumulative cost = {11.25 rows,
0.0 cpu, 0.0 io}, id = 119
LogicalProject(subset=[rel#118:Subset#1.NONE.[]], EMPNO=[$0], DEPTNO=[$2]):
rowcount = 100.0, cumulative cost = {100.0 rows, 200.0 cpu, 0.0 io}, id = 117
LogicalTableScan(subset=[rel#116:Subset#0.NONE.[]], table=[[SALES, EMPS]]):
rowcount = 100.0, cumulative cost = {100.0 rows, 101.0 cpu, 0.0 io}, id = 103
Sets:
Set#0, type: RecordType(INTEGER EMPNO, VARCHAR NAME, INTEGER DEPTNO, VARCHAR
GENDER, VARCHAR CITY, INTEGER EMPID, INTEGER AGE, BOOLEAN SLACKER, BOOLEAN
MANAGER, DATE JOINEDAT)
rel#116:Subset#0.NONE.[], best=null, importance=0.7291
rel#103:LogicalTableScan.NONE.[](table=[SALES, EMPS]),
rowcount=100.0, cumulative cost={inf}
rel#128:Subset#0.ENUMERABLE.[], best=rel#135,
importance=0.36455
rel#133:EnumerableTableScan.ENUMERABLE.[](table=[SALES, EMPS]),
rowcount=100.0, cumulative cost={100.0 rows, 101.0 cpu, 0.0 io}
rel#135:EnumerableInterpreter.ENUMERABLE.[](input=rel#132:Subset#0.BINDABLE.[]),
rowcount=100.0, cumulative cost={51.0 rows, 51.01 cpu, 0.0 io}
rel#132:Subset#0.BINDABLE.[], best=rel#131,
importance=0.36455
rel#131:BindableTableScan.BINDABLE.[](table=[SALES, EMPS]),
rowcount=100.0, cumulative cost={1.0 rows, 1.01 cpu, 0.0 io}
Set#1, type: RecordType(INTEGER EMPNO, INTEGER DEPTNO)
rel#118:Subset#1.NONE.[], best=null, importance=0.81
rel#117:LogicalProject.NONE.[](input=rel#116:Subset#0.NONE.[],EMPNO=$0,DEPTNO=$2),
rowcount=100.0, cumulative cost={inf}
rel#125:Subset#1.ENUMERABLE.[], best=rel#134, importance=0.405
rel#134:EnumerableProject.ENUMERABLE.[](input=rel#128:Subset#0.ENUMERABLE.[],EMPNO=$0,DEPTNO=$2),
rowcount=100.0, cumulative cost={151.0 rows, 251.01 cpu, 0.0 io}
Set#2, type: RecordType(INTEGER EXPR$0)
rel#120:Subset#2.NONE.[], best=null, importance=0.9
rel#119:LogicalAggregate.NONE.[](input=rel#118:Subset#1.NONE.[],group={},EXPR$0=COVAR_SAMP($0,
$1)), rowcount=10.0, cumulative cost={inf}
rel#127:LogicalAggregate.NONE.[](input=rel#116:Subset#0.NONE.[],group={},EXPR$0=COVAR_SAMP($0,
$2)), rowcount=10.0, cumulative cost={inf}
rel#123:Subset#2.ENUMERABLE.[], best=null, importance=1.0
rel#124:AbstractConverter.ENUMERABLE.[](input=rel#120:Subset#2.NONE.[],convention=ENUMERABLE,sort=[]),
rowcount=10.0, cumulative cost={inf} (state=,code=0)
java.sql.SQLException: Error while executing SQL "select covar_samp(empno,
deptno) from emps": Node [rel#123:Subset#2.ENUMERABLE.[]] could not be
implemented; planner state:
Root: rel#123:Subset#2.ENUMERABLE.[]
Original rel:
LogicalAggregate(subset=[rel#123:Subset#2.ENUMERABLE.[]], group=[{}],
EXPR$0=[COVAR_SAMP($0, $1)]): rowcount = 10.0, cumulative cost = {11.25 rows,
0.0 cpu, 0.0 io}, id = 119
LogicalProject(subset=[rel#118:Subset#1.NONE.[]], EMPNO=[$0], DEPTNO=[$2]):
rowcount = 100.0, cumulative cost = {100.0 rows, 200.0 cpu, 0.0 io}, id = 117
LogicalTableScan(subset=[rel#116:Subset#0.NONE.[]], table=[[SALES, EMPS]]):
rowcount = 100.0, cumulative cost = {100.0 rows, 101.0 cpu, 0.0 io}, id = 103
Sets:
Set#0, type: RecordType(INTEGER EMPNO, VARCHAR NAME, INTEGER DEPTNO, VARCHAR
GENDER, VARCHAR CITY, INTEGER EMPID, INTEGER AGE, BOOLEAN SLACKER, BOOLEAN
MANAGER, DATE JOINEDAT)
rel#116:Subset#0.NONE.[], best=null, importance=0.7291
[jira] [Created] (CALCITE-2383) NTH_VALUE window function
Sergey Nuyanzin created CALCITE-2383: Summary: NTH_VALUE window function Key: CALCITE-2383 URL: https://issues.apache.org/jira/browse/CALCITE-2383 Project: Calcite Issue Type: Bug Reporter: Sergey Nuyanzin Assignee: Julian Hyde Hello Just realized that NTH_VALUE is mentioned in Not Implemented section in http://calcite.apache.org/docs/reference.html Here there is a suggestion to implement it -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CALCITE-2369) OsAdapterTest fails on windows
Sergey Nuyanzin created CALCITE-2369:
Summary: OsAdapterTest fails on windows
Key: CALCITE-2369
URL: https://issues.apache.org/jira/browse/CALCITE-2369
Project: Calcite
Issue Type: Bug
Reporter: Sergey Nuyanzin
Assignee: Julian Hyde
testDu and testDuFilterSortLimit are failing like
As I understand the reason is absence of _du_ in Windows. So just setting tests
in ignore in case of Windows (like it is already done for others in the same
OsAdapterTest) resolves the issue.
The trace from tests {noformat}java.lang.RuntimeException: With
materializationsEnabled=false, limit=0
at
org.apache.calcite.test.CalciteAssert.assertQuery(CalciteAssert.java:605)
at
org.apache.calcite.test.CalciteAssert$AssertQuery.returns(CalciteAssert.java:1351)
at
org.apache.calcite.test.CalciteAssert$AssertQuery.returns(CalciteAssert.java:1334)
at
org.apache.calcite.adapter.os.OsAdapterTest.testDu(OsAdapterTest.java:95)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
at
com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
at
com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:47)
at
com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242)
at
com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70)
Caused by: java.sql.SQLException: Error while executing SQL "select * from du":
while creating process: [du, -ak]
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.test.CalciteAssert.assertQuery(CalciteAssert.java:573)
... 25 more
Caused by: java.lang.RuntimeException: while creating process: [du, -ak]
at
org.apache.calcite.adapter.os.Processes$ProcessFactory.get(Processes.java:198)
at
org.apache.calcite.adapter.os.Processes$ProcessFactory.get(Processes.java:185)
at
org.apache.calcite.adapter.os.Processes$ProcessLinesEnumerator.enumerator(Processes.java:83)
at
org.apache.calcite.linq4j.EnumerableDefaults$15$1.(EnumerableDefaults.java:1893)
at
org.apache.calcite.linq4j.EnumerableDefaults$15.enumerator(EnumerableDefaults.java:1892)
at Baz$1$1.(Unknown Source)
at Baz$1.enumerator(Unknown Source)
at
org.apache.calcite.linq4j.AbstractEnumerable.iterator(AbstractEnumerable.java:33)
at org.apache.calcite.avatica.MetaImpl.createCursor(MetaImpl.java:90)
at
org.apache.calcite.avatica.AvaticaResultSet.execute(AvaticaResultSet.java:184)
at
org.apache.calcite.jdbc.CalciteResultSet.execute(CalciteResultSet.java:67)
at
org.apache.calcite.jdbc.CalciteResultSet.execute(CalciteResultSet.java:44)
at
org.apache.calcite.avatica.AvaticaConnection$1.execute(AvaticaConnection.java:667)
at
org.apache.calcite.jdbc.CalciteMetaImpl.prepareAndExecute(CalciteMetaImpl.java:627)
at
org.apache.calcite.avatica.AvaticaConnection.prepareAndExecuteInternal(AvaticaConnection.java:675)
at
org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:156)
[jira] [Created] (CALCITE-2365) Calcite is not compiled after bumping Avatica version to 1.12.0
Sergey Nuyanzin created CALCITE-2365: Summary: Calcite is not compiled after bumping Avatica version to 1.12.0 Key: CALCITE-2365 URL: https://issues.apache.org/jira/browse/CALCITE-2365 Project: Calcite Issue Type: Bug Reporter: Sergey Nuyanzin Assignee: Julian Hyde I guess the main reason is CALCITE-2219. tried to fix it here https://github.com/apache/calcite/compare/master...snuyanzin:CALCITE_AVATICA_12_UPDATE however there are at least 2 issues which are not fixed but only workarounded # _org.apache.calcite.test.LatticeTest#testGroupByEmpty3_ connection pool factory is used however 3 methods (explainContains, and 2 returnsUnordered ) lead to _org.apache.calcite.test.CalciteAssert#assertQuery_ which closes connections without paying attention if its from pool or not # the same test. mats updated in explainplan and execute => that is why finally size is 6. # strange but while only now failed test from core/src/test/resources/sql/misc.iq. Logically because of difference in data it must have failed earlier it would be nice to have some advice at least relating to first 2 bullets to fix it in a better way -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CALCITE-2324) extract seconds, minutes from date works not correct in some cases
Sergey Nuyanzin created CALCITE-2324:
Summary: extract seconds, minutes from date works not correct in
some cases
Key: CALCITE-2324
URL: https://issues.apache.org/jira/browse/CALCITE-2324
Project: Calcite
Issue Type: Bug
Reporter: Sergey Nuyanzin
Assignee: Julian Hyde
While working on tests for CALCITE-2303 faced with the next issue (do not fix
within 2303 as the fix does not need avatica update while 2303 does)
{code:sql}select extract(second from date '2008-02-23');{sql} returns 13
I guess the issue is known because of the test is present in
_org.apache.calcite.sql.test.SqlOperatorBaseTest#testExtractDate_ within _TODO_
block and with the comment {code:java} if (TODO) {
// Looks like there is a bug in current execution code which returns 13
// instead of 0
tester.checkScalar(
"extract(second from date '2008-2-23')",
"0",
"BIGINT NOT NULL");
}{code}
I deep dive into it and realized that the problem is that in case of DATE
extract works with days + in case of seconds, minute, hours there will be used
_org.apache.calcite.adapter.enumerable.RexImpTable#getFactor_. And finally the
result is
{noformat}number_of_days % 6 / 1000L //for extract seconds{noformat}
{noformat}number_of_days % 36 / 1000L //for extract minutes{noformat}
and yes {code}select extract(minute from date '1700-01-01');{code} returns -1
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (CALCITE-2318) NumberFormatException while Sqlline start
Sergey Nuyanzin created CALCITE-2318:
Summary: NumberFormatException while Sqlline start
Key: CALCITE-2318
URL: https://issues.apache.org/jira/browse/CALCITE-2318
Project: Calcite
Issue Type: Bug
Environment: {noformat}
[serg@localhost ~]$ uname -a
Linux localhost.localdomain 4.16.7-300.fc28.x86_64 #1 SMP Wed May 2 20:09:13
UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
[serg@localhost ~]$ infocmp -V
ncurses 6.1.20180224
{noformat}
Reporter: Sergey Nuyanzin
Assignee: Julian Hyde
Hello
looks like known issue here https://github.com/jline/jline2/issues/281
IMHO jline2version update needed to have it fixed
to reproduce just run sqlline
{noformat}
[serg@localhost csv]$ ./sqlline
[ERROR] Failed to construct terminal; falling back to unsupported
java.lang.NumberFormatException: For input string: "0x100"
at
java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
at java.lang.Integer.parseInt(Integer.java:580)
at java.lang.Integer.valueOf(Integer.java:766)
at jline.internal.InfoCmp.parseInfoCmp(InfoCmp.java:59)
at jline.UnixTerminal.parseInfoCmp(UnixTerminal.java:242)
at jline.UnixTerminal.(UnixTerminal.java:65)
at jline.UnixTerminal.(UnixTerminal.java:50)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
at java.lang.Class.newInstance(Class.java:442)
at jline.TerminalFactory.getFlavor(TerminalFactory.java:211)
at jline.TerminalFactory.create(TerminalFactory.java:102)
at jline.TerminalFactory.get(TerminalFactory.java:186)
at jline.TerminalFactory.get(TerminalFactory.java:192)
at sqlline.SqlLineOpts.(SqlLineOpts.java:45)
at sqlline.SqlLine.(SqlLine.java:54)
at sqlline.SqlLine.start(SqlLine.java:372)
at sqlline.SqlLine.main(SqlLine.java:265)
[ERROR] Failed to construct terminal; falling back to unsupported
java.lang.NumberFormatException: For input string: "0x100"
at
java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
at java.lang.Integer.parseInt(Integer.java:580)
at java.lang.Integer.valueOf(Integer.java:766)
at jline.internal.InfoCmp.parseInfoCmp(InfoCmp.java:59)
at jline.UnixTerminal.parseInfoCmp(UnixTerminal.java:242)
at jline.UnixTerminal.(UnixTerminal.java:65)
at jline.UnixTerminal.(UnixTerminal.java:50)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
at java.lang.Class.newInstance(Class.java:442)
at jline.TerminalFactory.getFlavor(TerminalFactory.java:211)
at jline.TerminalFactory.create(TerminalFactory.java:102)
at jline.TerminalFactory.create(TerminalFactory.java:51)
at sqlline.SqlLine.getConsoleReader(SqlLine.java:705)
at sqlline.SqlLine.begin(SqlLine.java:639)
at sqlline.SqlLine.start(SqlLine.java:373)
at sqlline.SqlLine.main(SqlLine.java:265)
{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (CALCITE-2303) Extract for time unit: DECADE not supported!
Sergey Nuyanzin created CALCITE-2303:
Summary: Extract for time unit: DECADE not supported!
Key: CALCITE-2303
URL: https://issues.apache.org/jira/browse/CALCITE-2303
Project: Calcite
Issue Type: Bug
Reporter: Sergey Nuyanzin
Assignee: Julian Hyde
Here CALCITE-1177 were supported new units
however such test
{code:java}
@Test public void testDecadeFunction() throws Exception {
ExpressionChecker checker = new ExpressionChecker()
.addExpr("EXTRACT(DECADE FROM ts)", 199L)
;
checker.buildRunAndCheck();
}
{code}
failed like
Extract for time unit: DECADE not supported!
{panel}
SQL:>
SELECT EXTRACT(DECADE FROM ts) FROM PCOLLECTION
May 08, 2018 1:34:58 PM
org.apache.beam.sdk.extensions.sql.impl.planner.BeamQueryPlanner
validateAndConvert
INFO: SQL:
SELECT EXTRACT(DECADE FROM `PCOLLECTION`.`ts`)
FROM `PCOLLECTION` AS `PCOLLECTION`
May 08, 2018 1:34:58 PM
org.apache.beam.sdk.extensions.sql.impl.planner.BeamQueryPlanner
convertToBeamRel
INFO: SQLPlan>
LogicalProject(EXPR$0=[EXTRACT(FLAG(DECADE), $0)])
BeamIOSourceRel(table=[[PCOLLECTION]])
java.lang.RuntimeException:
org.apache.beam.sdk.Pipeline$PipelineExecutionException:
java.lang.UnsupportedOperationException: Extract for time unit: DECADE not
supported!
at
org.apache.beam.sdk.extensions.sql.integrationtest.BeamSqlBuiltinFunctionsIntegrationTestBase$ExpressionChecker.buildRunAndCheck(BeamSqlBuiltinFunctionsIntegrationTestBase.java:167)
at
org.apache.beam.sdk.extensions.sql.integrationtest.BeamSqlDateFunctionsIntegrationTest.testDecadeFunction(BeamSqlDateFunctionsIntegrationTest.java:66)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at
org.apache.beam.sdk.testing.TestPipeline$1.evaluate(TestPipeline.java:317)
at org.junit.rules.RunRules.evaluate(RunRules.java:20)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
at
com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
at
com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:47)
at
com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242)
at
com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70)
Caused by: org.apache.beam.sdk.Pipeline$PipelineExecutionException:
java.lang.UnsupportedOperationException: Extract for time unit: DECADE not
supported!
at
org.apache.beam.runners.direct.DirectRunner$DirectPipelineResult.waitUntilFinish(DirectRunner.java:349)
at
org.apache.beam.runners.direct.DirectRunner$DirectPipelineResult.waitUntilFinish(DirectRunner.java:319)
at
org.apache.beam.runners.direct.DirectRunner.run(DirectRunner.java:210)
at org.apache.beam.runners.direct.DirectRunner.run(DirectRunner.java:66)
at org.apache.beam.sdk.Pipeline.run(Pipeline.java:311)
at org.apache.beam.sdk.testing.TestPipeline.run(TestPipeline.java:346)
at org.apache.beam.sdk.testing.TestPipeline.run(TestPipeline.java:328)
at
org.apache.beam.sdk.extensions.sql.integrationtest.BeamSqlBuiltinFunctionsIntegrationTestBase$ExpressionChecker.buildRunAndCheck(BeamSqlBuiltinFunctionsIntegrationTestBase.java:165)
... 25 more
Caused by: java.lang.UnsupportedOperationException: Extract for time unit:
DECADE not supported!
at
