[jira] [Commented] (CALCITE-6112) Use indelible release tags
[
https://issues.apache.org/jira/browse/CALCITE-6112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17785751#comment-17785751
]
Vladimir Sitnikov commented on CALCITE-6112:
> inedible
I should have written uneditable :D
I just tried git push -f gh
2326cf8dc97f473d0efa2b0e4883fef87a40746b:calcite-1.28.0, and it worked.
{noformat}
To https://github.com/apache/calcite.git
+ 18b044d72...2326cf8dc 2326cf8dc97f473d0efa2b0e4883fef87a40746b ->
calcite-1.28.0 (forced update)
{noformat}
Then I reverted with git push -f gh
dec167ac18272c0cd8be477d6b162d7a31a62114:calcite-1.28.0
> Should we keep tagging as vX.Y.Z, supplement it with a rel/vX.Y.Z tag, or
> eschew the vX.Y.Z tag completely
You might probably ask infra to make rel/... customizable via .asf.yaml as well.
> Use indelible release tags
> --
>
> Key: CALCITE-6112
> URL: https://issues.apache.org/jira/browse/CALCITE-6112
> Project: Calcite
> Issue Type: Improvement
>Reporter: Vladimir Sitnikov
>Priority: Major
>
> The ASF has recommended using indelible Git tags (rel/...) since 2016:
> [https://lists.apache.org/thread/szbtzk0048ppx1zvzljbrq7by2mt1zvs]
> It turns out that has broken in Calcite since 2020:
> [https://github.com/apache/calcite/commit/2e30293af7373b6c5fbcc5fa6505b49df2fba000]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6112) Use inedible release tags
[ https://issues.apache.org/jira/browse/CALCITE-6112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Sitnikov updated CALCITE-6112: --- Description: The ASF has recommended using inedible Git tags (rel/...) since 2016: https://lists.apache.org/thread/szbtzk0048ppx1zvzljbrq7by2mt1zvs It turns out that has broken in Calcite since 2020: https://github.com/apache/calcite/commit/2e30293af7373b6c5fbcc5fa6505b49df2fba000 was: The ASF has recommended using inedible Git tags since 2016: https://lists.apache.org/thread/szbtzk0048ppx1zvzljbrq7by2mt1zvs It turns out that has broken in Calcite since 2020: https://github.com/apache/calcite/commit/2e30293af7373b6c5fbcc5fa6505b49df2fba000 > Use inedible release tags > - > > Key: CALCITE-6112 > URL: https://issues.apache.org/jira/browse/CALCITE-6112 > Project: Calcite > Issue Type: Improvement >Reporter: Vladimir Sitnikov >Priority: Major > > The ASF has recommended using inedible Git tags (rel/...) since 2016: > https://lists.apache.org/thread/szbtzk0048ppx1zvzljbrq7by2mt1zvs > It turns out that has broken in Calcite since 2020: > https://github.com/apache/calcite/commit/2e30293af7373b6c5fbcc5fa6505b49df2fba000 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CALCITE-6112) Use inedible release tags
Vladimir Sitnikov created CALCITE-6112: -- Summary: Use inedible release tags Key: CALCITE-6112 URL: https://issues.apache.org/jira/browse/CALCITE-6112 Project: Calcite Issue Type: Improvement Reporter: Vladimir Sitnikov The ASF has recommended using inedible Git tags since 2016: https://lists.apache.org/thread/szbtzk0048ppx1zvzljbrq7by2mt1zvs It turns out that has broken in Calcite since 2020: https://github.com/apache/calcite/commit/2e30293af7373b6c5fbcc5fa6505b49df2fba000 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CALCITE-2541) Calcite core is vulnerable to exposing through OSGI
[
https://issues.apache.org/jira/browse/CALCITE-2541?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17785278#comment-17785278
]
Vladimir Sitnikov commented on CALCITE-2541:
I believe a better way would be convincing Janino to use ServiceLoader API
instead of custom resources:
https://github.com/janino-compiler/janino/issues/209
> Calcite core is vulnerable to exposing through OSGI
> ---
>
> Key: CALCITE-2541
> URL: https://issues.apache.org/jira/browse/CALCITE-2541
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.17.0
>Reporter: Piotr Bojko
>Priority: Major
>
> When exposing connection created by Calcite through OSGI to another bundle -
> class not found it thrown everywhere from code as following:
> {code:java}
> ICompilerFactory compilerFactory;
> try {
> compilerFactory = CompilerFactoryFactory.getDefaultCompilerFactory();
> } catch (Exception e) {
> throw new IllegalStateException(
> "Unable to instantiate java compiler", e);
> }
> {code}
> This is because org.codehaus.commons.compiler.CompilerFactoryFactory uses
> classloader from current thread, where in OSGI exposed to different bundles
> thread classloader may not reach valid janino or
> org.codehaus.commons.compiler, appropriate for Calcite version (or at all).
> I would suggest changing the mentioned code with additional fallback:
>
> {code:java}
> ICompilerFactory compilerFactory;
> try {
> compilerFactory = CompilerFactoryFactory.getDefaultCompilerFactory();
> } catch (ClassNotFoundException e) {
> compilerFactory = new org.codehaus.janino.CompilerFactory();
> } catch (Exception e) {
> throw new IllegalStateException(
> "Unable to instantiate java compiler", e);
> }
> {code}
> Change in:
> * EnumerableInterpretable.getBindable(ClassDeclaration, String, int)
> * JaninoRexCompiler.getScalar(ClassDeclaration, String)
> * JaninoRelMetadataProvider.compile(String, String, MetadataDef,
> List)
> This should clear the way between calcite and an osgi world :)
> When accepted I will make a pull request.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6019) Excessive cast when UDF receives nullable JavaType
[
https://issues.apache.org/jira/browse/CALCITE-6019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Sitnikov updated CALCITE-6019:
---
Affects Version/s: 1.35.0
1.27.0
> Excessive cast when UDF receives nullable JavaType
> --
>
> Key: CALCITE-6019
> URL: https://issues.apache.org/jira/browse/CALCITE-6019
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.27.0, 1.35.0
>Reporter: Vladimir Sitnikov
>Priority: Major
>
> See CALCITE-6018, however, CALCITE-6018 is about the "ability to declare
> nullable, non-optional parameter" while this issue is about the excessive NOT
> NULL cast.
> Just in case, adding {{@Strict}} to {{retainedSize}} does not make CAST go
> away.
> It causes weird "cast(... NOT NULL)" even though my {{retainedSize}} function
> processes null just fine.
> {noformat}
> expr#4=[TO_HEAP_REFERENCE($t3)],
> expr#5=[CAST($t4):JavaType(class java.lang.Object) NOT NULL],
> expr#6=[retainedSize($t5)],
> {noformat}
> {{TO_HEAP_REFERENCE}} returns nullable {{HeapReference}} (Java class):
> [https://github.com/vlsi/mat-calcite-plugin/blob/4d4aa2284eeec69bc51da0c2e769ded06ef9ab97/MatCalcitePlugin/src/com/github/vlsi/mat/calcite/schema/objects/HeapOperatorTable.java#L27-L28]
> {{retainedSize}} receives a single (nullable) {{Object}} parameter, and it is
> declared as
> [https://github.com/vlsi/mat-calcite-plugin/blob/4d4aa2284eeec69bc51da0c2e769ded06ef9ab97/MatCalcitePlugin/src/com/github/vlsi/mat/calcite/functions/HeapFunctions.java#L129]
> I tried adding {{@Parameter(optional=true)}} to {{{}retainedSize{}}}, and it
> does not eliminate {{NOT NULL}} part of the cast.
>
> My expectation is that NOT NULL must not be there as both return type and the
> parameter type are nullable. It might be cast should not be there as well.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CALCITE-6019) Excessive cast when UDF receives nullable JavaType
Vladimir Sitnikov created CALCITE-6019:
--
Summary: Excessive cast when UDF receives nullable JavaType
Key: CALCITE-6019
URL: https://issues.apache.org/jira/browse/CALCITE-6019
Project: Calcite
Issue Type: Bug
Components: core
Reporter: Vladimir Sitnikov
See CALCITE-6018, however, CALCITE-6018 is about the "ability to declare
nullable, non-optional parameter" while this issue is about the excessive NOT
NULL cast.
Just in case, adding {{@Strict}} to {{retainedSize}} does not make CAST go away.
It causes weird "cast(... NOT NULL)" even though my {{retainedSize}} function
processes null just fine.
{noformat}
expr#4=[TO_HEAP_REFERENCE($t3)],
expr#5=[CAST($t4):JavaType(class java.lang.Object) NOT NULL],
expr#6=[retainedSize($t5)],
{noformat}
{{TO_HEAP_REFERENCE}} returns nullable {{HeapReference}} (Java class):
[https://github.com/vlsi/mat-calcite-plugin/blob/4d4aa2284eeec69bc51da0c2e769ded06ef9ab97/MatCalcitePlugin/src/com/github/vlsi/mat/calcite/schema/objects/HeapOperatorTable.java#L27-L28]
{{retainedSize}} receives a single (nullable) {{Object}} parameter, and it is
declared as
[https://github.com/vlsi/mat-calcite-plugin/blob/4d4aa2284eeec69bc51da0c2e769ded06ef9ab97/MatCalcitePlugin/src/com/github/vlsi/mat/calcite/functions/HeapFunctions.java#L129]
I tried adding {{@Parameter(optional=true)}} to {{{}retainedSize{}}}, and it
does not eliminate {{NOT NULL}} part of the cast.
My expectation is that NOT NULL must not be there as both return type and the
parameter type are nullable. It might be cast should not be there as well.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6018) Support nullable parameters in UDFs
[
https://issues.apache.org/jira/browse/CALCITE-6018?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Sitnikov updated CALCITE-6018:
---
Description:
Currently Calcite treats almost all the parameters as non-nullable. There's
{{@Parameter(optional=true)}}, however, it mixes "optionality" vs "nullability".
In other words, I would like to have nullable, non-optional parameters in UDFs.
For instance, Calcite could pick up nullness information from annotations (e.g.
`@Nullable`). For instance, Kotlin compiler generates the annotations
automatically, so I think supporting more-or-less standard tools like jspecify
and checkerframework should be preferred over Calcite-only annotations.
---
Sample usage: {{retainedSize}} is declared as
https://github.com/vlsi/mat-calcite-plugin/blob/4d4aa2284eeec69bc51da0c2e769ded06ef9ab97/MatCalcitePlugin/src/com/github/vlsi/mat/calcite/functions/HeapFunctions.java#L129,
and I want to declare that {{retainedSize}} is fine to receive {{null}}
parameter.
was:
Currently Calcite treats almost all the parameters as non-nullable. There's
{{@Parameter(optional=true)}}, however, it mixes "optionality" vs "nullability".
It causes weird "cast(... NOT NULL)" even though my function processes null
just fine.
See example in CALCITE-6012.
{noformat}
expr#4=[TO_HEAP_REFERENCE($t3)],
expr#5=[CAST($t4):JavaType(class java.lang.Object) NOT NULL],
expr#6=[retainedSize($t5)],
{noformat}
{{TO_HEAP_REFERENCE}} returns nullable {{HeapReference}} (Java class):
https://github.com/vlsi/mat-calcite-plugin/blob/4d4aa2284eeec69bc51da0c2e769ded06ef9ab97/MatCalcitePlugin/src/com/github/vlsi/mat/calcite/schema/objects/HeapOperatorTable.java#L27-L28
{{retainedSize}} is declared as
https://github.com/vlsi/mat-calcite-plugin/blob/4d4aa2284eeec69bc51da0c2e769ded06ef9ab97/MatCalcitePlugin/src/com/github/vlsi/mat/calcite/functions/HeapFunctions.java#L129
I tried adding {{@Parameter(optional=true)}} to {{retainedSize}}, and it does
not remove the cast. It does not eliminate {{NOT NULL}} part of the cast.
---
In any case, I think it is not quite right to mix nullaness and optionally
concepts, and Calcite should inter nullness from nullability annotations.
> Support nullable parameters in UDFs
> ---
>
> Key: CALCITE-6018
> URL: https://issues.apache.org/jira/browse/CALCITE-6018
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.35.0
>Reporter: Vladimir Sitnikov
>Priority: Major
>
> Currently Calcite treats almost all the parameters as non-nullable. There's
> {{@Parameter(optional=true)}}, however, it mixes "optionality" vs
> "nullability".
> In other words, I would like to have nullable, non-optional parameters in
> UDFs.
> For instance, Calcite could pick up nullness information from annotations
> (e.g. `@Nullable`). For instance, Kotlin compiler generates the annotations
> automatically, so I think supporting more-or-less standard tools like
> jspecify and checkerframework should be preferred over Calcite-only
> annotations.
> ---
> Sample usage: {{retainedSize}} is declared as
> https://github.com/vlsi/mat-calcite-plugin/blob/4d4aa2284eeec69bc51da0c2e769ded06ef9ab97/MatCalcitePlugin/src/com/github/vlsi/mat/calcite/functions/HeapFunctions.java#L129,
> and I want to declare that {{retainedSize}} is fine to receive {{null}}
> parameter.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-6018) Support nullable parameters in UDFs
[
https://issues.apache.org/jira/browse/CALCITE-6018?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17767390#comment-17767390
]
Vladimir Sitnikov commented on CALCITE-6018:
Just in case, {{@Parameter(optional=true}} does make
{{ScalarFunctionImpl.functions}} produce function with "nullable (and
optional)" parameter. So it looks like the artificial cast is yet another issue.
> Support nullable parameters in UDFs
> ---
>
> Key: CALCITE-6018
> URL: https://issues.apache.org/jira/browse/CALCITE-6018
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.35.0
>Reporter: Vladimir Sitnikov
>Priority: Major
>
> Currently Calcite treats almost all the parameters as non-nullable. There's
> {{@Parameter(optional=true)}}, however, it mixes "optionality" vs
> "nullability".
> It causes weird "cast(... NOT NULL)" even though my function processes null
> just fine.
> See example in CALCITE-6012.
> {noformat}
> expr#4=[TO_HEAP_REFERENCE($t3)],
> expr#5=[CAST($t4):JavaType(class java.lang.Object) NOT NULL],
> expr#6=[retainedSize($t5)],
> {noformat}
> {{TO_HEAP_REFERENCE}} returns nullable {{HeapReference}} (Java class):
> https://github.com/vlsi/mat-calcite-plugin/blob/4d4aa2284eeec69bc51da0c2e769ded06ef9ab97/MatCalcitePlugin/src/com/github/vlsi/mat/calcite/schema/objects/HeapOperatorTable.java#L27-L28
> {{retainedSize}} is declared as
> https://github.com/vlsi/mat-calcite-plugin/blob/4d4aa2284eeec69bc51da0c2e769ded06ef9ab97/MatCalcitePlugin/src/com/github/vlsi/mat/calcite/functions/HeapFunctions.java#L129
> I tried adding {{@Parameter(optional=true)}} to {{retainedSize}}, and it does
> not remove the cast. It does not eliminate {{NOT NULL}} part of the cast.
> ---
> In any case, I think it is not quite right to mix nullaness and optionally
> concepts, and Calcite should inter nullness from nullability annotations.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CALCITE-6018) Support nullable parameters in UDFs
Vladimir Sitnikov created CALCITE-6018:
--
Summary: Support nullable parameters in UDFs
Key: CALCITE-6018
URL: https://issues.apache.org/jira/browse/CALCITE-6018
Project: Calcite
Issue Type: Improvement
Components: core
Reporter: Vladimir Sitnikov
Currently Calcite treats almost all the parameters as non-nullable. There's
{{@Parameter(optional=true)}}, however, it mixes "optionality" vs "nullability".
It causes weird "cast(... NOT NULL)" even though my function processes null
just fine.
See example in CALCITE-6012.
{noformat}
expr#4=[TO_HEAP_REFERENCE($t3)],
expr#5=[CAST($t4):JavaType(class java.lang.Object) NOT NULL],
expr#6=[retainedSize($t5)],
{noformat}
{{TO_HEAP_REFERENCE}} returns nullable {{HeapReference}} (Java class):
https://github.com/vlsi/mat-calcite-plugin/blob/4d4aa2284eeec69bc51da0c2e769ded06ef9ab97/MatCalcitePlugin/src/com/github/vlsi/mat/calcite/schema/objects/HeapOperatorTable.java#L27-L28
{{retainedSize}} is declared as
https://github.com/vlsi/mat-calcite-plugin/blob/4d4aa2284eeec69bc51da0c2e769ded06ef9ab97/MatCalcitePlugin/src/com/github/vlsi/mat/calcite/functions/HeapFunctions.java#L129
I tried adding {{@Parameter(optional=true)}} to {{retainedSize}}, and it does
not remove the cast. It does not eliminate {{NOT NULL}} part of the cast.
---
In any case, I think it is not quite right to mix nullaness and optionally
concepts, and Calcite should inter nullness from nullability annotations.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6018) Support nullable parameters in UDFs
[
https://issues.apache.org/jira/browse/CALCITE-6018?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Sitnikov updated CALCITE-6018:
---
Affects Version/s: 1.35.0
> Support nullable parameters in UDFs
> ---
>
> Key: CALCITE-6018
> URL: https://issues.apache.org/jira/browse/CALCITE-6018
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.35.0
>Reporter: Vladimir Sitnikov
>Priority: Major
>
> Currently Calcite treats almost all the parameters as non-nullable. There's
> {{@Parameter(optional=true)}}, however, it mixes "optionality" vs
> "nullability".
> It causes weird "cast(... NOT NULL)" even though my function processes null
> just fine.
> See example in CALCITE-6012.
> {noformat}
> expr#4=[TO_HEAP_REFERENCE($t3)],
> expr#5=[CAST($t4):JavaType(class java.lang.Object) NOT NULL],
> expr#6=[retainedSize($t5)],
> {noformat}
> {{TO_HEAP_REFERENCE}} returns nullable {{HeapReference}} (Java class):
> https://github.com/vlsi/mat-calcite-plugin/blob/4d4aa2284eeec69bc51da0c2e769ded06ef9ab97/MatCalcitePlugin/src/com/github/vlsi/mat/calcite/schema/objects/HeapOperatorTable.java#L27-L28
> {{retainedSize}} is declared as
> https://github.com/vlsi/mat-calcite-plugin/blob/4d4aa2284eeec69bc51da0c2e769ded06ef9ab97/MatCalcitePlugin/src/com/github/vlsi/mat/calcite/functions/HeapFunctions.java#L129
> I tried adding {{@Parameter(optional=true)}} to {{retainedSize}}, and it does
> not remove the cast. It does not eliminate {{NOT NULL}} part of the cast.
> ---
> In any case, I think it is not quite right to mix nullaness and optionally
> concepts, and Calcite should inter nullness from nullability annotations.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-5960) CAST failed if SqlTypeFamily of targetType is NULL
[
https://issues.apache.org/jira/browse/CALCITE-5960?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17767370#comment-17767370
]
Vladimir Sitnikov commented on CALCITE-5960:
Currently Calcite has no tests with SqlUserDefinedFunction, so at least one
would be great
> CAST failed if SqlTypeFamily of targetType is NULL
> --
>
> Key: CALCITE-5960
> URL: https://issues.apache.org/jira/browse/CALCITE-5960
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.35.0
>Reporter: Ran Tao
>Assignee: Ran Tao
>Priority: Major
>
> current RexToLixTranslator#translateCast#scaleIntervalToNumber will scale
> interval to number. but it throws NPE when family is null.
> It will cause some types such as row type (family is null) raise a NPE.
> e.g. If we call
> {code:java}
> CAST(row(1, 2) as row(a integer, b tinyint)){code}
> it will cause NPE:
> {noformat}
> java.sql.SQLException: Error while executing SQL "values (CAST(row(1, 2) as
> row(a integer, b tinyint)))": Unable to implement
> EnumerableCalc(expr#0=[\{inputs}], expr#1=[1], expr#2=[2], expr#3=[ROW($t1,
> $t2)], expr#4=[CAST($t3):RecordType(INTEGER NOT NULL A, TINYINT NOT NULL B)
> NOT NULL], EXPR$0=[$t4]): rowcount = 1.0, cumulative cost = \{2.0 rows, 7.0
> cpu, 0.0 io}, id = 20
> EnumerableValues(tuples=[[\{ 0 }]]): rowcount = 1.0, cumulative cost =
> \{1.0 rows, 1.0 cpu, 0.0 io}, id = 13
> 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:164)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeQuery(AvaticaStatement.java:228)
> at
> org.apache.calcite.test.SqlOperatorTest$TesterImpl.check(SqlOperatorTest.java:12684)
> at org.apache.calcite.sql.test.SqlTester.check(SqlTester.java:160)
> at
> org.apache.calcite.test.SqlOperatorFixtureImpl.lambda$checkScalar$2(SqlOperatorFixtureImpl.java:224)
> at
> org.apache.calcite.sql.test.AbstractSqlTester.forEachQuery(AbstractSqlTester.java:446)
> at
> org.apache.calcite.test.SqlOperatorFixtureImpl.checkScalar(SqlOperatorFixtureImpl.java:223)
> at
> org.apache.calcite.sql.test.SqlOperatorFixture.checkScalar(SqlOperatorFixture.java:238)
> at
> org.apache.calcite.test.SqlOperatorTest.testCastRow(SqlOperatorTest.java:6103)
> 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.platform.commons.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:727)
> at
> org.junit.jupiter.engine.execution.MethodInvocation.proceed(MethodInvocation.java:60)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain$ValidatingInvocation.proceed(InvocationInterceptorChain.java:131)
> at
> org.junit.jupiter.engine.extension.TimeoutExtension.intercept(TimeoutExtension.java:156)
> at
> org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestableMethod(TimeoutExtension.java:147)
> at
> org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestMethod(TimeoutExtension.java:86)
> at
> org.junit.jupiter.engine.execution.InterceptingExecutableInvoker$ReflectiveInterceptorCall.lambda$ofVoidMethod$0(InterceptingExecutableInvoker.java:103)
> at
> org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.lambda$invoke$0(InterceptingExecutableInvoker.java:93)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain$InterceptedInvocation.proceed(InvocationInterceptorChain.java:106)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain.proceed(InvocationInterceptorChain.java:64)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain.chainAndInvoke(InvocationInterceptorChain.java:45)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain.invoke(InvocationInterceptorChain.java:37)
> at
> org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.invoke(InterceptingExecutableInvoker.java:92)
> at
> org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.invoke(InterceptingExecutableInvoker.java:86)
> at
> org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.lambda$invokeTestMethod$7(TestMethodTestDescriptor.java:217)
> at
> org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
> at
> org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.invokeTestMethod(TestMethodTestDescriptor.java:213)
> at
>
[jira] [Created] (CALCITE-6012) CAST($t4):JavaType(class java.lang.Object) NOT NULL causes NPE since 1.27
Vladimir Sitnikov created CALCITE-6012:
--
Summary: CAST($t4):JavaType(class java.lang.Object) NOT NULL
causes NPE since 1.27
Key: CALCITE-6012
URL: https://issues.apache.org/jira/browse/CALCITE-6012
Project: Calcite
Issue Type: Improvement
Components: core
Affects Versions: 1.27.0
Reporter: Vladimir Sitnikov
The commit that introduced the regression is
https://github.com/apache/calcite/commit/e819b4611e883c54708a75f6856300462c92b8ae
Here's UDF declaration:
https://github.com/vlsi/mat-calcite-plugin/blob/4d4aa2284eeec69bc51da0c2e769ded06ef9ab97/MatCalcitePlugin/src/com/github/vlsi/mat/calcite/schema/objects/HeapOperatorTable.java#L24-L36
Problematic stacktrace is below.
Frankly speaking, it is strange to see scaleIntervalToNumber in the stacktrace
as the types have nothing to do with intervals.
{noformat}
Caused by: java.lang.IllegalStateException: Unable to implement
EnumerableAggregate(group=[{}], retained_size=[SUM($0)]): rowcount = 8.0,
cumulative cost = {169.1038146973 rows, 721.0 cpu, 0.0 io}, id = 52
EnumerableCalc(expr#0=[{inputs}], expr#1=[0], expr#2=[GET_SNAPSHOT($t1)],
expr#3=[GET_IOBJECT($t2, $t0)], expr#4=[TO_HEAP_REFERENCE($t3)],
expr#5=[CAST($t4):JavaType(class java.lang.Object) NOT NULL],
expr#6=[retainedSize($t5)], $f0=[$t6]): rowcount = 80.0, cumulative cost =
{160.0 rows, 721.0 cpu, 0.0 io}, id = 54
EnumerableTableScan(table=[[HEAP, java, util, $ids$:HashMap]]): rowcount =
80.0, cumulative cost = {80.0 rows, 81.0 cpu, 0.0 io}, id = 36
at
org.apache.calcite.adapter.enumerable.EnumerableRelImplementor.implementRoot(EnumerableRelImplementor.java:111)
at
org.apache.calcite.adapter.enumerable.EnumerableInterpretable.toBindable(EnumerableInterpretable.java:112)
at
org.apache.calcite.prepare.CalcitePrepareImpl$CalcitePreparingStmt.implement(CalcitePrepareImpl.java:1124)
at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:311)
at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:208)
at
org.apache.calcite.prepare.CalcitePrepareImpl.prepare2_(CalcitePrepareImpl.java:642)
at
org.apache.calcite.prepare.CalcitePrepareImpl.prepare_(CalcitePrepareImpl.java:508)
at
org.apache.calcite.prepare.CalcitePrepareImpl.prepareSql(CalcitePrepareImpl.java:478)
at
org.apache.calcite.jdbc.CalciteConnectionImpl.parseQuery(CalciteConnectionImpl.java:231)
at
org.apache.calcite.jdbc.CalciteConnectionImpl.prepareStatement_(CalciteConnectionImpl.java:213)
... 64 more
Suppressed: java.lang.NullPointerException
at
org.apache.calcite.adapter.enumerable.RexToLixTranslator.scaleIntervalToNumber(RexToLixTranslator.java:936)
at
org.apache.calcite.adapter.enumerable.RexToLixTranslator.translateCast(RexToLixTranslator.java:592)
at
org.apache.calcite.adapter.enumerable.RexImpTable$CastImplementor.implementSafe(RexImpTable.java:2481)
at
org.apache.calcite.adapter.enumerable.RexImpTable$AbstractRexCallImplementor.genValueStatement(RexImpTable.java:2937)
at
org.apache.calcite.adapter.enumerable.RexImpTable$AbstractRexCallImplementor.implement(RexImpTable.java:2902)
at
org.apache.calcite.adapter.enumerable.RexToLixTranslator.visitCall(RexToLixTranslator.java:1134)
at
org.apache.calcite.adapter.enumerable.RexToLixTranslator.visitCall(RexToLixTranslator.java:90)
at org.apache.calcite.rex.RexCall.accept(RexCall.java:175)
at
org.apache.calcite.adapter.enumerable.RexToLixTranslator.visitLocalRef(RexToLixTranslator.java:1018)
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.implementCallOperand(RexToLixTranslator.java:1143)
at
org.apache.calcite.adapter.enumerable.RexToLixTranslator.visitCall(RexToLixTranslator.java:1130)
at
org.apache.calcite.adapter.enumerable.RexToLixTranslator.visitCall(RexToLixTranslator.java:90)
at org.apache.calcite.rex.RexCall.accept(RexCall.java:175)
at
org.apache.calcite.adapter.enumerable.RexToLixTranslator.visitLocalRef(RexToLixTranslator.java:1018)
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)
[jira] [Updated] (CALCITE-6010) RelRule.Config requires too much ceremony for trivial cases
[
https://issues.apache.org/jira/browse/CALCITE-6010?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Sitnikov updated CALCITE-6010:
---
Description:
It takes a lot to implement RelRule.Config even for trivial cases when no extra
configuration options needed.
Sample:
https://github.com/apache/calcite/blob/d9dd3ac8a9f695e111a0a5e77f45b61b90f4b5b6/core/src/main/java/org/apache/calcite/rel/rules/TableScanRule.java#L72C35-L78
It requires users:
1) Use immutables or implement Config manually. Adding immutables processor
adds compile-time overhead, and implementing the interface manually is not
trivial
2) Implement CustomRule(Config) constructor
3) Implement Config.toRule() by calling CustomRule(Config)
---
I suggest:
1) Drop method Config.toRule(), and suggest users to call new ...Rule(config)
directly. Config.toRule() adds no value, and it creates excessive coupling of
Config with the Rule.
2) Provide default Config implementation along with Calcite. For instance
DefaultConfig.EMPTY, DefaultConfigBuilder...
3) Use composition for custom configurations, in other words, let custom rules
have their own attributes, and one of the attributes could be default config.
For instance: {{data class AggregateExpandDistinctAggregatesRule.Config(config
RelRule.Config, usingGroupingSets Boolean)}}
It would make it easier for users to implement config objects, and it would
reduce the code size (generated bytecode and native image size) as the current
Calcite approach duplicates the same "Config" methods like withOperandSupplier
across all the Config implementations
was:
It takes a lot to implement RelRule.Config even for trivial cases when no extra
configuration options needed.
Sample:
https://github.com/apache/calcite/blob/d9dd3ac8a9f695e111a0a5e77f45b61b90f4b5b6/core/src/main/java/org/apache/calcite/rel/rules/TableScanRule.java#L72C35-L78
It requires users:
1) Use immutables or implement Config manually. Adding immutables processor
adds compile-time overhead, and implementing the interface manually is not
trivial
2) Implement CustomRule(Config) constructor
3) Implement Config.toRule() by calling CustomRule(Config)
---
I suggest:
1) Drop method Config.toRule(), and suggest users to call new ...Rule(config)
directly.
2) Provide default Config implementation along with Calcite. For instance
DefaultConfig.EMPTY, DefaultConfigBuilder...
3) Use composition for custom configurations, in other words, let custom rules
have their own attributes, and one of the attributes could be default config.
For instance: {{data class AggregateExpandDistinctAggregatesRule.Config(config
RelRule.Config, usingGroupingSets Boolean)}}
It would make it easier for users to implement config objects, and it would
reduce the code size (generated bytecode and native image size) as the current
Calcite approach duplicates the same "Config" methods like withOperandSupplier
across all the Config implementations
> RelRule.Config requires too much ceremony for trivial cases
> ---
>
> Key: CALCITE-6010
> URL: https://issues.apache.org/jira/browse/CALCITE-6010
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: Vladimir Sitnikov
>Priority: Major
>
> It takes a lot to implement RelRule.Config even for trivial cases when no
> extra configuration options needed.
> Sample:
> https://github.com/apache/calcite/blob/d9dd3ac8a9f695e111a0a5e77f45b61b90f4b5b6/core/src/main/java/org/apache/calcite/rel/rules/TableScanRule.java#L72C35-L78
> It requires users:
> 1) Use immutables or implement Config manually. Adding immutables processor
> adds compile-time overhead, and implementing the interface manually is not
> trivial
> 2) Implement CustomRule(Config) constructor
> 3) Implement Config.toRule() by calling CustomRule(Config)
> ---
> I suggest:
> 1) Drop method Config.toRule(), and suggest users to call new ...Rule(config)
> directly. Config.toRule() adds no value, and it creates excessive coupling of
> Config with the Rule.
> 2) Provide default Config implementation along with Calcite. For instance
> DefaultConfig.EMPTY, DefaultConfigBuilder...
> 3) Use composition for custom configurations, in other words, let custom
> rules have their own attributes, and one of the attributes could be default
> config.
> For instance: {{data class
> AggregateExpandDistinctAggregatesRule.Config(config RelRule.Config,
> usingGroupingSets Boolean)}}
> It would make it easier for users to implement config objects, and it would
> reduce the code size (generated bytecode and native image size) as the
> current Calcite approach duplicates the same "Config" methods like
> withOperandSupplier across all the Config implementations
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CALCITE-6010) RelRule.Config requires too much ceremony for trivial cases
Vladimir Sitnikov created CALCITE-6010:
--
Summary: RelRule.Config requires too much ceremony for trivial
cases
Key: CALCITE-6010
URL: https://issues.apache.org/jira/browse/CALCITE-6010
Project: Calcite
Issue Type: Improvement
Components: core
Reporter: Vladimir Sitnikov
It takes a lot to implement RelRule.Config even for trivial cases when no extra
configuration options needed.
Sample:
https://github.com/apache/calcite/blob/d9dd3ac8a9f695e111a0a5e77f45b61b90f4b5b6/core/src/main/java/org/apache/calcite/rel/rules/TableScanRule.java#L72C35-L78
It requires users:
1) Use immutables or implement Config manually. Adding immutables processor
adds compile-time overhead, and implementing the interface manually is not
trivial
2) Implement CustomRule(Config) constructor
3) Implement Config.toRule() by calling CustomRule(Config)
---
I suggest:
1) Drop method Config.toRule(), and suggest users to call new ...Rule(config)
directly.
2) Provide default Config implementation along with Calcite. For instance
DefaultConfig.EMPTY, DefaultConfigBuilder...
3) Use composition for custom configurations, in other words, let custom rules
have their own attributes, and one of the attributes could be default config.
For instance: {{data class AggregateExpandDistinctAggregatesRule.Config(config
RelRule.Config, usingGroupingSets Boolean)}}
It would make it easier for users to implement config objects, and it would
reduce the code size (generated bytecode and native image size) as the current
Calcite approach duplicates the same "Config" methods like withOperandSupplier
across all the Config implementations
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-4824) ServerUnParserTest#testCreateTableVirtualColumn fails
[
https://issues.apache.org/jira/browse/CALCITE-4824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17722648#comment-17722648
]
Vladimir Sitnikov commented on CALCITE-4824:
The classes have not been modified since 2021, so I would assume the issue is
still there.
I ceased Calcite development some time ago (see
https://lists.apache.org/thread/j4nbh4st0nqbwl69b1mzrsd8p758mf28), and I have
no interest in reproducing the issue.
> ServerUnParserTest#testCreateTableVirtualColumn fails
> --
>
> Key: CALCITE-4824
> URL: https://issues.apache.org/jira/browse/CALCITE-4824
> Project: Calcite
> Issue Type: Improvement
> Components: server
>Reporter: Vladimir Sitnikov
>Priority: Major
>
> It looks like {{org.apache.calcite.server.ServerDdlExecutor#INSTANCE}}
> results in non-synchronized HashMap instances in ReflectUtil.
> Sample failure:
> {noformat}
> ServerUnParserTest > testCreateTableVirtualColumn() STANDARD_ERROR
> log4j:WARN No appenders could be found for logger
> (org.apache.calcite.sql.parser).
> log4j:WARN Please initialize the log4j system properly.
> log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for
> more info.
> WARNING 2.8sec, 442 completed, 0 failed, 5 skipped,
> org.apache.calcite.test.ServerParserTest
> WARNING 3.8sec, 442 completed, 0 failed, 6 skipped,
> org.apache.calcite.test.ServerUnParserTest
> 2.2sec, org.apache.calcite.test.ServerTest > testVirtualColumn()
> org.apache.calcite.test.ServerQuidemTest > test(String)[3], [3] sql\table.iq
> failure marker
> FAILURE 3.6sec, org.apache.calcite.test.ServerQuidemTest > test(String)[3],
> [3] sql\table.iq
> org.opentest4j.AssertionFailedError: Files differ:
> D:\a\calcite\calcite\server\build\resources\test\sql\surefire\sql\table.iq
> D:\a\calcite\calcite\server\build\resources\test\sql\table.iq
> 23c23,155
> < (0 rows modified)
> ---
> > java.sql.SQLException: Error while executing SQL "create table t (i
> int, j int not null)": Method not found: execute([class
> org.apache.calcite.sql.SqlNode, interface
> org.apache.calcite.jdbc.CalcitePrepare$Context])
> > 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.executeLargeUpdate(AvaticaStatement.java:246)
> > at
> org.apache.calcite.avatica.AvaticaStatement.executeUpdate(AvaticaStatement.java:240)
> > at net.hydromatic.quidem.Quidem.update(Quidem.java:279)
> > at net.hydromatic.quidem.Quidem.access$2900(Quidem.java:54)
> > at
> net.hydromatic.quidem.Quidem$ContextImpl.update(Quidem.java:1752)
> > at
> net.hydromatic.quidem.Quidem$UpdateCommand.execute(Quidem.java:1152)
> > 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:156)
> > at
> org.junit.platform.engine.support.hierarchical.NodeTestTask.execute(NodeTestTask.java:95)
> > at
> org.junit.platform.engine.support.hierarchical.ForkJoinPoolHierarchicalTestExecutorService$ExclusiveTask.compute(ForkJoinPoolHierarchicalTestExecutorService.java:185)
> > at
> java.util.concurrent.RecursiveAction.exec(RecursiveAction.java:189)
> > at
> java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:289)
> > at
> java.util.concurrent.ForkJoinPool$WorkQueue.runTask(ForkJoinPool.java:1056)
> > at
> java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1692)
> > at
> java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:175)
> > Caused by: java.lang.IllegalArgumentException: Method not found:
> execute([class org.apache.calcite.sql.SqlNode, interface
> org.apache.calcite.jdbc.CalcitePrepare$Context])
> > at
> org.apache.calcite.util.ReflectUtil$2.lookupMethod(ReflectUtil.java:563)
> > at
> org.apache.calcite.util.ReflectUtil$2.invoke(ReflectUtil.java:527)
> > at
> org.apache.calcite.server.DdlExecutorImpl.executeDdl(DdlExecutorImpl.java:41)
> > at
> org.apache.calcite.prepare.CalcitePrepareImpl.executeDdl(CalcitePrepareImpl.java:369)
> > at
> org.apache.calcite.prepare.CalcitePrepareImpl.prepare2_(CalcitePrepareImpl.java:634)
> > at
> org.apache.calcite.prepare.CalcitePrepareImpl.prepare_(CalcitePrepareImpl.java:513)
[jira] [Assigned] (CALCITE-4832) Refactor Gradle to build-logic convention plugins
[ https://issues.apache.org/jira/browse/CALCITE-4832?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Sitnikov reassigned CALCITE-4832: -- Assignee: (was: Vladimir Sitnikov) > Refactor Gradle to build-logic convention plugins > - > > Key: CALCITE-4832 > URL: https://issues.apache.org/jira/browse/CALCITE-4832 > Project: Calcite > Issue Type: Improvement > Components: build >Reporter: Vladimir Sitnikov >Priority: Major > Labels: pull-request-available > Time Spent: 50m > Remaining Estimate: 0h > > See > https://docs.gradle.org/current/userguide/structuring_software_products.html -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (CALCITE-5034) Disable Gradle build cache or use an alternative account for it
[ https://issues.apache.org/jira/browse/CALCITE-5034?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Sitnikov updated CALCITE-5034: --- Description: Calcite uses build cache since CALCITE-4140. I'm paying for the service (~$6/month), and there's a risk bank will block further payments (I'm from Russia :-/ ), so I think it is time to switch to another account or disable the build-cache. I've chosen Wasabi S3 since they have a free egress policy, so the costs are predictable. Cloudflare R2 is not ready yet: https://blog.cloudflare.com/introducing-r2-object-storage/ Rough stats so far Total storage=15 GiB (~retention is 30 days) Upload=0.1-0.2 GiB/day Download=1-2 GiB/day was: Calcite uses build cache since CALCITE-4140. I'm paying for the service (~$6/month), and there's a risk bank will block further payments (I'm from Russia :-/ ), so I think it is time to switch to another account or disable the build-cache. I've chosen Wasabi S3 since they have a free egress policy, so the costs are predictable. Cloudflare R2 is not ready yet: https://blog.cloudflare.com/introducing-r2-object-storage/ Rough stats so far Total storage=15 GiB Upload=0.1-0.2 GiB/day Download=1-2 GiB/day > Disable Gradle build cache or use an alternative account for it > --- > > Key: CALCITE-5034 > URL: https://issues.apache.org/jira/browse/CALCITE-5034 > Project: Calcite > Issue Type: Task > Components: build >Reporter: Vladimir Sitnikov >Priority: Major > Attachments: bucket-utilization-cache.csv > > > Calcite uses build cache since CALCITE-4140. > I'm paying for the service (~$6/month), and there's a risk bank will block > further payments (I'm from Russia :-/ ), so I think it is time to switch to > another account or disable the build-cache. > I've chosen Wasabi S3 since they have a free egress policy, so the costs are > predictable. > Cloudflare R2 is not ready yet: > https://blog.cloudflare.com/introducing-r2-object-storage/ > Rough stats so far > Total storage=15 GiB (~retention is 30 days) > Upload=0.1-0.2 GiB/day > Download=1-2 GiB/day -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (CALCITE-5034) Disable Gradle build cache or use an alternative account for it
[ https://issues.apache.org/jira/browse/CALCITE-5034?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Sitnikov updated CALCITE-5034: --- Description: Calcite uses build cache since CALCITE-4140. I'm paying for the service (~$6/month), and there's a risk bank will block further payments (I'm from Russia :-/ ), so I think it is time to switch to another account or disable the build-cache. I've chosen Wasabi S3 since they have a free egress policy, so the costs are predictable. Cloudflare R2 is not ready yet: https://blog.cloudflare.com/introducing-r2-object-storage/ Rough stats so far Total storage=15 GiB Upload=0.1-0.2 GiB/day Download=1-2 GiB/day was: Calcite uses build cache since CALCITE-4140. I'm paying for the service (~$6/month), and there's a risk bank will block further payments (I'm from Russia :-/ ), so I think it is time to switch to another account or disable the build-cache. I've chosen Wasabi S3 since they have a free egress policy, so the costs are predictable. Cloudflare R2 is not yet ready: https://blog.cloudflare.com/introducing-r2-object-storage/ Rough stats so far Total storage=15 GiB Upload=0.1-0.2 GiB/day Download=1-2 GiB/day > Disable Gradle build cache or use an alternative account for it > --- > > Key: CALCITE-5034 > URL: https://issues.apache.org/jira/browse/CALCITE-5034 > Project: Calcite > Issue Type: Task > Components: build >Reporter: Vladimir Sitnikov >Priority: Major > Attachments: bucket-utilization-cache.csv > > > Calcite uses build cache since CALCITE-4140. > I'm paying for the service (~$6/month), and there's a risk bank will block > further payments (I'm from Russia :-/ ), so I think it is time to switch to > another account or disable the build-cache. > I've chosen Wasabi S3 since they have a free egress policy, so the costs are > predictable. > Cloudflare R2 is not ready yet: > https://blog.cloudflare.com/introducing-r2-object-storage/ > Rough stats so far > Total storage=15 GiB > Upload=0.1-0.2 GiB/day > Download=1-2 GiB/day -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (CALCITE-5034) Disable Gradle build cache or use an alternative accout for it
Vladimir Sitnikov created CALCITE-5034: -- Summary: Disable Gradle build cache or use an alternative accout for it Key: CALCITE-5034 URL: https://issues.apache.org/jira/browse/CALCITE-5034 Project: Calcite Issue Type: Task Components: build Reporter: Vladimir Sitnikov Attachments: bucket-utilization-cache.csv Calcite uses build cache since CALCITE-4140. I'm paying for the service (~$6/month), and there's a risk bank will block further payments (I'm from Russia :-/ ), so I think it is time to switch to another account or disable the build-cache. I've chosen Wasabi S3 since they have a free egress policy, so the costs are predictable. Cloudflare R2 is not yet ready: https://blog.cloudflare.com/introducing-r2-object-storage/ Rough stats so far Total storage=15 GiB Upload=0.1-0.2 GiB/day Download=1-2 GiB/day -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (CALCITE-5034) Disable Gradle build cache or use an alternative account for it
[ https://issues.apache.org/jira/browse/CALCITE-5034?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Sitnikov updated CALCITE-5034: --- Summary: Disable Gradle build cache or use an alternative account for it (was: Disable Gradle build cache or use an alternative accout for it) > Disable Gradle build cache or use an alternative account for it > --- > > Key: CALCITE-5034 > URL: https://issues.apache.org/jira/browse/CALCITE-5034 > Project: Calcite > Issue Type: Task > Components: build >Reporter: Vladimir Sitnikov >Priority: Major > Attachments: bucket-utilization-cache.csv > > > Calcite uses build cache since CALCITE-4140. > I'm paying for the service (~$6/month), and there's a risk bank will block > further payments (I'm from Russia :-/ ), so I think it is time to switch to > another account or disable the build-cache. > I've chosen Wasabi S3 since they have a free egress policy, so the costs are > predictable. > Cloudflare R2 is not yet ready: > https://blog.cloudflare.com/introducing-r2-object-storage/ > Rough stats so far > Total storage=15 GiB > Upload=0.1-0.2 GiB/day > Download=1-2 GiB/day -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (CALCITE-4856) Gradle prepareVote fails with 'not authorized'
[
https://issues.apache.org/jira/browse/CALCITE-4856?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17462928#comment-17462928
]
Vladimir Sitnikov commented on CALCITE-4856:
Julian, GitHub did improve things by forbidding hard-coding passwords. Of
course, it could be that a year ago passwords did work, and now they do not.
The good thing is GitHub allows 2FA, so having GitHub as a default is good.
{quote}was tricky to get working. In fact I never fully got it working.{quote}
Can you clarify what is not really working?
It is really sad when you add more and more manual steps and switches to the
release process. The release should be a mechanical process.
> Gradle prepareVote fails with 'not authorized'
> --
>
> Key: CALCITE-4856
> URL: https://issues.apache.org/jira/browse/CALCITE-4856
> Project: Calcite
> Issue Type: Bug
>Reporter: Julian Hyde
>Priority: Major
> Fix For: 1.29.0
>
>
> Gradle {{prepareVote}} fails with 'not authorized' error.
> {noformat}
> $ ./gradlew prepareVote -Prc=0 -Pasf
> > Configure project :
> Building Apache Calcite 1.28.0
> > Task :gitProps
> Execution optimizations have been disabled for task ':gitProps' to ensure
> correctness due to the following reasons:
> - Gradle detected a problem with the following location:
> '/home/jhyde/dev/release/calcite'. Reason: Task ':gitProps' uses this output
> of task ':babel:fmppMain' without declaring an explicit or implicit
> dependency. This can lead to incorrect results being produced, depending on
> what order the tasks are executed. Please refer to
> https://docs.gradle.org/7.2/userguide/validation_problems.html#implicit_dependency
> for more details about this problem.
> ...
> > Task :pushRcTag
> Pushing tag to Git remote release-origin:
> https://github.com/apache/calcite.git
> > Task :pushRcTag FAILED
> Build calcite FAILURE reason:
> Execution failed for task ':pushRcTag':
> Caused by: org.eclipse.jgit.api.errors.TransportException:
> https://github.com/apache/calcite.git: not authorized
> at org.eclipse.jgit.api.PushCommand.call(PushCommand.java:180)
> at
> com.github.vlsi.gradle.release.jgit.dsl.GitExtensionsKt.push(GitExtensions.kt:132)
> at
> com.github.vlsi.gradle.release.GitPushTask$pushTag$1.invoke(GitPushTask.kt:54)
> at
> com.github.vlsi.gradle.release.GitPushTask$pushTag$1.invoke(GitPushTask.kt:30)
> at
> com.github.vlsi.gradle.release.DefaultGitTask.jgit(DefaultGitTask.kt:45)
> at
> com.github.vlsi.gradle.release.GitPushTask.pushTag(GitPushTask.kt:50)
> at
> org.gradle.internal.reflect.JavaMethod.invoke(JavaMethod.java:104)
> at
> org.gradle.api.internal.project.taskfactory.StandardTaskAction.doExecute(StandardTaskAction.java:58)
> ...
> at
> org.eclipse.jgit.transport.Transport.push(Transport.java:1368)
> at org.eclipse.jgit.api.PushCommand.call(PushCommand.java:170)
> ... 89 more
> FAILURE: Build failed with an exception.
> * What went wrong:
> Execution failed for task ':pushRcTag'.
> > org.eclipse.jgit.api.errors.TransportException:
> > https://github.com/apache/calcite.git: not authorized
> * Try:
> Run with --stacktrace option to get the stack trace. Run with --info or
> --debug option to get more log output. Run with --scan to get full insights.
> * Get more help at https://help.gradle.org
> Deprecated Gradle features were used in this build, making it incompatible
> with Gradle 8.0.
> You can use '--warning-mode all' to show the individual deprecation warnings
> and determine if they come from your own scripts or plugins.
> See
> https://docs.gradle.org/7.2/userguide/command_line_interface.html#sec:command_line_warnings
> Execution optimizations have been disabled for 29 invalid unit(s) of work
> during this build to ensure correctness.
> Please consult deprecation warnings for more details.
> BUILD FAILED in 2m 32s
> 268 actionable tasks: 187 executed, 20 from cache, 61 up-to-date
> S3 cache 5s wasted (3s wasted on hits, 2s wasted on misses), reads: 43, hits:
> 20, elapsed: 5s, received: 8 KiB
> {noformat}
> I had tried previously without the {{-Pasf}} flag but that ran into other
> errors, sooner in the process, that seemed to be about my environment. I
> concluded that the dry-run was a waste of time.
> I'm not sure why the command is trying to push to github rather than gitbox.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (CALCITE-4915) Query with unqualified common column and NATURAL JOIN fails
[
https://issues.apache.org/jira/browse/CALCITE-4915?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17452909#comment-17452909
]
Vladimir Sitnikov commented on CALCITE-4915:
{quote}I've found some bugs during testing of NATURAL JOINs in our framework,
each bug should be investigated first to be sure that the problem is in Calcite
and not in our code, after investigation I've filed a ticket and pretty
straightforward fix. Of course for complex tickets, it's better to discuss
first, before the implementation.{quote}
+100500. This is a clear bug, and we do not need a JIRA ticket for it. Just PR
would be enough
> Query with unqualified common column and NATURAL JOIN fails
> ---
>
> Key: CALCITE-4915
> URL: https://issues.apache.org/jira/browse/CALCITE-4915
> Project: Calcite
> Issue Type: Bug
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Labels: pull-request-available
>
> Query with unqualified common column and NATURAL JOIN:
> {noformat}
> SELECT deptno FROM emp NATURAL JOIN dept{noformat}
> Fails with "Column 'DEPTNO' is ambiguous" error.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (CALCITE-4889) Double join is created for NOT IN
[
https://issues.apache.org/jira/browse/CALCITE-4889?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Sitnikov updated CALCITE-4889:
---
Description:
The following queries yield several joins in the plan.
I think double joins are excessive here, especially for the first case where
all the values are non-nullable.
Original discussion:
https://github.com/apache/calcite/pull/2607/files#diff-26cbb70deb4731f2c84faf803724dc40a9cdf6e2f2c67f8724e1afbc98fc8950R3320
{code}select * from "scott".emp where (empno, deptno) not in ((7369, 20),
(7499, 30));{code}
{noformat}
select * from "scott".emp where empno not in (null, 7782);
EnumerableCalc(expr#0..12=[{inputs}], expr#13=[0:BIGINT], expr#14=[=($t8,
$t13)], expr#15=[IS NULL($t12)], expr#16=[>=($t9, $t8)], expr#17=[AND($t15,
$t16)], expr#18=[OR($t14, $t17)], proj#0..7=[{exprs}], $condition=[$t18])
EnumerableMergeJoin(condition=[=($10, $11)], joinType=[left])
EnumerableSort(sort0=[$10], dir0=[ASC])
EnumerableCalc(expr#0..9=[{inputs}], proj#0..9=[{exprs}], EMPNO0=[$t0])
EnumerableNestedLoopJoin(condition=[true], joinType=[inner])
EnumerableTableScan(table=[[scott, EMP]])
EnumerableAggregate(group=[{}], agg#0=[COUNT()], agg#1=[COUNT($0)])
EnumerableValues(tuples=[[{ null }, { 7782 }]])
EnumerableSort(sort0=[$0], dir0=[ASC])
EnumerableCalc(expr#0=[{inputs}], expr#1=[true], proj#0..1=[{exprs}])
EnumerableValues(tuples=[[{ null }, { 7782 }]])
{noformat}
{noformat}
select * from "scott".emp where (empno, deptno) not in ((1, 2), (3, null));
EnumerableCalc(expr#0..14=[{inputs}], expr#15=[0:BIGINT], expr#16=[=($t8,
$t15)], expr#17=[IS NULL($t14)], expr#18=[>=($t9, $t8)], expr#19=[IS NOT
NULL($t11)], expr#20=[AND($t17, $t18, $t19)], expr#21=[OR($t16, $t20)],
proj#0..7=[{exprs}], $condition=[$t21])
EnumerableMergeJoin(condition=[AND(=($10, $12), =($11, $13))],
joinType=[left])
EnumerableSort(sort0=[$10], sort1=[$11], dir0=[ASC], dir1=[ASC])
EnumerableCalc(expr#0..9=[{inputs}], proj#0..9=[{exprs}], EMPNO0=[$t0],
DEPTNO0=[$t7])
EnumerableNestedLoopJoin(condition=[true], joinType=[inner])
EnumerableTableScan(table=[[scott, EMP]])
EnumerableAggregate(group=[{}], agg#0=[COUNT()], agg#1=[COUNT($0,
$1)])
EnumerableValues(tuples=[[{ 1, 2 }, { 3, null }]])
EnumerableSort(sort0=[$0], sort1=[$1], dir0=[ASC], dir1=[ASC])
EnumerableCalc(expr#0..1=[{inputs}], expr#2=[true], proj#0..2=[{exprs}])
EnumerableValues(tuples=[[{ 1, 2 }, { 3, null }]])
{noformat}
was:
The following queries yield several joins in the plan.
I think double joins are excessive here, especially for the first case where
all the values are non-nullable.
{code}select * from "scott".emp where (empno, deptno) not in ((7369, 20),
(7499, 30));{code}
{noformat}
select * from "scott".emp where empno not in (null, 7782);
EnumerableCalc(expr#0..12=[{inputs}], expr#13=[0:BIGINT], expr#14=[=($t8,
$t13)], expr#15=[IS NULL($t12)], expr#16=[>=($t9, $t8)], expr#17=[AND($t15,
$t16)], expr#18=[OR($t14, $t17)], proj#0..7=[{exprs}], $condition=[$t18])
EnumerableMergeJoin(condition=[=($10, $11)], joinType=[left])
EnumerableSort(sort0=[$10], dir0=[ASC])
EnumerableCalc(expr#0..9=[{inputs}], proj#0..9=[{exprs}], EMPNO0=[$t0])
EnumerableNestedLoopJoin(condition=[true], joinType=[inner])
EnumerableTableScan(table=[[scott, EMP]])
EnumerableAggregate(group=[{}], agg#0=[COUNT()], agg#1=[COUNT($0)])
EnumerableValues(tuples=[[{ null }, { 7782 }]])
EnumerableSort(sort0=[$0], dir0=[ASC])
EnumerableCalc(expr#0=[{inputs}], expr#1=[true], proj#0..1=[{exprs}])
EnumerableValues(tuples=[[{ null }, { 7782 }]])
{noformat}
{noformat}
select * from "scott".emp where (empno, deptno) not in ((1, 2), (3, null));
EnumerableCalc(expr#0..14=[{inputs}], expr#15=[0:BIGINT], expr#16=[=($t8,
$t15)], expr#17=[IS NULL($t14)], expr#18=[>=($t9, $t8)], expr#19=[IS NOT
NULL($t11)], expr#20=[AND($t17, $t18, $t19)], expr#21=[OR($t16, $t20)],
proj#0..7=[{exprs}], $condition=[$t21])
EnumerableMergeJoin(condition=[AND(=($10, $12), =($11, $13))],
joinType=[left])
EnumerableSort(sort0=[$10], sort1=[$11], dir0=[ASC], dir1=[ASC])
EnumerableCalc(expr#0..9=[{inputs}], proj#0..9=[{exprs}], EMPNO0=[$t0],
DEPTNO0=[$t7])
EnumerableNestedLoopJoin(condition=[true], joinType=[inner])
EnumerableTableScan(table=[[scott, EMP]])
EnumerableAggregate(group=[{}], agg#0=[COUNT()], agg#1=[COUNT($0,
$1)])
EnumerableValues(tuples=[[{ 1, 2 }, { 3, null }]])
EnumerableSort(sort0=[$0], sort1=[$1], dir0=[ASC], dir1=[ASC])
EnumerableCalc(expr#0..1=[{inputs}], expr#2=[true], proj#0..2=[{exprs}])
EnumerableValues(tuples=[[{ 1, 2 }, { 3, null }]])
{noformat}
> Double join is created for NOT IN
> -
[jira] [Commented] (CALCITE-4889) Double join is created for NOT IN
[
https://issues.apache.org/jira/browse/CALCITE-4889?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17449478#comment-17449478
]
Vladimir Sitnikov commented on CALCITE-4889:
[~jingzhang], I noticed the case here:
https://github.com/apache/calcite/pull/2607/files#diff-26cbb70deb4731f2c84faf803724dc40a9cdf6e2f2c67f8724e1afbc98fc8950R3320
> Double join is created for NOT IN
> -
>
> Key: CALCITE-4889
> URL: https://issues.apache.org/jira/browse/CALCITE-4889
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.28.0
>Reporter: Vladimir Sitnikov
>Priority: Major
>
> The following queries yield several joins in the plan.
> I think double joins are excessive here, especially for the first case where
> all the values are non-nullable.
> Original discussion:
> https://github.com/apache/calcite/pull/2607/files#diff-26cbb70deb4731f2c84faf803724dc40a9cdf6e2f2c67f8724e1afbc98fc8950R3320
> {code}select * from "scott".emp where (empno, deptno) not in ((7369, 20),
> (7499, 30));{code}
> {noformat}
> select * from "scott".emp where empno not in (null, 7782);
> EnumerableCalc(expr#0..12=[{inputs}], expr#13=[0:BIGINT], expr#14=[=($t8,
> $t13)], expr#15=[IS NULL($t12)], expr#16=[>=($t9, $t8)], expr#17=[AND($t15,
> $t16)], expr#18=[OR($t14, $t17)], proj#0..7=[{exprs}], $condition=[$t18])
> EnumerableMergeJoin(condition=[=($10, $11)], joinType=[left])
> EnumerableSort(sort0=[$10], dir0=[ASC])
> EnumerableCalc(expr#0..9=[{inputs}], proj#0..9=[{exprs}], EMPNO0=[$t0])
> EnumerableNestedLoopJoin(condition=[true], joinType=[inner])
> EnumerableTableScan(table=[[scott, EMP]])
> EnumerableAggregate(group=[{}], agg#0=[COUNT()], agg#1=[COUNT($0)])
> EnumerableValues(tuples=[[{ null }, { 7782 }]])
> EnumerableSort(sort0=[$0], dir0=[ASC])
> EnumerableCalc(expr#0=[{inputs}], expr#1=[true], proj#0..1=[{exprs}])
> EnumerableValues(tuples=[[{ null }, { 7782 }]])
> {noformat}
> {noformat}
> select * from "scott".emp where (empno, deptno) not in ((1, 2), (3, null));
> EnumerableCalc(expr#0..14=[{inputs}], expr#15=[0:BIGINT], expr#16=[=($t8,
> $t15)], expr#17=[IS NULL($t14)], expr#18=[>=($t9, $t8)], expr#19=[IS NOT
> NULL($t11)], expr#20=[AND($t17, $t18, $t19)], expr#21=[OR($t16, $t20)],
> proj#0..7=[{exprs}], $condition=[$t21])
> EnumerableMergeJoin(condition=[AND(=($10, $12), =($11, $13))],
> joinType=[left])
> EnumerableSort(sort0=[$10], sort1=[$11], dir0=[ASC], dir1=[ASC])
> EnumerableCalc(expr#0..9=[{inputs}], proj#0..9=[{exprs}], EMPNO0=[$t0],
> DEPTNO0=[$t7])
> EnumerableNestedLoopJoin(condition=[true], joinType=[inner])
> EnumerableTableScan(table=[[scott, EMP]])
> EnumerableAggregate(group=[{}], agg#0=[COUNT()], agg#1=[COUNT($0,
> $1)])
> EnumerableValues(tuples=[[{ 1, 2 }, { 3, null }]])
> EnumerableSort(sort0=[$0], sort1=[$1], dir0=[ASC], dir1=[ASC])
> EnumerableCalc(expr#0..1=[{inputs}], expr#2=[true], proj#0..2=[{exprs}])
> EnumerableValues(tuples=[[{ 1, 2 }, { 3, null }]])
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (CALCITE-4894) MV rewriting fails for expressions with more than a field reference in the view/query projection
[
https://issues.apache.org/jira/browse/CALCITE-4894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17445963#comment-17445963
]
Vladimir Sitnikov commented on CALCITE-4894:
I do not understand your use case, however, it looks like you have found
"unimplemented feature" which manifests itself via {{assert}} check.
I think all "unimplemented" features should be regular exceptions (e.g.
invalidargument, illegalstate, and so on).
{{assert}} should be for the cases "I bet planner state is always valid,
however, let us double-check just in case".
> MV rewriting fails for expressions with more than a field reference in the
> view/query projection
>
>
> Key: CALCITE-4894
> URL: https://issues.apache.org/jira/browse/CALCITE-4894
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.28.0
>Reporter: Alessandro Solimando
>Assignee: Alessandro Solimando
>Priority: Major
>
> MV rewrite fails when at least one expression in the project of either the
> view or the query references, directly or indirectly, to more than one field.
> Consider a view with an expression of the form "f between 1 and 3" expression
> (which under the hood becomes "f >= 1 and f <= 3", so effectively referencing
> the same field twice):
> {code:java}
> @Test void testViewProjectWithBetween() {
> sql("select s.\"time_id\", s.\"time_id\" between 1 and 3"
> + " from \"foodmart\".\"sales_fact_1997\" as s"
> + " where s.\"store_id\" = 1",
> "select s.\"time_id\""
> + " from \"foodmart\".\"sales_fact_1997\" as s"
> + " where s.\"store_id\" = 1")
> .withDefaultSchemaSpec(CalciteAssert.SchemaSpec.JDBC_FOODMART)
> .ok();
> }{code}
> It fails as follows:
> {noformat}
> FAILURE 6.9sec, org.apache.calcite.test.MaterializedViewRelOptRulesTest >
> testViewProjectWithBetween()
> java.lang.AssertionError
> at
> org.apache.calcite.rel.rules.materialize.MaterializedViewRule.generateSwapTableColumnReferencesLineage(MaterializedViewRule.java:1046)
> at
> org.apache.calcite.rel.rules.materialize.MaterializedViewRule.rewriteExpressions(MaterializedViewRule.java:1005)
> at
> org.apache.calcite.rel.rules.materialize.MaterializedViewJoinRule.rewriteView(MaterializedViewJoinRule.java:278)
> at
> org.apache.calcite.rel.rules.materialize.MaterializedViewRule.perform(MaterializedViewRule.java:475)
> at
> org.apache.calcite.rel.rules.materialize.MaterializedViewOnlyFilterRule.onMatch(MaterializedViewOnlyFilterRule.java:50)
> at
> org.apache.calcite.plan.volcano.VolcanoRuleCall.onMatch(VolcanoRuleCall.java:239)
> at
> org.apache.calcite.plan.volcano.IterativeRuleDriver.drive(IterativeRuleDriver.java:61)
> at
> org.apache.calcite.plan.volcano.VolcanoPlanner.findBestExp(VolcanoPlanner.java:523)
> at
> org.apache.calcite.tools.Programs.lambda$standard$3(Programs.java:276)
> at
> org.apache.calcite.tools.Programs$SequenceProgram.run(Programs.java:336)
> at
> org.apache.calcite.test.MaterializedViewRelOptRulesTest.optimize(MaterializedViewRelOptRulesTest.java:1210)
> at
> org.apache.calcite.test.AbstractMaterializedViewTest.checkMaterialize(AbstractMaterializedViewTest.java:109)
> at
> org.apache.calcite.test.AbstractMaterializedViewTest.access$000(AbstractMaterializedViewTest.java:69)
> at
> org.apache.calcite.test.AbstractMaterializedViewTest$Sql.ok(AbstractMaterializedViewTest.java:230)
> at
> org.apache.calcite.test.MaterializedViewRelOptRulesTest.testViewProjectWithBetween(MaterializedViewRelOptRulesTest.java:60){noformat}
>
> Similarly when the same kind of expression is present in the query:
> {code:java}
> @Test void testQueryProjectWithBetween() {
> sql("select *"
> + " from \"foodmart\".\"sales_fact_1997\" as s"
> + " where s.\"store_id\" = 1",
> "select s.\"time_id\" between 1 and 3"
> + " from \"foodmart\".\"sales_fact_1997\" as s"
> + " where s.\"store_id\" = 1")
> .withDefaultSchemaSpec(CalciteAssert.SchemaSpec.JDBC_FOODMART)
> .ok();
> } {code}
> Calcite fails as follows:
> {noformat}
> FAILURE 5.5sec, org.apache.calcite.test.MaterializedViewRelOptRulesTest >
> testQueryProjectWithBetween()
> java.lang.AssertionError
> at
> org.apache.calcite.rel.rules.materialize.MaterializedViewJoinRule.rewriteView(MaterializedViewJoinRule.java:268)
> at
> org.apache.calcite.rel.rules.materialize.MaterializedViewRule.perform(MaterializedViewRule.java:475)
> at
> org.apache.calcite.rel.rules.materialize.MaterializedViewProjectFilterRule.onMatch(MaterializedViewProjectFilterRule.java:53)
[jira] [Commented] (CALCITE-4894) MV rewriting fails for expressions with more than a field reference in the view/query projection
[
https://issues.apache.org/jira/browse/CALCITE-4894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17445939#comment-17445939
]
Vladimir Sitnikov commented on CALCITE-4894:
Just wondering: should it be a regular (always-enabled) exception rather than
an assertion?
> MV rewriting fails for expressions with more than a field reference in the
> view/query projection
>
>
> Key: CALCITE-4894
> URL: https://issues.apache.org/jira/browse/CALCITE-4894
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.28.0
>Reporter: Alessandro Solimando
>Assignee: Alessandro Solimando
>Priority: Major
>
> MV rewrite fails when at least one expression in the project of either the
> view or the query references, directly or indirectly, to more than one field.
> Consider a view with an expression of the form "f between 1 and 3" expression
> (which under the hood becomes "f >= 1 and f <= 3", so effectively referencing
> the same field twice):
> {code:java}
> @Test void testViewProjectWithBetween() {
> sql("select s.\"time_id\", s.\"time_id\" between 1 and 3"
> + " from \"foodmart\".\"sales_fact_1997\" as s"
> + " where s.\"store_id\" = 1",
> "select s.\"time_id\""
> + " from \"foodmart\".\"sales_fact_1997\" as s"
> + " where s.\"store_id\" = 1")
> .withDefaultSchemaSpec(CalciteAssert.SchemaSpec.JDBC_FOODMART)
> .ok();
> }{code}
> It fails as follows:
> {noformat}
> FAILURE 6.9sec, org.apache.calcite.test.MaterializedViewRelOptRulesTest >
> testViewProjectWithBetween()
> java.lang.AssertionError
> at
> org.apache.calcite.rel.rules.materialize.MaterializedViewRule.generateSwapTableColumnReferencesLineage(MaterializedViewRule.java:1046)
> at
> org.apache.calcite.rel.rules.materialize.MaterializedViewRule.rewriteExpressions(MaterializedViewRule.java:1005)
> at
> org.apache.calcite.rel.rules.materialize.MaterializedViewJoinRule.rewriteView(MaterializedViewJoinRule.java:278)
> at
> org.apache.calcite.rel.rules.materialize.MaterializedViewRule.perform(MaterializedViewRule.java:475)
> at
> org.apache.calcite.rel.rules.materialize.MaterializedViewOnlyFilterRule.onMatch(MaterializedViewOnlyFilterRule.java:50)
> at
> org.apache.calcite.plan.volcano.VolcanoRuleCall.onMatch(VolcanoRuleCall.java:239)
> at
> org.apache.calcite.plan.volcano.IterativeRuleDriver.drive(IterativeRuleDriver.java:61)
> at
> org.apache.calcite.plan.volcano.VolcanoPlanner.findBestExp(VolcanoPlanner.java:523)
> at
> org.apache.calcite.tools.Programs.lambda$standard$3(Programs.java:276)
> at
> org.apache.calcite.tools.Programs$SequenceProgram.run(Programs.java:336)
> at
> org.apache.calcite.test.MaterializedViewRelOptRulesTest.optimize(MaterializedViewRelOptRulesTest.java:1210)
> at
> org.apache.calcite.test.AbstractMaterializedViewTest.checkMaterialize(AbstractMaterializedViewTest.java:109)
> at
> org.apache.calcite.test.AbstractMaterializedViewTest.access$000(AbstractMaterializedViewTest.java:69)
> at
> org.apache.calcite.test.AbstractMaterializedViewTest$Sql.ok(AbstractMaterializedViewTest.java:230)
> at
> org.apache.calcite.test.MaterializedViewRelOptRulesTest.testViewProjectWithBetween(MaterializedViewRelOptRulesTest.java:60){noformat}
>
> Similarly when the same kind of expression is present in the query:
> {code:java}
> @Test void testQueryProjectWithBetween() {
> sql("select *"
> + " from \"foodmart\".\"sales_fact_1997\" as s"
> + " where s.\"store_id\" = 1",
> "select s.\"time_id\" between 1 and 3"
> + " from \"foodmart\".\"sales_fact_1997\" as s"
> + " where s.\"store_id\" = 1")
> .withDefaultSchemaSpec(CalciteAssert.SchemaSpec.JDBC_FOODMART)
> .ok();
> } {code}
> Calcite fails as follows:
> {noformat}
> FAILURE 5.5sec, org.apache.calcite.test.MaterializedViewRelOptRulesTest >
> testQueryProjectWithBetween()
> java.lang.AssertionError
> at
> org.apache.calcite.rel.rules.materialize.MaterializedViewJoinRule.rewriteView(MaterializedViewJoinRule.java:268)
> at
> org.apache.calcite.rel.rules.materialize.MaterializedViewRule.perform(MaterializedViewRule.java:475)
> at
> org.apache.calcite.rel.rules.materialize.MaterializedViewProjectFilterRule.onMatch(MaterializedViewProjectFilterRule.java:53)
> at
> org.apache.calcite.plan.volcano.VolcanoRuleCall.onMatch(VolcanoRuleCall.java:239)
> at
> org.apache.calcite.plan.volcano.IterativeRuleDriver.drive(IterativeRuleDriver.java:61)
> at
>
[jira] [Commented] (CALCITE-4894) MV rewriting fails for expressions with more than a field reference in the view/query projection
[
https://issues.apache.org/jira/browse/CALCITE-4894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17445811#comment-17445811
]
Vladimir Sitnikov commented on CALCITE-4894:
The comment should have been a message to the assert call.
In other words, instead of
{code:java}
// We only support project - filter - join, thus it should map to
// a single expression
assert s.size() == 1;
{code}
The code should be
{code:java}
assert s.size() == 1 : "We only support project - filter - join, thus it
should map to a single expression, got: " + s;
{code}
> MV rewriting fails for expressions with more than a field reference in the
> view/query projection
>
>
> Key: CALCITE-4894
> URL: https://issues.apache.org/jira/browse/CALCITE-4894
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.28.0
>Reporter: Alessandro Solimando
>Priority: Major
>
> MV rewrite fails when at least one expression in the project of either the
> view or the query references, directly or indirectly, to more than one field.
> Consider a view with an expression of the form "f between 1 and 3" expression
> (which under the hood becomes "f >= 1 and f <= 3", so effectively referencing
> the same field twice):
> {code:java}
> @Test void testViewProjectWithBetween() {
> sql("select s.\"time_id\", s.\"time_id\" between 1 and 3"
> + " from \"foodmart\".\"sales_fact_1997\" as s"
> + " where s.\"store_id\" = 1",
> "select s.\"time_id\""
> + " from \"foodmart\".\"sales_fact_1997\" as s"
> + " where s.\"store_id\" = 1")
> .withDefaultSchemaSpec(CalciteAssert.SchemaSpec.JDBC_FOODMART)
> .ok();
> }{code}
> It fails as follows:
> {noformat}
> FAILURE 6.9sec, org.apache.calcite.test.MaterializedViewRelOptRulesTest >
> testViewProjectWithBetween()
> java.lang.AssertionError
> at
> org.apache.calcite.rel.rules.materialize.MaterializedViewRule.generateSwapTableColumnReferencesLineage(MaterializedViewRule.java:1046)
> at
> org.apache.calcite.rel.rules.materialize.MaterializedViewRule.rewriteExpressions(MaterializedViewRule.java:1005)
> at
> org.apache.calcite.rel.rules.materialize.MaterializedViewJoinRule.rewriteView(MaterializedViewJoinRule.java:278)
> at
> org.apache.calcite.rel.rules.materialize.MaterializedViewRule.perform(MaterializedViewRule.java:475)
> at
> org.apache.calcite.rel.rules.materialize.MaterializedViewOnlyFilterRule.onMatch(MaterializedViewOnlyFilterRule.java:50)
> at
> org.apache.calcite.plan.volcano.VolcanoRuleCall.onMatch(VolcanoRuleCall.java:239)
> at
> org.apache.calcite.plan.volcano.IterativeRuleDriver.drive(IterativeRuleDriver.java:61)
> at
> org.apache.calcite.plan.volcano.VolcanoPlanner.findBestExp(VolcanoPlanner.java:523)
> at
> org.apache.calcite.tools.Programs.lambda$standard$3(Programs.java:276)
> at
> org.apache.calcite.tools.Programs$SequenceProgram.run(Programs.java:336)
> at
> org.apache.calcite.test.MaterializedViewRelOptRulesTest.optimize(MaterializedViewRelOptRulesTest.java:1210)
> at
> org.apache.calcite.test.AbstractMaterializedViewTest.checkMaterialize(AbstractMaterializedViewTest.java:109)
> at
> org.apache.calcite.test.AbstractMaterializedViewTest.access$000(AbstractMaterializedViewTest.java:69)
> at
> org.apache.calcite.test.AbstractMaterializedViewTest$Sql.ok(AbstractMaterializedViewTest.java:230)
> at
> org.apache.calcite.test.MaterializedViewRelOptRulesTest.testViewProjectWithBetween(MaterializedViewRelOptRulesTest.java:60){noformat}
>
> Similarly when the same kind of expression is present in the query:
> {code:java}
> @Test void testQueryProjectWithBetween() {
> sql("select *"
> + " from \"foodmart\".\"sales_fact_1997\" as s"
> + " where s.\"store_id\" = 1",
> "select s.\"time_id\" between 1 and 3"
> + " from \"foodmart\".\"sales_fact_1997\" as s"
> + " where s.\"store_id\" = 1")
> .withDefaultSchemaSpec(CalciteAssert.SchemaSpec.JDBC_FOODMART)
> .ok();
> } {code}
> Calcite fails as follows:
> {noformat}
> FAILURE 5.5sec, org.apache.calcite.test.MaterializedViewRelOptRulesTest >
> testQueryProjectWithBetween()
> java.lang.AssertionError
> at
> org.apache.calcite.rel.rules.materialize.MaterializedViewJoinRule.rewriteView(MaterializedViewJoinRule.java:268)
> at
> org.apache.calcite.rel.rules.materialize.MaterializedViewRule.perform(MaterializedViewRule.java:475)
> at
> org.apache.calcite.rel.rules.materialize.MaterializedViewProjectFilterRule.onMatch(MaterializedViewProjectFilterRule.java:53)
> at
>
[jira] [Commented] (CALCITE-4890) Enable mavenLocal for sqlline
[
https://issues.apache.org/jira/browse/CALCITE-4890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17445142#comment-17445142
]
Vladimir Sitnikov commented on CALCITE-4890:
I would inline to
a) allow passing custom arguments to Gradle build, so the ones who need
mavenLocal would pass -PenableMavenLocal or something like that
b) allow custom local.properties feature (e.g. Gradle properties relevant for
the local clone)
Both would allow overriding dependency versions and keep git sources unmodified.
> Enable mavenLocal for sqlline
> --
>
> Key: CALCITE-4890
> URL: https://issues.apache.org/jira/browse/CALCITE-4890
> Project: Calcite
> Issue Type: Bug
>Reporter: Sergey Nuyanzin
>Priority: Major
>
> 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
>
[jira] [Updated] (CALCITE-4889) Double join is created for NOT IN
[
https://issues.apache.org/jira/browse/CALCITE-4889?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Sitnikov updated CALCITE-4889:
---
Issue Type: Bug (was: Improvement)
> Double join is created for NOT IN
> -
>
> Key: CALCITE-4889
> URL: https://issues.apache.org/jira/browse/CALCITE-4889
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.28.0
>Reporter: Vladimir Sitnikov
>Priority: Major
>
> The following queries yield several joins in the plan.
> I think double joins are excessive here, especially for the first case where
> all the values are non-nullable.
> {code}select * from "scott".emp where (empno, deptno) not in ((7369, 20),
> (7499, 30));{code}
> {noformat}
> select * from "scott".emp where empno not in (null, 7782);
> EnumerableCalc(expr#0..12=[{inputs}], expr#13=[0:BIGINT], expr#14=[=($t8,
> $t13)], expr#15=[IS NULL($t12)], expr#16=[>=($t9, $t8)], expr#17=[AND($t15,
> $t16)], expr#18=[OR($t14, $t17)], proj#0..7=[{exprs}], $condition=[$t18])
> EnumerableMergeJoin(condition=[=($10, $11)], joinType=[left])
> EnumerableSort(sort0=[$10], dir0=[ASC])
> EnumerableCalc(expr#0..9=[{inputs}], proj#0..9=[{exprs}], EMPNO0=[$t0])
> EnumerableNestedLoopJoin(condition=[true], joinType=[inner])
> EnumerableTableScan(table=[[scott, EMP]])
> EnumerableAggregate(group=[{}], agg#0=[COUNT()], agg#1=[COUNT($0)])
> EnumerableValues(tuples=[[{ null }, { 7782 }]])
> EnumerableSort(sort0=[$0], dir0=[ASC])
> EnumerableCalc(expr#0=[{inputs}], expr#1=[true], proj#0..1=[{exprs}])
> EnumerableValues(tuples=[[{ null }, { 7782 }]])
> {noformat}
> {noformat}
> select * from "scott".emp where (empno, deptno) not in ((1, 2), (3, null));
> EnumerableCalc(expr#0..14=[{inputs}], expr#15=[0:BIGINT], expr#16=[=($t8,
> $t15)], expr#17=[IS NULL($t14)], expr#18=[>=($t9, $t8)], expr#19=[IS NOT
> NULL($t11)], expr#20=[AND($t17, $t18, $t19)], expr#21=[OR($t16, $t20)],
> proj#0..7=[{exprs}], $condition=[$t21])
> EnumerableMergeJoin(condition=[AND(=($10, $12), =($11, $13))],
> joinType=[left])
> EnumerableSort(sort0=[$10], sort1=[$11], dir0=[ASC], dir1=[ASC])
> EnumerableCalc(expr#0..9=[{inputs}], proj#0..9=[{exprs}], EMPNO0=[$t0],
> DEPTNO0=[$t7])
> EnumerableNestedLoopJoin(condition=[true], joinType=[inner])
> EnumerableTableScan(table=[[scott, EMP]])
> EnumerableAggregate(group=[{}], agg#0=[COUNT()], agg#1=[COUNT($0,
> $1)])
> EnumerableValues(tuples=[[{ 1, 2 }, { 3, null }]])
> EnumerableSort(sort0=[$0], sort1=[$1], dir0=[ASC], dir1=[ASC])
> EnumerableCalc(expr#0..1=[{inputs}], expr#2=[true], proj#0..2=[{exprs}])
> EnumerableValues(tuples=[[{ 1, 2 }, { 3, null }]])
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (CALCITE-4889) Double join is created for NOT IN
Vladimir Sitnikov created CALCITE-4889:
--
Summary: Double join is created for NOT IN
Key: CALCITE-4889
URL: https://issues.apache.org/jira/browse/CALCITE-4889
Project: Calcite
Issue Type: Improvement
Components: core
Affects Versions: 1.28.0
Reporter: Vladimir Sitnikov
The following queries yield several joins in the plan.
I think double joins are excessive here, especially for the first case where
all the values are non-nullable.
{code}select * from "scott".emp where (empno, deptno) not in ((7369, 20),
(7499, 30));{code}
{noformat}
select * from "scott".emp where empno not in (null, 7782);
EnumerableCalc(expr#0..12=[{inputs}], expr#13=[0:BIGINT], expr#14=[=($t8,
$t13)], expr#15=[IS NULL($t12)], expr#16=[>=($t9, $t8)], expr#17=[AND($t15,
$t16)], expr#18=[OR($t14, $t17)], proj#0..7=[{exprs}], $condition=[$t18])
EnumerableMergeJoin(condition=[=($10, $11)], joinType=[left])
EnumerableSort(sort0=[$10], dir0=[ASC])
EnumerableCalc(expr#0..9=[{inputs}], proj#0..9=[{exprs}], EMPNO0=[$t0])
EnumerableNestedLoopJoin(condition=[true], joinType=[inner])
EnumerableTableScan(table=[[scott, EMP]])
EnumerableAggregate(group=[{}], agg#0=[COUNT()], agg#1=[COUNT($0)])
EnumerableValues(tuples=[[{ null }, { 7782 }]])
EnumerableSort(sort0=[$0], dir0=[ASC])
EnumerableCalc(expr#0=[{inputs}], expr#1=[true], proj#0..1=[{exprs}])
EnumerableValues(tuples=[[{ null }, { 7782 }]])
{noformat}
{noformat}
select * from "scott".emp where (empno, deptno) not in ((1, 2), (3, null));
EnumerableCalc(expr#0..14=[{inputs}], expr#15=[0:BIGINT], expr#16=[=($t8,
$t15)], expr#17=[IS NULL($t14)], expr#18=[>=($t9, $t8)], expr#19=[IS NOT
NULL($t11)], expr#20=[AND($t17, $t18, $t19)], expr#21=[OR($t16, $t20)],
proj#0..7=[{exprs}], $condition=[$t21])
EnumerableMergeJoin(condition=[AND(=($10, $12), =($11, $13))],
joinType=[left])
EnumerableSort(sort0=[$10], sort1=[$11], dir0=[ASC], dir1=[ASC])
EnumerableCalc(expr#0..9=[{inputs}], proj#0..9=[{exprs}], EMPNO0=[$t0],
DEPTNO0=[$t7])
EnumerableNestedLoopJoin(condition=[true], joinType=[inner])
EnumerableTableScan(table=[[scott, EMP]])
EnumerableAggregate(group=[{}], agg#0=[COUNT()], agg#1=[COUNT($0,
$1)])
EnumerableValues(tuples=[[{ 1, 2 }, { 3, null }]])
EnumerableSort(sort0=[$0], sort1=[$1], dir0=[ASC], dir1=[ASC])
EnumerableCalc(expr#0..1=[{inputs}], expr#2=[true], proj#0..2=[{exprs}])
EnumerableValues(tuples=[[{ 1, 2 }, { 3, null }]])
{noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (CALCITE-4885) Fluent test fixtures so that dependent projects can write parser, validator and rules tests
[ https://issues.apache.org/jira/browse/CALCITE-4885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17443191#comment-17443191 ] Vladimir Sitnikov commented on CALCITE-4885: I do not mean hamcrest is forbidden, however, it is sad that new Matcher implementations appear in Calcite > Fluent test fixtures so that dependent projects can write parser, validator > and rules tests > > > Key: CALCITE-4885 > URL: https://issues.apache.org/jira/browse/CALCITE-4885 > Project: Calcite > Issue Type: Bug >Reporter: Julian Hyde >Assignee: Julian Hyde >Priority: Major > > Provide fluent test fixtures so that dependent projects can write parser, > validator and rules tests. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (CALCITE-4885) Fluent test fixtures so that dependent projects can write parser, validator and rules tests
[ https://issues.apache.org/jira/browse/CALCITE-4885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17443181#comment-17443181 ] Vladimir Sitnikov commented on CALCITE-4885: Creating new Matcher implementation is not that orthogonal. > Fluent test fixtures so that dependent projects can write parser, validator > and rules tests > > > Key: CALCITE-4885 > URL: https://issues.apache.org/jira/browse/CALCITE-4885 > Project: Calcite > Issue Type: Bug >Reporter: Julian Hyde >Assignee: Julian Hyde >Priority: Major > > Provide fluent test fixtures so that dependent projects can write parser, > validator and rules tests. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (CALCITE-4885) Fluent test fixtures so that dependent projects can write parser, validator and rules tests
[ https://issues.apache.org/jira/browse/CALCITE-4885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17442683#comment-17442683 ] Vladimir Sitnikov commented on CALCITE-4885: I suggest we move to AssertJ rather than continue Hamcrest-based approach: CALCITE-4659. Hamcreset matchers are hard to create, and hamcrest matches are hard to discover: they are written in "backwards" way, so one can't press autocomplete and see which assertions are available. > Fluent test fixtures so that dependent projects can write parser, validator > and rules tests > > > Key: CALCITE-4885 > URL: https://issues.apache.org/jira/browse/CALCITE-4885 > Project: Calcite > Issue Type: Bug >Reporter: Julian Hyde >Priority: Major > > Provide fluent test fixtures so that dependent projects can write parser, > validator and rules tests. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (CALCITE-4881) Calcite release tags should have rel/... prefix as per the ASF requirements
[ https://issues.apache.org/jira/browse/CALCITE-4881?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17440935#comment-17440935 ] Vladimir Sitnikov commented on CALCITE-4881: [~francischuang], can you have double tags for the release? ASF does not forbid having v.X.Y.Z. What they as is to have rel/... for the legal provenance. > Calcite release tags should have rel/... prefix as per the ASF requirements > --- > > Key: CALCITE-4881 > URL: https://issues.apache.org/jira/browse/CALCITE-4881 > Project: Calcite > Issue Type: Improvement >Reporter: Vladimir Sitnikov >Priority: Critical > > As per "Git status update" mail from Infra, release commits should be tagged > with rel/... tags which are protected at the Infra side so they can't be > overwritten, removed, etc. > See sample: ACCUMULO-4106 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (CALCITE-4881) Calcite release tags should have rel/... prefix as per the ASF requirements
[
https://issues.apache.org/jira/browse/CALCITE-4881?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17440936#comment-17440936
]
Vladimir Sitnikov commented on CALCITE-4881:
Just for the reference, Calcite release tags were named like {{rel/...}},
however, it was "broken" in
https://github.com/apache/calcite/commit/2e30293af7373b6c5fbcc5fa6505b49df2fba000
> Calcite release tags should have rel/... prefix as per the ASF requirements
> ---
>
> Key: CALCITE-4881
> URL: https://issues.apache.org/jira/browse/CALCITE-4881
> Project: Calcite
> Issue Type: Improvement
>Reporter: Vladimir Sitnikov
>Priority: Critical
>
> As per "Git status update" mail from Infra, release commits should be tagged
> with rel/... tags which are protected at the Infra side so they can't be
> overwritten, removed, etc.
> See sample: ACCUMULO-4106
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (CALCITE-4881) Calcite release tags should have rel/... prefix as per the ASF requirements
Vladimir Sitnikov created CALCITE-4881: -- Summary: Calcite release tags should have rel/... prefix as per the ASF requirements Key: CALCITE-4881 URL: https://issues.apache.org/jira/browse/CALCITE-4881 Project: Calcite Issue Type: Improvement Reporter: Vladimir Sitnikov As per "Git status update" mail from Infra, release commits should be tagged with rel/... tags which are protected at the Infra side so they can't be overwritten, removed, etc. See sample: ACCUMULO-4106 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (CALCITE-4877) Make the exception information of class not found more explicit
[
https://issues.apache.org/jira/browse/CALCITE-4877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17439947#comment-17439947
]
Vladimir Sitnikov commented on CALCITE-4877:
[~sunjincheng121], thanks for the PR!
> Make the exception information of class not found more explicit
> ---
>
> Key: CALCITE-4877
> URL: https://issues.apache.org/jira/browse/CALCITE-4877
> Project: Calcite
> Issue Type: Improvement
> Components: avatica
>Reporter: sunjincheng
>Assignee: sunjincheng
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.29.0
>
> Attachments: image-2021-11-06-07-03-57-742.png
>
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
> Make the exception information of class not found more explicit when we want
> REATE SCHEMA or CREATE TABLE supported.
> when we not add the class to the class path we got the exception as follows:
> {code}
> Error: Error while executing SQL "CREATE TABLE t (i INTEGER, j VARCHAR(10))":
> Property 'org.apache.calcite.sql.parser.ddl.SqlDdlParserImpl#FACTORY' not
> valid for plugin type org.apache.calcite.sql.parser.SqlParserImplFactory
> (state=,code=0)
> {code}
> !image-2021-11-06-07-03-57-742.png!
> {code}
> would be great if we can make the error message more explicit , such as:
> "Property 'org.apache.calcite.sql.parser.ddl.SqlDdlParserImpl#FACTORY' not
> valid as 'org.apache.calcite.sql.parser.ddl.SqlDdlParserImpl' not found in
> the classpath."
> {code}
> What do you think？
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Resolved] (CALCITE-4877) Make the exception information of class not found more explicit
[
https://issues.apache.org/jira/browse/CALCITE-4877?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Sitnikov resolved CALCITE-4877.
Resolution: Fixed
Fixed in
https://github.com/apache/calcite-avatica/commit/434cf002f00fc5051f8a89cbf14df256ca77b3aa
> Make the exception information of class not found more explicit
> ---
>
> Key: CALCITE-4877
> URL: https://issues.apache.org/jira/browse/CALCITE-4877
> Project: Calcite
> Issue Type: Improvement
> Components: avatica
>Reporter: sunjincheng
>Assignee: sunjincheng
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.29.0
>
> Attachments: image-2021-11-06-07-03-57-742.png
>
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
> Make the exception information of class not found more explicit when we want
> REATE SCHEMA or CREATE TABLE supported.
> when we not add the class to the class path we got the exception as follows:
> {code}
> Error: Error while executing SQL "CREATE TABLE t (i INTEGER, j VARCHAR(10))":
> Property 'org.apache.calcite.sql.parser.ddl.SqlDdlParserImpl#FACTORY' not
> valid for plugin type org.apache.calcite.sql.parser.SqlParserImplFactory
> (state=,code=0)
> {code}
> !image-2021-11-06-07-03-57-742.png!
> {code}
> would be great if we can make the error message more explicit , such as:
> "Property 'org.apache.calcite.sql.parser.ddl.SqlDdlParserImpl#FACTORY' not
> valid as 'org.apache.calcite.sql.parser.ddl.SqlDdlParserImpl' not found in
> the classpath."
> {code}
> What do you think？
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Resolved] (CALCITE-4131) the XmlFunctions exception handled by System.out
[
https://issues.apache.org/jira/browse/CALCITE-4131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Sitnikov resolved CALCITE-4131.
Fix Version/s: 1.29.0
Resolution: Fixed
Fixed in
https://github.com/apache/calcite/commit/f1db79fb876ac9ba3c405283e99bb0438e4e97be
> the XmlFunctions exception handled by System.out
>
>
> Key: CALCITE-4131
> URL: https://issues.apache.org/jira/browse/CALCITE-4131
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: Haisheng Yuan
>Assignee: duan xiong
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.29.0
>
> Attachments: after apply the PR.png, before apply the PR.png
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> The error doesn't affect the proceeding of the test suite, and doesn't fail
> the test. But the error message is not so pleasing:
> {code:java}
> SqlToRelConverterExtendedTest > testCrossJoinLateral1() STANDARD_ERROR
> [Fatal Error] :1:2: XML document structures must start and end within the
> same entity.
> ERROR: 'Could not compile stylesheet'
> FATAL ERROR: 'XML document structures must start and end within the same
> entity.'
>:XML document structures must start and end within the same
> entity.
> SqlToRelConverterExtendedTest > testMatchRecognizeIn() STANDARD_ERROR
> ERROR: 'XML document structures must start and end within the same
> entity.'
> ERROR: 'com.sun.org.apache.xml.internal.utils.WrappedRuntimeException:
> XML document structures must start and end within the same entity.'
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (CALCITE-2040) Create adapter for Apache Arrow
[ https://issues.apache.org/jira/browse/CALCITE-2040?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17439422#comment-17439422 ] Vladimir Sitnikov commented on CALCITE-2040: [~Karshit Shah], have you considered running "ArrowData" as a part of the test? (e.g. via JUnit @TempDir, etc , etc). > Create adapter for Apache Arrow > --- > > Key: CALCITE-2040 > URL: https://issues.apache.org/jira/browse/CALCITE-2040 > Project: Calcite > Issue Type: Bug >Reporter: Julian Hyde >Assignee: Julian Hyde >Priority: Major > Labels: pull-request-available > Attachments: arrow_data.py > > Time Spent: 1h > Remaining Estimate: 0h > > Create an adapter for [Apache Arrow|http://arrow.apache.org/]. This would > allow people to execute SQL statements, via JDBC or ODBC, on data stored in > Arrow in-memory format. > Since Arrow is an in-memory format, it is not as straightforward as reading, > say, CSV files using the file adapter: an Arrow data set does not have a URL. > (Unless we use Arrow's > [Feather|https://blog.cloudera.com/blog/2016/03/feather-a-fast-on-disk-format-for-data-frames-for-r-and-python-powered-by-apache-arrow/] > format, or use an in-memory file system such as Alluxio.) So we would need > to devise a way of addressing Arrow data sets. > Also, since Arrow is an extremely efficient format for processing data, it > would also be good to have Arrow as a calling convention. That is, > implementations of relational operators such as Filter, Project, Aggregate in > addition to just TableScan. > Lastly, when we have an Arrow convention, if we build adapters for file > formats (for instance the bioinformatics formats SAM, VCF, FASTQ discussed in > CALCITE-2025) it would make a lot of sense to translate those formats > directly into Arrow (applying simple projects and filters first if > applicable). Those adapters would belong as a "contrib" module in the Arrow > project better than in Calcite. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-4853) Gradle could not determine the dependencies of task ':syncPreviewSiteRepo'
[
https://issues.apache.org/jira/browse/CALCITE-4853?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17429454#comment-17429454
]
Vladimir Sitnikov commented on CALCITE-4853:
Oh. Avatica still uses com.github.vlsi.vlsi-release-plugins.version=1.70, so
I'm puzzled where did I encounter the issue for the first time.
> Gradle could not determine the dependencies of task ':syncPreviewSiteRepo'
> --
>
> Key: CALCITE-4853
> URL: https://issues.apache.org/jira/browse/CALCITE-4853
> Project: Calcite
> Issue Type: Bug
> Components: build
>Reporter: Julian Hyde
>Assignee: Stamatis Zampetakis
>Priority: Major
> Fix For: 1.28.0
>
>
> I got the following error while following the instructions to [make a Calcite
> release
> candidate|https://calcite.apache.org/docs/howto.html#making-a-release-candidate].
> {noformat}
> $ ./gradlew prepareVote -Prc=0
> Starting a Gradle Daemon, 1 incompatible Daemon could not be reused, use
> --status for details
> > Configure project :
> Building Apache Calcite 1.28.0
> FAILURE: Build failed with an exception.
> * What went wrong:
> Could not determine the dependencies of task ':syncPreviewSiteRepo'.
> > Could not resolve all dependencies for configuration ':previewSite'.
>> Querying the mapped value of flatmap(provider(task 'distTar', class
> org.gradle.api.tasks.bundling.Tar)) before task ':release:distTar' has
> completed is not supported
> * Try:
> Run with --stacktrace option to get the stack trace. Run with --info or
> --debug option to get more log output. Run with --scan to get full insights.
> * Get more help at https://help.gradle.org
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-4853) Gradle could not determine the dependencies of task ':syncPreviewSiteRepo'
[
https://issues.apache.org/jira/browse/CALCITE-4853?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17429451#comment-17429451
]
Vladimir Sitnikov commented on CALCITE-4853:
[~zabetak], thanks for looking into this.
I was sure I saw an issue like that, so I was planning a debugging session, and
I completely forgot I updated release-plugins only for Avatica.
> Gradle could not determine the dependencies of task ':syncPreviewSiteRepo'
> --
>
> Key: CALCITE-4853
> URL: https://issues.apache.org/jira/browse/CALCITE-4853
> Project: Calcite
> Issue Type: Bug
> Components: build
>Reporter: Julian Hyde
>Assignee: Stamatis Zampetakis
>Priority: Major
> Fix For: 1.28.0
>
>
> I got the following error while following the instructions to [make a Calcite
> release
> candidate|https://calcite.apache.org/docs/howto.html#making-a-release-candidate].
> {noformat}
> $ ./gradlew prepareVote -Prc=0
> Starting a Gradle Daemon, 1 incompatible Daemon could not be reused, use
> --status for details
> > Configure project :
> Building Apache Calcite 1.28.0
> FAILURE: Build failed with an exception.
> * What went wrong:
> Could not determine the dependencies of task ':syncPreviewSiteRepo'.
> > Could not resolve all dependencies for configuration ':previewSite'.
>> Querying the mapped value of flatmap(provider(task 'distTar', class
> org.gradle.api.tasks.bundling.Tar)) before task ':release:distTar' has
> completed is not supported
> * Try:
> Run with --stacktrace option to get the stack trace. Run with --info or
> --debug option to get more log output. Run with --scan to get full insights.
> * Get more help at https://help.gradle.org
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-4851) Lots of warnings about Execution optimizations have been disabled when build CALCITE
[
https://issues.apache.org/jira/browse/CALCITE-4851?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17429251#comment-17429251
]
Vladimir Sitnikov commented on CALCITE-4851:
What do you mean "makes build slower"? Do you have numbers for comparison?
AFAIK [~julianhyde] asked to explicitly refrain from any build modifications
before the release.
> Lots of warnings about Execution optimizations have been disabled when build
> CALCITE
>
>
> Key: CALCITE-4851
> URL: https://issues.apache.org/jira/browse/CALCITE-4851
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.27.0
> Environment: MacOS
> Gradle 7.2
> Jdk 11
>Reporter: duan xiong
>Priority: Major
>
> Lots of warnings about Execution optimizations have been disabled when build
> CALCITE. For example:
> {noformat}
> Execution optimizations have been disabled for task ':babel:sourcesJar' to
> ensure correctness due to the following reasons:
> - Gradle detected a problem with the following location:
> '/calcite/babel/build/javacc/javaCCMain'.
> Reason: Task ':babel:sourcesJar' uses this output of task ':babel:javaCCMain'
> without declaring an explicit or implicit dependency.
> This can lead to incorrect results being produced, depending on what order
> the tasks are executed. Please refer to
> https://docs.gradle.org/7.2/userguide/validation_problems.html#implicit_dependency
> for more details about this problem.{noformat}
> and
> {noformat}
> Gradle detected a problem with the following location: '/calcite'. Reason:
> Task ':gitProps' uses this output of task ':babel:checkstyleTest' without
> declaring an explicit or implicit dependency.
> This can lead to incorrect results being produced, depending on what order
> the tasks are executed. Please refer to
> https://docs.gradle.org/7.2/userguide/validation_problems.html#implicit_dependency
> for more details about this problem.{noformat}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (CALCITE-4832) Refactor Gradle to build-logic convention plugins
Vladimir Sitnikov created CALCITE-4832: -- Summary: Refactor Gradle to build-logic convention plugins Key: CALCITE-4832 URL: https://issues.apache.org/jira/browse/CALCITE-4832 Project: Calcite Issue Type: Improvement Components: build Reporter: Vladimir Sitnikov Assignee: Vladimir Sitnikov See https://docs.gradle.org/current/userguide/structuring_software_products.html -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (CALCITE-4821) Move utility test classes into calcite-testkit and unpublish -test.jar
[
https://issues.apache.org/jira/browse/CALCITE-4821?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Sitnikov resolved CALCITE-4821.
Fix Version/s: 1.28.0
Resolution: Fixed
Fixed in
https://github.com/apache/calcite/pull/2558/commits/ef40b524936d9d0497deebcb5be2139502a052e1
> Move utility test classes into calcite-testkit and unpublish -test.jar
> --
>
> Key: CALCITE-4821
> URL: https://issues.apache.org/jira/browse/CALCITE-4821
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: Vladimir Sitnikov
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.28.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> -test.jar make it hard to support build configuration, and it blocks
> migration to Gradle 7.
> As we move the commonly used classes to its own -testkit module, it would
> make it easier to reuse test helpers, it would make easier to recognize the
> Test API vs {{@Test}} code, and it would make certain classes smaller. E.g.
> CatchAllSchema is currently located in ReflectiveSchemaTest, and if we move
> it to a top-level class, then ReflectiveSchemaTest would be smaller.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (CALCITE-4823) JEP 411: AccessControlException, AccessController in java.security has been deprecated and marked for removal
[
https://issues.apache.org/jira/browse/CALCITE-4823?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Sitnikov resolved CALCITE-4823.
Resolution: Fixed
Fixed in
https://github.com/apache/calcite/pull/2558/commits/2fdc5370e8b3bdec6d21b202f5f9fbe54f3f7837
> JEP 411: AccessControlException, AccessController in java.security has been
> deprecated and marked for removal
> -
>
> Key: CALCITE-4823
> URL: https://issues.apache.org/jira/browse/CALCITE-4823
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: Vladimir Sitnikov
>Priority: Major
>
> Calcite uses java.security APIs that have been marked for removal.
> Let's minimize the usages of java.security for now.
> {noformat}
> /Users/runner/work/calcite/calcite/core/src/main/java/org/apache/calcite/util/SaffronProperties.java:28:
> warning: [removal] AccessControlException in java.security has been
> deprecated and marked for removal
> import java.security.AccessControlException;
> ^
> /Users/runner/work/calcite/calcite/core/src/main/java/org/apache/calcite/config/CalciteSystemProperty.java:27:
> warning: [removal] AccessControlException in java.security has been
> deprecated and marked for removal
> import java.security.AccessControlException;
> ^
> error: warnings found and -Werror specified
> /Users/runner/work/calcite/calcite/core/src/main/java/org/apache/calcite/runtime/Resources.java:991:
> warning: [removal] AccessController in java.security has been deprecated and
> marked for removal
> return java.security.AccessController.doPrivileged(
> ^
> /Users/runner/work/calcite/calcite/core/src/main/java/org/apache/calcite/util/SaffronProperties.java:137:
> warning: [removal] AccessControlException in java.security has been
> deprecated and marked for removal
> } catch (AccessControlException e) {
>^
> /Users/runner/work/calcite/calcite/core/src/main/java/org/apache/calcite/config/CalciteSystemProperty.java:439:
> warning: [removal] AccessControlException in java.security has been
> deprecated and marked for removal
> } catch (AccessControlException e) {
> ^
> Note: Some input files use unchecked or unsafe operations.
> Note: Recompile with -Xlint:unchecked for details.
> 1 error
> 5 warnings
> :core:compileJava failure marker
> {noformat}
> What do we do with that?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-4823) JEP 411: AccessControlException, AccessController in java.security has been deprecated and marked for removal
[
https://issues.apache.org/jira/browse/CALCITE-4823?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Sitnikov updated CALCITE-4823:
---
Fix Version/s: 1.28.0
> JEP 411: AccessControlException, AccessController in java.security has been
> deprecated and marked for removal
> -
>
> Key: CALCITE-4823
> URL: https://issues.apache.org/jira/browse/CALCITE-4823
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: Vladimir Sitnikov
>Priority: Major
> Fix For: 1.28.0
>
>
> Calcite uses java.security APIs that have been marked for removal.
> Let's minimize the usages of java.security for now.
> {noformat}
> /Users/runner/work/calcite/calcite/core/src/main/java/org/apache/calcite/util/SaffronProperties.java:28:
> warning: [removal] AccessControlException in java.security has been
> deprecated and marked for removal
> import java.security.AccessControlException;
> ^
> /Users/runner/work/calcite/calcite/core/src/main/java/org/apache/calcite/config/CalciteSystemProperty.java:27:
> warning: [removal] AccessControlException in java.security has been
> deprecated and marked for removal
> import java.security.AccessControlException;
> ^
> error: warnings found and -Werror specified
> /Users/runner/work/calcite/calcite/core/src/main/java/org/apache/calcite/runtime/Resources.java:991:
> warning: [removal] AccessController in java.security has been deprecated and
> marked for removal
> return java.security.AccessController.doPrivileged(
> ^
> /Users/runner/work/calcite/calcite/core/src/main/java/org/apache/calcite/util/SaffronProperties.java:137:
> warning: [removal] AccessControlException in java.security has been
> deprecated and marked for removal
> } catch (AccessControlException e) {
>^
> /Users/runner/work/calcite/calcite/core/src/main/java/org/apache/calcite/config/CalciteSystemProperty.java:439:
> warning: [removal] AccessControlException in java.security has been
> deprecated and marked for removal
> } catch (AccessControlException e) {
> ^
> Note: Some input files use unchecked or unsafe operations.
> Note: Recompile with -Xlint:unchecked for details.
> 1 error
> 5 warnings
> :core:compileJava failure marker
> {noformat}
> What do we do with that?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (CALCITE-4829) Bump Gradle to 7.2 and test with Java 17 at GitHub Actions
[ https://issues.apache.org/jira/browse/CALCITE-4829?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Sitnikov resolved CALCITE-4829. Fix Version/s: 1.28.0 Resolution: Fixed Fixed in https://github.com/apache/calcite/pull/2558/commits/a8a6569e6ba75efe9d5725c49338a7f181d3ab5c > Bump Gradle to 7.2 and test with Java 17 at GitHub Actions > -- > > Key: CALCITE-4829 > URL: https://issues.apache.org/jira/browse/CALCITE-4829 > Project: Calcite > Issue Type: Improvement > Components: build, core >Reporter: Vladimir Sitnikov >Priority: Major > Fix For: 1.28.0 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CALCITE-4547) Support Java 16
[ https://issues.apache.org/jira/browse/CALCITE-4547?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Sitnikov updated CALCITE-4547: --- Summary: Support Java 16 (was: Support Java 17) > Support Java 16 > --- > > Key: CALCITE-4547 > URL: https://issues.apache.org/jira/browse/CALCITE-4547 > Project: Calcite > Issue Type: Bug >Reporter: Julian Hyde >Assignee: Julian Hyde >Priority: Major > Labels: pull-request-available > Time Spent: 10m > Remaining Estimate: 0h > > Support building and running on [Java 16|https://jdk.java.net/16/] (OpenJDK > 16). > This will require an [upgrade to Gradle > 7|https://melix.github.io/blog/2021/03/gradle-java16.html], because Gradle 6 > will not support Java 16. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CALCITE-4829) Bump Gradle to 7.2 and test with Java 17 at GitHub Actions
Vladimir Sitnikov created CALCITE-4829: -- Summary: Bump Gradle to 7.2 and test with Java 17 at GitHub Actions Key: CALCITE-4829 URL: https://issues.apache.org/jira/browse/CALCITE-4829 Project: Calcite Issue Type: Improvement Components: build, core Reporter: Vladimir Sitnikov -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-4547) Support Java 16
[ https://issues.apache.org/jira/browse/CALCITE-4547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17424380#comment-17424380 ] Vladimir Sitnikov commented on CALCITE-4547: I reverted the subject > Support Java 16 > --- > > Key: CALCITE-4547 > URL: https://issues.apache.org/jira/browse/CALCITE-4547 > Project: Calcite > Issue Type: Bug >Reporter: Julian Hyde >Assignee: Julian Hyde >Priority: Major > Labels: pull-request-available > Time Spent: 10m > Remaining Estimate: 0h > > Support building and running on [Java 16|https://jdk.java.net/16/] (OpenJDK > 16). > This will require an [upgrade to Gradle > 7|https://melix.github.io/blog/2021/03/gradle-java16.html], because Gradle 6 > will not support Java 16. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-4826) annotationProcessorMain task is misconfigured in core gradle build, causing sync to fail in Intellij
[
https://issues.apache.org/jira/browse/CALCITE-4826?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17424116#comment-17424116
]
Vladimir Sitnikov commented on CALCITE-4826:
I think {{git push --force-with-lease ..}} is reasonable for the cases like
this.
> annotationProcessorMain task is misconfigured in core gradle build, causing
> sync to fail in Intellij
>
>
> Key: CALCITE-4826
> URL: https://issues.apache.org/jira/browse/CALCITE-4826
> Project: Calcite
> Issue Type: Bug
>Reporter: Jacques Nadeau
>Assignee: Jacques Nadeau
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.28.0
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> After CALCITE-4787, Intellij will fail when syncing with:
> {quote}{{A problem was found with the configuration of task
> ':core:annotationProcessorMain' (type 'JavaCompile').}}
> {{> No value has been specified for property 'destinationDirectory'.}}
> {quote}
>
> This property was removed and tested in the Intellij before the merge but
> apparently was tested incorrectly. Adding it back fixes the issue.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-4826) Fix Intellij annotation processing failure post CALCITE-4787
[
https://issues.apache.org/jira/browse/CALCITE-4826?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17424061#comment-17424061
]
Vladimir Sitnikov commented on CALCITE-4826:
Just force push all the way! :)
> Fix Intellij annotation processing failure post CALCITE-4787
>
>
> Key: CALCITE-4826
> URL: https://issues.apache.org/jira/browse/CALCITE-4826
> Project: Calcite
> Issue Type: Bug
>Reporter: Jacques Nadeau
>Assignee: Jacques Nadeau
>Priority: Major
>
> After CALCITE-4787, Intellij will fail when syncing with:
> {quote}{{A problem was found with the configuration of task
> ':core:annotationProcessorMain' (type 'JavaCompile').}}
> {{> No value has been specified for property 'destinationDirectory'.}}
> {quote}
>
> This property was removed and tested in the Intellij before the merge but
> apparently was tested incorrectly. Adding it back fixes the issue.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-4824) ServerUnParserTest#testCreateTableVirtualColumn fails
[
https://issues.apache.org/jira/browse/CALCITE-4824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17423958#comment-17423958
]
Vladimir Sitnikov commented on CALCITE-4824:
A similar case:
{noformat}
> java.sql.SQLException: Error while executing SQL "insert into t values
(1, 2)": At line 1, column 13: Number of INSERT target columns (3) does not
equal number of source items (2)
> 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.executeLargeUpdate(AvaticaStatement.java:246)
> at
org.apache.calcite.avatica.AvaticaStatement.executeUpdate(AvaticaStatement.java:240)
> at net.hydromatic.quidem.Quidem.update(Quidem.java:279)
> at net.hydromatic.quidem.Quidem.access$2900(Quidem.java:54)
> at net.hydromatic.quidem.Quidem$ContextImpl.update(Quidem.java:1752)
> at net.hydromatic.quidem.Quidem$UpdateCommand.execute(Quidem.java:1152)
> 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:156)
> at org.apache.calcite.test.QuidemTest.test(QuidemTest.java:207)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
org.junit.platform.commons.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:725)
> at
org.junit.jupiter.engine.execution.MethodInvocation.proceed(MethodInvocation.java:60)
> at
org.junit.jupiter.engine.execution.InvocationInterceptorChain$ValidatingInvocation.proceed(InvocationInterceptorChain.java:131)
> at
org.junit.jupiter.engine.extension.TimeoutInvocation.proceed(TimeoutInvocation.java:46)
> at
org.junit.jupiter.engine.extension.TimeoutExtension.intercept(TimeoutExtension.java:149)
> at
org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestableMethod(TimeoutExtension.java:140)
> at
org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestTemplateMethod(TimeoutExtension.java:92)
> at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:918)
> at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:903)
> at
org.apache.calcite.sql.validate.SqlValidatorImpl.newValidationError(SqlValidatorImpl.java:5266)
> at
org.apache.calcite.sql.validate.SqlValidatorImpl.checkFieldCount(SqlValidatorImpl.java:4761)
> at
org.apache.calcite.sql.validate.SqlValidatorImpl.validateInsert(SqlValidatorImpl.java:4617)
> at org.apache.calcite.sql.SqlInsert.validate(SqlInsert.java:166)
> 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)
> ... 116 more
> Caused by: org.apache.calcite.sql.validate.SqlValidatorException: Number
of INSERT target columns (3) does not equal number of source items (2)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> at
org.apache.calcite.runtime.Resources$ExInstWithCause.ex(Resources.java:505)
> at
[jira] [Created] (CALCITE-4824) ServerUnParserTest#testCreateTableVirtualColumn fails
Vladimir Sitnikov created CALCITE-4824:
--
Summary: ServerUnParserTest#testCreateTableVirtualColumn fails
Key: CALCITE-4824
URL: https://issues.apache.org/jira/browse/CALCITE-4824
Project: Calcite
Issue Type: Improvement
Components: server
Reporter: Vladimir Sitnikov
It looks like {{org.apache.calcite.server.ServerDdlExecutor#INSTANCE}} results
in non-synchronized HashMap instances in ReflectUtil.
Sample failure:
{noformat}
ServerUnParserTest > testCreateTableVirtualColumn() STANDARD_ERROR
log4j:WARN No appenders could be found for logger
(org.apache.calcite.sql.parser).
log4j:WARN Please initialize the log4j system properly.
log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for
more info.
WARNING 2.8sec, 442 completed, 0 failed, 5 skipped,
org.apache.calcite.test.ServerParserTest
WARNING 3.8sec, 442 completed, 0 failed, 6 skipped,
org.apache.calcite.test.ServerUnParserTest
2.2sec, org.apache.calcite.test.ServerTest > testVirtualColumn()
org.apache.calcite.test.ServerQuidemTest > test(String)[3], [3] sql\table.iq
failure marker
FAILURE 3.6sec, org.apache.calcite.test.ServerQuidemTest > test(String)[3],
[3] sql\table.iq
org.opentest4j.AssertionFailedError: Files differ:
D:\a\calcite\calcite\server\build\resources\test\sql\surefire\sql\table.iq
D:\a\calcite\calcite\server\build\resources\test\sql\table.iq
23c23,155
< (0 rows modified)
---
> java.sql.SQLException: Error while executing SQL "create table t (i int,
j int not null)": Method not found: execute([class
org.apache.calcite.sql.SqlNode, interface
org.apache.calcite.jdbc.CalcitePrepare$Context])
> 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.executeLargeUpdate(AvaticaStatement.java:246)
> at
org.apache.calcite.avatica.AvaticaStatement.executeUpdate(AvaticaStatement.java:240)
> at net.hydromatic.quidem.Quidem.update(Quidem.java:279)
> at net.hydromatic.quidem.Quidem.access$2900(Quidem.java:54)
> at net.hydromatic.quidem.Quidem$ContextImpl.update(Quidem.java:1752)
> at net.hydromatic.quidem.Quidem$UpdateCommand.execute(Quidem.java:1152)
> 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:156)
> at
org.junit.platform.engine.support.hierarchical.NodeTestTask.execute(NodeTestTask.java:95)
> at
org.junit.platform.engine.support.hierarchical.ForkJoinPoolHierarchicalTestExecutorService$ExclusiveTask.compute(ForkJoinPoolHierarchicalTestExecutorService.java:185)
> at java.util.concurrent.RecursiveAction.exec(RecursiveAction.java:189)
> at java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:289)
> at
java.util.concurrent.ForkJoinPool$WorkQueue.runTask(ForkJoinPool.java:1056)
> at java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1692)
> at
java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:175)
> Caused by: java.lang.IllegalArgumentException: Method not found:
execute([class org.apache.calcite.sql.SqlNode, interface
org.apache.calcite.jdbc.CalcitePrepare$Context])
> at
org.apache.calcite.util.ReflectUtil$2.lookupMethod(ReflectUtil.java:563)
> at org.apache.calcite.util.ReflectUtil$2.invoke(ReflectUtil.java:527)
> at
org.apache.calcite.server.DdlExecutorImpl.executeDdl(DdlExecutorImpl.java:41)
> at
org.apache.calcite.prepare.CalcitePrepareImpl.executeDdl(CalcitePrepareImpl.java:369)
> at
org.apache.calcite.prepare.CalcitePrepareImpl.prepare2_(CalcitePrepareImpl.java:634)
> 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)
> ... 116 more
{noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-4547) Support Java 17
[ https://issues.apache.org/jira/browse/CALCITE-4547?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Sitnikov updated CALCITE-4547: --- Summary: Support Java 17 (was: Support Java 16) > Support Java 17 > --- > > Key: CALCITE-4547 > URL: https://issues.apache.org/jira/browse/CALCITE-4547 > Project: Calcite > Issue Type: Bug >Reporter: Julian Hyde >Assignee: Julian Hyde >Priority: Major > Labels: pull-request-available > Time Spent: 10m > Remaining Estimate: 0h > > Support building and running on [Java 16|https://jdk.java.net/16/] (OpenJDK > 16). > This will require an [upgrade to Gradle > 7|https://melix.github.io/blog/2021/03/gradle-java16.html], because Gradle 6 > will not support Java 16. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CALCITE-4823) JEP 411: AccessControlException, AccessController in java.security has been deprecated and marked for removal
Vladimir Sitnikov created CALCITE-4823:
--
Summary: JEP 411: AccessControlException, AccessController in
java.security has been deprecated and marked for removal
Key: CALCITE-4823
URL: https://issues.apache.org/jira/browse/CALCITE-4823
Project: Calcite
Issue Type: Improvement
Components: core
Reporter: Vladimir Sitnikov
Calcite uses java.security APIs that have been marked for removal.
Let's minimize the usages of java.security for now.
{noformat}
/Users/runner/work/calcite/calcite/core/src/main/java/org/apache/calcite/util/SaffronProperties.java:28:
warning: [removal] AccessControlException in java.security has been deprecated
and marked for removal
import java.security.AccessControlException;
^
/Users/runner/work/calcite/calcite/core/src/main/java/org/apache/calcite/config/CalciteSystemProperty.java:27:
warning: [removal] AccessControlException in java.security has been deprecated
and marked for removal
import java.security.AccessControlException;
^
error: warnings found and -Werror specified
/Users/runner/work/calcite/calcite/core/src/main/java/org/apache/calcite/runtime/Resources.java:991:
warning: [removal] AccessController in java.security has been deprecated and
marked for removal
return java.security.AccessController.doPrivileged(
^
/Users/runner/work/calcite/calcite/core/src/main/java/org/apache/calcite/util/SaffronProperties.java:137:
warning: [removal] AccessControlException in java.security has been deprecated
and marked for removal
} catch (AccessControlException e) {
^
/Users/runner/work/calcite/calcite/core/src/main/java/org/apache/calcite/config/CalciteSystemProperty.java:439:
warning: [removal] AccessControlException in java.security has been deprecated
and marked for removal
} catch (AccessControlException e) {
^
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.
1 error
5 warnings
:core:compileJava failure marker
{noformat}
What do we do with that?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (CALCITE-4821) Move utility test classes into calcite-testkit and unpublish -test.jar
Vladimir Sitnikov created CALCITE-4821:
--
Summary: Move utility test classes into calcite-testkit and
unpublish -test.jar
Key: CALCITE-4821
URL: https://issues.apache.org/jira/browse/CALCITE-4821
Project: Calcite
Issue Type: Improvement
Components: core
Reporter: Vladimir Sitnikov
-test.jar make it hard to support build configuration, and it blocks migration
to Gradle 7.
As we move the commonly used classes to its own -testkit module, it would make
it easier to reuse test helpers, it would make easier to recognize the Test API
vs {{@Test}} code, and it would make certain classes smaller. E.g.
CatchAllSchema is currently located in ReflectiveSchemaTest, and if we move it
to a top-level class, then ReflectiveSchemaTest would be smaller.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (CALCITE-4815) Avatica's Travis fails with 'LICENSE-like files are missing' error
[
https://issues.apache.org/jira/browse/CALCITE-4815?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17423544#comment-17423544
]
Vladimir Sitnikov edited comment on CALCITE-4815 at 10/2/21, 6:57 PM:
--
Gradle tasks can be skipped with -x taskName
was (Author: vladimirsitnikov):
How about adding a constraint for that version as well?
Gradle tasks can be skipped with -x taskName
> Avatica's Travis fails with 'LICENSE-like files are missing' error
> --
>
> Key: CALCITE-4815
> URL: https://issues.apache.org/jira/browse/CALCITE-4815
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Reporter: Julian Hyde
>Assignee: Vladimir Sitnikov
>Priority: Major
> Fix For: avatica-1.19.0
>
>
> Some configurations of Avatica's Travis CI job fail with the following error.
> {noformat}
> > Task :standalone-server:classes
> > Task :standalone-server:getLicenses FAILED
> > Task :server:checkstyleTest
> Build [0;1mcalcite-avatica [0;1;31mFAILURE[0;1m[0m reason:
>
> Execution [0;1;31mfailed[0m for task
> '[0;1m:standalone-server:getLicenses[0m':
> LICENSE-like files are missing
> ==
>
> MIT
> * org.checkerframework:checker-qual:2.11.1
>
> at
> com.github.vlsi.gradle.license.GatherLicenseTask.run(GatherLicenseTask.kt:417)
> at org.gradle.internal.reflect.JavaMethod.invoke(JavaMethod.java:104)
> at
> org.gradle.api.internal.project.taskfactory.StandardTaskAction.doExecute(StandardTaskAction.java:58)
> FAILURE: Build failed with an exception.
> * What went wrong:
> Execution failed for task ':standalone-server:getLicenses'.
> > LICENSE-like files are missing
> ==
>
> MIT
> * org.checkerframework:checker-qual:2.11.1
> {noformat}
>
> [~vlsi], Do you have any idea what's going on? Avatica doesn't even use
> checkerframework. You can see the build output (for a few days) at
> [https://app.travis-ci.com/github/julianhyde/calcite-avatica/builds/238877621].
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-4815) Avatica's Travis fails with 'LICENSE-like files are missing' error
[
https://issues.apache.org/jira/browse/CALCITE-4815?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17423582#comment-17423582
]
Vladimir Sitnikov commented on CALCITE-4815:
I suggest we exclude org.codehaus.mojo:animal-sniffer-annotations dependency
since it is not really needed for Avatica, and it has been removed from the
recent Guava versions as well.
We should not claim "we support Guava 22" if we have a known licensing issue
with that version.
> Avatica's Travis fails with 'LICENSE-like files are missing' error
> --
>
> Key: CALCITE-4815
> URL: https://issues.apache.org/jira/browse/CALCITE-4815
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Reporter: Julian Hyde
>Assignee: Vladimir Sitnikov
>Priority: Major
> Fix For: avatica-1.19.0
>
>
> Some configurations of Avatica's Travis CI job fail with the following error.
> {noformat}
> > Task :standalone-server:classes
> > Task :standalone-server:getLicenses FAILED
> > Task :server:checkstyleTest
> Build [0;1mcalcite-avatica [0;1;31mFAILURE[0;1m[0m reason:
>
> Execution [0;1;31mfailed[0m for task
> '[0;1m:standalone-server:getLicenses[0m':
> LICENSE-like files are missing
> ==
>
> MIT
> * org.checkerframework:checker-qual:2.11.1
>
> at
> com.github.vlsi.gradle.license.GatherLicenseTask.run(GatherLicenseTask.kt:417)
> at org.gradle.internal.reflect.JavaMethod.invoke(JavaMethod.java:104)
> at
> org.gradle.api.internal.project.taskfactory.StandardTaskAction.doExecute(StandardTaskAction.java:58)
> FAILURE: Build failed with an exception.
> * What went wrong:
> Execution failed for task ':standalone-server:getLicenses'.
> > LICENSE-like files are missing
> ==
>
> MIT
> * org.checkerframework:checker-qual:2.11.1
> {noformat}
>
> [~vlsi], Do you have any idea what's going on? Avatica doesn't even use
> checkerframework. You can see the build output (for a few days) at
> [https://app.travis-ci.com/github/julianhyde/calcite-avatica/builds/238877621].
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-4815) Avatica's Travis fails with 'LICENSE-like files are missing' error
[
https://issues.apache.org/jira/browse/CALCITE-4815?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17423544#comment-17423544
]
Vladimir Sitnikov commented on CALCITE-4815:
How about adding a constraint for that version as well?
Gradle tasks can be skipped with -x taskName
> Avatica's Travis fails with 'LICENSE-like files are missing' error
> --
>
> Key: CALCITE-4815
> URL: https://issues.apache.org/jira/browse/CALCITE-4815
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Reporter: Julian Hyde
>Assignee: Vladimir Sitnikov
>Priority: Major
> Fix For: avatica-1.19.0
>
>
> Some configurations of Avatica's Travis CI job fail with the following error.
> {noformat}
> > Task :standalone-server:classes
> > Task :standalone-server:getLicenses FAILED
> > Task :server:checkstyleTest
> Build [0;1mcalcite-avatica [0;1;31mFAILURE[0;1m[0m reason:
>
> Execution [0;1;31mfailed[0m for task
> '[0;1m:standalone-server:getLicenses[0m':
> LICENSE-like files are missing
> ==
>
> MIT
> * org.checkerframework:checker-qual:2.11.1
>
> at
> com.github.vlsi.gradle.license.GatherLicenseTask.run(GatherLicenseTask.kt:417)
> at org.gradle.internal.reflect.JavaMethod.invoke(JavaMethod.java:104)
> at
> org.gradle.api.internal.project.taskfactory.StandardTaskAction.doExecute(StandardTaskAction.java:58)
> FAILURE: Build failed with an exception.
> * What went wrong:
> Execution failed for task ':standalone-server:getLicenses'.
> > LICENSE-like files are missing
> ==
>
> MIT
> * org.checkerframework:checker-qual:2.11.1
> {noformat}
>
> [~vlsi], Do you have any idea what's going on? Avatica doesn't even use
> checkerframework. You can see the build output (for a few days) at
> [https://app.travis-ci.com/github/julianhyde/calcite-avatica/builds/238877621].
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (CALCITE-4815) Avatica's Travis fails with 'LICENSE-like files are missing' error
[
https://issues.apache.org/jira/browse/CALCITE-4815?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17423113#comment-17423113
]
Vladimir Sitnikov edited comment on CALCITE-4815 at 10/1/21, 6:58 AM:
--
It is indeed sad that com.github.vlsi.gradle.license plugin does not show the
provenance to the dependency causing the failure, however, it can be identified
as follows:
{noformat}
./gradlew :standalone-server:dependencies -Pguava.version=29.0-jre
--configuration shaded
{noformat}
{noformat}
shaded
+--- project :core
|+--- project :metrics
||+--- project :bom
|||+--- com.beust:jcommander:1.72 (c)
|||+--- com.fasterxml.jackson.core:jackson-annotations:2.10.0 (c)
|||+--- com.fasterxml.jackson.core:jackson-core:2.10.0 (c)
|||+--- com.fasterxml.jackson.core:jackson-databind:2.10.0 (c)
|||+--- com.google.guava:guava:29.0-jre (c)
|||+--- com.google.protobuf:protobuf-java:3.6.1 (c)
|||+--- javax.servlet:javax.servlet-api:4.0.1 (c)
|||+--- org.apache.httpcomponents:httpclient:4.5.9 (c)
|||+--- org.apache.httpcomponents:httpcore:4.4.11 (c)
|||+--- org.eclipse.jetty:jetty-http:9.4.42.v20210604 (c)
|||+--- org.eclipse.jetty:jetty-security:9.4.42.v20210604 (c)
|||+--- org.eclipse.jetty:jetty-server:9.4.42.v20210604 (c)
|||+--- org.eclipse.jetty:jetty-util:9.4.42.v20210604 (c)
|||+--- org.slf4j:slf4j-api:1.7.25 (c)
|||\--- org.slf4j:slf4j-log4j12:1.7.25 (c)
||\--- org.slf4j:slf4j-api -> 1.7.25
|+--- com.fasterxml.jackson.core:jackson-annotations -> 2.10.0
|+--- com.fasterxml.jackson.core:jackson-databind -> 2.10.0
||+--- com.fasterxml.jackson.core:jackson-annotations:2.10.0
||\--- com.fasterxml.jackson.core:jackson-core:2.10.0
|+--- com.google.protobuf:protobuf-java -> 3.6.1
|+--- project :bom (*)
|+--- com.fasterxml.jackson.core:jackson-core -> 2.10.0
|+--- org.apache.httpcomponents:httpclient -> 4.5.9
||+--- org.apache.httpcomponents:httpcore:4.4.11
||+--- commons-logging:commons-logging:1.2
||\--- commons-codec:commons-codec:1.11
|+--- org.apache.httpcomponents:httpcore -> 4.4.11
|\--- org.slf4j:slf4j-api -> 1.7.25
+--- project :server
|+--- project :core (*)
|+--- project :metrics (*)
|+--- javax.servlet:javax.servlet-api -> 4.0.1
|+--- org.eclipse.jetty:jetty-http -> 9.4.42.v20210604
||+--- org.eclipse.jetty:jetty-util:9.4.42.v20210604
||\--- org.eclipse.jetty:jetty-io:9.4.42.v20210604
|| \--- org.eclipse.jetty:jetty-util:9.4.42.v20210604
|+--- org.eclipse.jetty:jetty-security -> 9.4.42.v20210604
||\--- org.eclipse.jetty:jetty-server:9.4.42.v20210604
|| +--- javax.servlet:javax.servlet-api:3.1.0 -> 4.0.1
|| +--- org.eclipse.jetty:jetty-http:9.4.42.v20210604 (*)
|| \--- org.eclipse.jetty:jetty-io:9.4.42.v20210604 (*)
|+--- org.eclipse.jetty:jetty-server -> 9.4.42.v20210604 (*)
|+--- org.eclipse.jetty:jetty-util -> 9.4.42.v20210604
|+--- project :bom (*)
|+--- org.slf4j:slf4j-api -> 1.7.25
|\--- com.google.guava:guava -> 29.0-jre
| +--- com.google.guava:failureaccess:1.0.1
| +---
com.google.guava:listenablefuture:.0-empty-to-avoid-conflict-with-guava
| +--- com.google.code.findbugs:jsr305:3.0.2
| +--- org.checkerframework:checker-qual:2.11.1
| +--- com.google.errorprone:error_prone_annotations:2.3.4
| \--- com.google.j2objc:j2objc-annotations:1.3
+--- com.beust:jcommander -> 1.72
+--- org.slf4j:slf4j-api -> 1.7.25
\--- org.slf4j:slf4j-log4j12 -> 1.7.25
+--- org.slf4j:slf4j-api:1.7.25
\--- log4j:log4j:1.2.17
{noformat}
The "offending" dependency comes from
{noformat}
|\--- com.google.guava:guava -> 29.0-jre
...
| +--- org.checkerframework:checker-qual:2.11.1
{noformat}
The thing here is as follows:
1) Calcite Avatica "standalone-server" shades dependencies, which means it
bundles them
2) checker-qual is MIT licensed, so requires to include MIT license text into
the generated standalone-server.jar
3) calcite-avatica does not have a copy of checker-qual license text, and we do
not want to keep it as it would require manual inspection of the licenses on
each and every upgrade :-/
That means we would violate checker-qual license terms if we ship the current
Calcite Avatica built with checker-qual:2.11.1
-
I believe, the most workable solution is to make {{checker-qual}} include its
own license into the checker-qual.jar, so everybody who shades that dependency
receives the appropriate copy of the license.
I've reported the issue earlier in
https://github.com/typetools/checker-framework/issues/2798, and the license
text has been included in
[jira] [Resolved] (CALCITE-4815) Avatica's Travis fails with 'LICENSE-like files are missing' error
[
https://issues.apache.org/jira/browse/CALCITE-4815?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Sitnikov resolved CALCITE-4815.
Fix Version/s: avatica-1.19.0
Resolution: Fixed
Fixed in
https://github.com/apache/calcite-avatica/commit/951b21ef7ce075a414559d7192739463b40f7b9b
> Avatica's Travis fails with 'LICENSE-like files are missing' error
> --
>
> Key: CALCITE-4815
> URL: https://issues.apache.org/jira/browse/CALCITE-4815
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Reporter: Julian Hyde
>Priority: Major
> Fix For: avatica-1.19.0
>
>
> Some configurations of Avatica's Travis CI job fail with the following error.
> {noformat}
> > Task :standalone-server:classes
> > Task :standalone-server:getLicenses FAILED
> > Task :server:checkstyleTest
> Build [0;1mcalcite-avatica [0;1;31mFAILURE[0;1m[0m reason:
>
> Execution [0;1;31mfailed[0m for task
> '[0;1m:standalone-server:getLicenses[0m':
> LICENSE-like files are missing
> ==
>
> MIT
> * org.checkerframework:checker-qual:2.11.1
>
> at
> com.github.vlsi.gradle.license.GatherLicenseTask.run(GatherLicenseTask.kt:417)
> at org.gradle.internal.reflect.JavaMethod.invoke(JavaMethod.java:104)
> at
> org.gradle.api.internal.project.taskfactory.StandardTaskAction.doExecute(StandardTaskAction.java:58)
> FAILURE: Build failed with an exception.
> * What went wrong:
> Execution failed for task ':standalone-server:getLicenses'.
> > LICENSE-like files are missing
> ==
>
> MIT
> * org.checkerframework:checker-qual:2.11.1
> {noformat}
>
> [~vlsi], Do you have any idea what's going on? Avatica doesn't even use
> checkerframework. You can see the build output (for a few days) at
> [https://app.travis-ci.com/github/julianhyde/calcite-avatica/builds/238877621].
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-4815) Avatica's Travis fails with 'LICENSE-like files are missing' error
[
https://issues.apache.org/jira/browse/CALCITE-4815?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17423115#comment-17423115
]
Vladimir Sitnikov commented on CALCITE-4815:
The solution here is to enforce newer checker-qual version as follows.
What it does it says "if checker-qual appears on the classpath, use 3.10.0 or
newer"
{noformat}
diff --git a/bom/build.gradle.kts b/bom/build.gradle.kts
index 71a81839d..acbb02487 100644
--- a/bom/build.gradle.kts
+++ b/bom/build.gradle.kts
@@ -45,6 +45,7 @@ dependencies {
// In other words, marking dependency as "runtime" would avoid
accidental
// dependency on it during compilation
apiv("com.beust:jcommander")
+apiv("org.checkerframework:checker-qual", "checkerframework")
apiv("com.fasterxml.jackson.core:jackson-annotations", "jackson")
apiv("com.fasterxml.jackson.core:jackson-core", "jackson")
apiv("com.fasterxml.jackson.core:jackson-databind", "jackson")
diff --git a/gradle.properties b/gradle.properties
index 5d752f413..24fcdde86 100644
--- a/gradle.properties
+++ b/gradle.properties
@@ -49,6 +49,7 @@ org.owasp.dependencycheck.version=5.2.2
# docker-maven-plugin.version=1.2.0
# Tools
+checkerframework.version=3.10.0
checkstyle.version=6.18
spotbugs.version=3.1.11
# For Checkstyle
{noformat}
> Avatica's Travis fails with 'LICENSE-like files are missing' error
> --
>
> Key: CALCITE-4815
> URL: https://issues.apache.org/jira/browse/CALCITE-4815
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Reporter: Julian Hyde
>Priority: Major
>
> Some configurations of Avatica's Travis CI job fail with the following error.
> {noformat}
> > Task :standalone-server:classes
> > Task :standalone-server:getLicenses FAILED
> > Task :server:checkstyleTest
> Build [0;1mcalcite-avatica [0;1;31mFAILURE[0;1m[0m reason:
>
> Execution [0;1;31mfailed[0m for task
> '[0;1m:standalone-server:getLicenses[0m':
> LICENSE-like files are missing
> ==
>
> MIT
> * org.checkerframework:checker-qual:2.11.1
>
> at
> com.github.vlsi.gradle.license.GatherLicenseTask.run(GatherLicenseTask.kt:417)
> at org.gradle.internal.reflect.JavaMethod.invoke(JavaMethod.java:104)
> at
> org.gradle.api.internal.project.taskfactory.StandardTaskAction.doExecute(StandardTaskAction.java:58)
> FAILURE: Build failed with an exception.
> * What went wrong:
> Execution failed for task ':standalone-server:getLicenses'.
> > LICENSE-like files are missing
> ==
>
> MIT
> * org.checkerframework:checker-qual:2.11.1
> {noformat}
>
> [~vlsi], Do you have any idea what's going on? Avatica doesn't even use
> checkerframework. You can see the build output (for a few days) at
> [https://app.travis-ci.com/github/julianhyde/calcite-avatica/builds/238877621].
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (CALCITE-4815) Avatica's Travis fails with 'LICENSE-like files are missing' error
[
https://issues.apache.org/jira/browse/CALCITE-4815?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17423113#comment-17423113
]
Vladimir Sitnikov edited comment on CALCITE-4815 at 10/1/21, 6:14 AM:
--
It is indeed sad that com.github.vlsi.gradle.license plugin does not show the
provenance to the dependency causing the failure, however, it can be identified
as follows:
{noformat}
./gradlew :standalone-server:dependencies -Pguava.version=29.0-jre
--configuration shaded
{noformat}
{noformat}
shaded
+--- project :core
|+--- project :metrics
||+--- project :bom
|||+--- com.beust:jcommander:1.72 (c)
|||+--- com.fasterxml.jackson.core:jackson-annotations:2.10.0 (c)
|||+--- com.fasterxml.jackson.core:jackson-core:2.10.0 (c)
|||+--- com.fasterxml.jackson.core:jackson-databind:2.10.0 (c)
|||+--- com.google.guava:guava:29.0-jre (c)
|||+--- com.google.protobuf:protobuf-java:3.6.1 (c)
|||+--- javax.servlet:javax.servlet-api:4.0.1 (c)
|||+--- org.apache.httpcomponents:httpclient:4.5.9 (c)
|||+--- org.apache.httpcomponents:httpcore:4.4.11 (c)
|||+--- org.eclipse.jetty:jetty-http:9.4.42.v20210604 (c)
|||+--- org.eclipse.jetty:jetty-security:9.4.42.v20210604 (c)
|||+--- org.eclipse.jetty:jetty-server:9.4.42.v20210604 (c)
|||+--- org.eclipse.jetty:jetty-util:9.4.42.v20210604 (c)
|||+--- org.slf4j:slf4j-api:1.7.25 (c)
|||\--- org.slf4j:slf4j-log4j12:1.7.25 (c)
||\--- org.slf4j:slf4j-api -> 1.7.25
|+--- com.fasterxml.jackson.core:jackson-annotations -> 2.10.0
|+--- com.fasterxml.jackson.core:jackson-databind -> 2.10.0
||+--- com.fasterxml.jackson.core:jackson-annotations:2.10.0
||\--- com.fasterxml.jackson.core:jackson-core:2.10.0
|+--- com.google.protobuf:protobuf-java -> 3.6.1
|+--- project :bom (*)
|+--- com.fasterxml.jackson.core:jackson-core -> 2.10.0
|+--- org.apache.httpcomponents:httpclient -> 4.5.9
||+--- org.apache.httpcomponents:httpcore:4.4.11
||+--- commons-logging:commons-logging:1.2
||\--- commons-codec:commons-codec:1.11
|+--- org.apache.httpcomponents:httpcore -> 4.4.11
|\--- org.slf4j:slf4j-api -> 1.7.25
+--- project :server
|+--- project :core (*)
|+--- project :metrics (*)
|+--- javax.servlet:javax.servlet-api -> 4.0.1
|+--- org.eclipse.jetty:jetty-http -> 9.4.42.v20210604
||+--- org.eclipse.jetty:jetty-util:9.4.42.v20210604
||\--- org.eclipse.jetty:jetty-io:9.4.42.v20210604
|| \--- org.eclipse.jetty:jetty-util:9.4.42.v20210604
|+--- org.eclipse.jetty:jetty-security -> 9.4.42.v20210604
||\--- org.eclipse.jetty:jetty-server:9.4.42.v20210604
|| +--- javax.servlet:javax.servlet-api:3.1.0 -> 4.0.1
|| +--- org.eclipse.jetty:jetty-http:9.4.42.v20210604 (*)
|| \--- org.eclipse.jetty:jetty-io:9.4.42.v20210604 (*)
|+--- org.eclipse.jetty:jetty-server -> 9.4.42.v20210604 (*)
|+--- org.eclipse.jetty:jetty-util -> 9.4.42.v20210604
|+--- project :bom (*)
|+--- org.slf4j:slf4j-api -> 1.7.25
|\--- com.google.guava:guava -> 29.0-jre
| +--- com.google.guava:failureaccess:1.0.1
| +---
com.google.guava:listenablefuture:.0-empty-to-avoid-conflict-with-guava
| +--- com.google.code.findbugs:jsr305:3.0.2
| +--- org.checkerframework:checker-qual:2.11.1
| +--- com.google.errorprone:error_prone_annotations:2.3.4
| \--- com.google.j2objc:j2objc-annotations:1.3
+--- com.beust:jcommander -> 1.72
+--- org.slf4j:slf4j-api -> 1.7.25
\--- org.slf4j:slf4j-log4j12 -> 1.7.25
+--- org.slf4j:slf4j-api:1.7.25
\--- log4j:log4j:1.2.17
{noformat}
The "offending" dependency comes from
{noformat}
|\--- com.google.guava:guava -> 29.0-jre
...
| +--- org.checkerframework:checker-qual:2.11.1
{noformat}
The thing here is as follows:
1) Calcite Avatica "standalone-server" shades dependencies, which means it
bundles them
2) It means standalone-server includes checker-qual
3) checker-qual is MIT licensed, which requires to include MIT license text
into the generated standalone-server.jar
That means we would violate checker-qual license terms if we ship the current
Calcite Avatica built with checker-qual:2.11.1
-
I believe, the most workable solution is to make {{checker-qual}} include its
own license into the checker-qual.jar, so everybody who shades that dependency
receives the appropriate copy of the license.
I've reported the issue earlier in
https://github.com/typetools/checker-framework/issues/2798, and the license
text has been included in checker-qual 3.0.0+
was (Author: vladimirsitnikov):
It is indeed sad that com.github.vlsi.gradle.license plugin does not show the
[jira] [Commented] (CALCITE-4815) Avatica's Travis fails with 'LICENSE-like files are missing' error
[
https://issues.apache.org/jira/browse/CALCITE-4815?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17423113#comment-17423113
]
Vladimir Sitnikov commented on CALCITE-4815:
It is indeed sad that com.github.vlsi.gradle.license plugin does not show the
provenance to the dependency causing the failure, however, it can be identified
as follows:
{noformat}
./gradlew :standalone-server:dependencies -Pguava.version=29.0-jre
--configuration shaded
{noformat}
{noformat}
shaded
+--- project :core
|+--- project :metrics
||+--- project :bom
|||+--- com.beust:jcommander:1.72 (c)
|||+--- com.fasterxml.jackson.core:jackson-annotations:2.10.0 (c)
|||+--- com.fasterxml.jackson.core:jackson-core:2.10.0 (c)
|||+--- com.fasterxml.jackson.core:jackson-databind:2.10.0 (c)
|||+--- com.google.guava:guava:29.0-jre (c)
|||+--- com.google.protobuf:protobuf-java:3.6.1 (c)
|||+--- javax.servlet:javax.servlet-api:4.0.1 (c)
|||+--- org.apache.httpcomponents:httpclient:4.5.9 (c)
|||+--- org.apache.httpcomponents:httpcore:4.4.11 (c)
|||+--- org.eclipse.jetty:jetty-http:9.4.42.v20210604 (c)
|||+--- org.eclipse.jetty:jetty-security:9.4.42.v20210604 (c)
|||+--- org.eclipse.jetty:jetty-server:9.4.42.v20210604 (c)
|||+--- org.eclipse.jetty:jetty-util:9.4.42.v20210604 (c)
|||+--- org.slf4j:slf4j-api:1.7.25 (c)
|||\--- org.slf4j:slf4j-log4j12:1.7.25 (c)
||\--- org.slf4j:slf4j-api -> 1.7.25
|+--- com.fasterxml.jackson.core:jackson-annotations -> 2.10.0
|+--- com.fasterxml.jackson.core:jackson-databind -> 2.10.0
||+--- com.fasterxml.jackson.core:jackson-annotations:2.10.0
||\--- com.fasterxml.jackson.core:jackson-core:2.10.0
|+--- com.google.protobuf:protobuf-java -> 3.6.1
|+--- project :bom (*)
|+--- com.fasterxml.jackson.core:jackson-core -> 2.10.0
|+--- org.apache.httpcomponents:httpclient -> 4.5.9
||+--- org.apache.httpcomponents:httpcore:4.4.11
||+--- commons-logging:commons-logging:1.2
||\--- commons-codec:commons-codec:1.11
|+--- org.apache.httpcomponents:httpcore -> 4.4.11
|\--- org.slf4j:slf4j-api -> 1.7.25
+--- project :server
|+--- project :core (*)
|+--- project :metrics (*)
|+--- javax.servlet:javax.servlet-api -> 4.0.1
|+--- org.eclipse.jetty:jetty-http -> 9.4.42.v20210604
||+--- org.eclipse.jetty:jetty-util:9.4.42.v20210604
||\--- org.eclipse.jetty:jetty-io:9.4.42.v20210604
|| \--- org.eclipse.jetty:jetty-util:9.4.42.v20210604
|+--- org.eclipse.jetty:jetty-security -> 9.4.42.v20210604
||\--- org.eclipse.jetty:jetty-server:9.4.42.v20210604
|| +--- javax.servlet:javax.servlet-api:3.1.0 -> 4.0.1
|| +--- org.eclipse.jetty:jetty-http:9.4.42.v20210604 (*)
|| \--- org.eclipse.jetty:jetty-io:9.4.42.v20210604 (*)
|+--- org.eclipse.jetty:jetty-server -> 9.4.42.v20210604 (*)
|+--- org.eclipse.jetty:jetty-util -> 9.4.42.v20210604
|+--- project :bom (*)
|+--- org.slf4j:slf4j-api -> 1.7.25
|\--- com.google.guava:guava -> 29.0-jre
| +--- com.google.guava:failureaccess:1.0.1
| +---
com.google.guava:listenablefuture:.0-empty-to-avoid-conflict-with-guava
| +--- com.google.code.findbugs:jsr305:3.0.2
| +--- org.checkerframework:checker-qual:2.11.1
| +--- com.google.errorprone:error_prone_annotations:2.3.4
| \--- com.google.j2objc:j2objc-annotations:1.3
+--- com.beust:jcommander -> 1.72
+--- org.slf4j:slf4j-api -> 1.7.25
\--- org.slf4j:slf4j-log4j12 -> 1.7.25
+--- org.slf4j:slf4j-api:1.7.25
\--- log4j:log4j:1.2.17
{noformat}
The "offending" dependency comes from
{noformat}
|\--- com.google.guava:guava -> 29.0-jre
...
| +--- org.checkerframework:checker-qual:2.11.1
{noformat}
The thing here is as follows:
1) Calcite Avatica "standalone-server" shades dependencies, which means it
bundles them
2) It means standalone-server includes checker-qual
3) checker-qual is MIT licensed, which requires to include MIT license text
into the generated standalone-server.jar
-
I believe, the most workable solution is to make {{checker-qual}} include its
own license into the checker-qual.jar, so everybody who shades that dependency
receives the appropriate copy of the license.
I've reported the issue earlier in
https://github.com/typetools/checker-framework/issues/2798, and the license
text has been included in checker-qual 3.0.0+
> Avatica's Travis fails with 'LICENSE-like files are missing' error
> --
>
> Key: CALCITE-4815
> URL: https://issues.apache.org/jira/browse/CALCITE-4815
> Project: Calcite
>
[jira] [Resolved] (CALCITE-4790) Make Gradle pass the 'user.timezone' property to the test JVM
[ https://issues.apache.org/jira/browse/CALCITE-4790?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Sitnikov resolved CALCITE-4790. Fix Version/s: 1.28.0 Resolution: Fixed Fixed in https://github.com/apache/calcite/commit/d6a2d69d33c466f7cb7d164f3db4e54771d31371, thanks [~asolimando] > Make Gradle pass the 'user.timezone' property to the test JVM > - > > Key: CALCITE-4790 > URL: https://issues.apache.org/jira/browse/CALCITE-4790 > Project: Calcite > Issue Type: Improvement >Affects Versions: 1.27.0 >Reporter: Alessandro Solimando >Assignee: Alessandro Solimando >Priority: Major > Labels: pull-request-available > Fix For: 1.28.0 > > Time Spent: 10m > Remaining Estimate: 0h > > Tests run in the forked JVM, only the explicit set of properties is passed > there, which are listed > [here|https://github.com/apache/calcite/blob/4b1e9ed1a513eae0c873a660b755bb4f27b39da9/build.gradle.kts#L711-L726] > Add -Duser.timezone to the list of properties to be passed along. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (CALCITE-4787) Evaluate use of Immutables instead of ImmutableBeans
[
https://issues.apache.org/jira/browse/CALCITE-4787?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17421203#comment-17421203
]
Vladimir Sitnikov edited comment on CALCITE-4787 at 9/28/21, 6:54 AM:
--
By the way, IDEA 2019.3+ picks up annotation-generated sources by default, so a
mere compile (e.g. {{./gradlew classes}}) would be a sensible workaround.
I just tried adding -proc:only to the regular `compileJava` task, and it took
6-7 seconds which is probably a sane delay for importing the project.
Here's a sketch of the task that would process the annotations:
{code:java}
val annotationProcessor by tasks.registering(JavaCompile::class) {
dependsOn(javaCCMain)
val main = sourceSets.main.get()
source = main.java
classpath = main.compileClasspath
destinationDirectory.set(project.layout.buildDirectory.dir("tmp/$name"))
options.compilerArgs.add("-proc:only")
org.gradle.api.plugins.internal.JvmPluginsHelper.configureAnnotationProcessorPath(main,
main.java, options, project)
}
{code}
A downside is that "project import" would print errors if the code does not
compile (e.g. if there's a typo in java code), on the other hand, if a new
immutable class is added, a mere "sync project" would be enough to trigger the
code generation just like generating the parser.
was (Author: vladimirsitnikov):
By the way, IDEA 2019.3+ picks up annotation-generated sources by default, so a
mere build would be a sensible workaround.
I just tried adding -proc:only to the regular `compileJava` task, and it took
6-7 seconds which is probably a sane delay for importing the project.
Here's a sketch of the task that would process the annotations:
{code:java}
val annotationProcessor by tasks.registering(JavaCompile::class) {
dependsOn(javaCCMain)
val main = sourceSets.main.get()
source = main.java
classpath = main.compileClasspath
destinationDirectory.set(project.layout.buildDirectory.dir("tmp/$name"))
options.compilerArgs.add("-proc:only")
org.gradle.api.plugins.internal.JvmPluginsHelper.configureAnnotationProcessorPath(main,
main.java, options, project)
}
{code}
A downside is that "project import" would print errors if the code does not
compile (e.g. if there's a typo in java code), on the other hand, if a new
immutable class is added, a mere "sync project" would be enough to trigger the
code generation just like generating the parser.
> Evaluate use of Immutables instead of ImmutableBeans
>
>
> Key: CALCITE-4787
> URL: https://issues.apache.org/jira/browse/CALCITE-4787
> Project: Calcite
> Issue Type: Improvement
>Reporter: Jacques Nadeau
>Assignee: Jacques Nadeau
>Priority: Major
> Labels: pull-request-available
> Time Spent: 6.5h
> Remaining Estimate: 0h
>
> In the creation of CALCITE-3328, [Immutables|https://immutables.github.io/]
> was discussed as an alternative to a custom implementation. This ticket is to
> evaluate the impact to the codebase of changing. Ideally, introduction of
> immutables would both add flexibility and reduce the amount of code
> associated with these classes.
> Immutables works via annotation processor which means that it is should be
> relatively seamless to build systems and IDEs.
> The switch would also make it easier to work with these objects types in the
> context of aot compilation tools like GraalVM.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-4787) Evaluate use of Immutables instead of ImmutableBeans
[
https://issues.apache.org/jira/browse/CALCITE-4787?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17421203#comment-17421203
]
Vladimir Sitnikov commented on CALCITE-4787:
By the way, IDEA 2019.3+ picks up annotation-generated sources by default, so a
mere build would be a sensible workaround.
I just tried adding -proc:only to the regular `compileJava` task, and it took
6-7 seconds which is probably a sane delay for importing the project.
Here's a sketch of the task that would process the annotations:
{code:java}
val annotationProcessor by tasks.registering(JavaCompile::class) {
dependsOn(javaCCMain)
val main = sourceSets.main.get()
source = main.java
classpath = main.compileClasspath
destinationDirectory.set(project.layout.buildDirectory.dir("tmp/$name"))
options.compilerArgs.add("-proc:only")
org.gradle.api.plugins.internal.JvmPluginsHelper.configureAnnotationProcessorPath(main,
main.java, options, project)
}
{code}
A downside is that "project import" would print errors if the code does not
compile (e.g. if there's a typo in java code), on the other hand, if a new
immutable class is added, a mere "sync project" would be enough to trigger the
code generation just like generating the parser.
> Evaluate use of Immutables instead of ImmutableBeans
>
>
> Key: CALCITE-4787
> URL: https://issues.apache.org/jira/browse/CALCITE-4787
> Project: Calcite
> Issue Type: Improvement
>Reporter: Jacques Nadeau
>Assignee: Jacques Nadeau
>Priority: Major
> Labels: pull-request-available
> Time Spent: 6.5h
> Remaining Estimate: 0h
>
> In the creation of CALCITE-3328, [Immutables|https://immutables.github.io/]
> was discussed as an alternative to a custom implementation. This ticket is to
> evaluate the impact to the codebase of changing. Ideally, introduction of
> immutables would both add flexibility and reduce the amount of code
> associated with these classes.
> Immutables works via annotation processor which means that it is should be
> relatively seamless to build systems and IDEs.
> The switch would also make it easier to work with these objects types in the
> context of aot compilation tools like GraalVM.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-4787) Evaluate use of Immutables instead of ImmutableBeans
[
https://issues.apache.org/jira/browse/CALCITE-4787?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17420991#comment-17420991
]
Vladimir Sitnikov commented on CALCITE-4787:
One more issue: the code is invalid in IDEA after I import the project.
I think we should consider configuring the build so it generates all the
classes when the project is imported to the IDE.
I wonder if there's a way to generate the immutable code without compiling all
the classes in {{core}}.
Currently {{:core:compileJava}} takes ~30-40s, and {{:core:compileTestJava}}
takes ~20sec which, I believe, is not something we want to do on each import.
Issuing compileJava on project import would probably be reasonable if we could
extract the immutable interfaces to a smaller module.
> Evaluate use of Immutables instead of ImmutableBeans
>
>
> Key: CALCITE-4787
> URL: https://issues.apache.org/jira/browse/CALCITE-4787
> Project: Calcite
> Issue Type: Improvement
>Reporter: Jacques Nadeau
>Assignee: Jacques Nadeau
>Priority: Major
> Labels: pull-request-available
> Time Spent: 5h 40m
> Remaining Estimate: 0h
>
> In the creation of CALCITE-3328, [Immutables|https://immutables.github.io/]
> was discussed as an alternative to a custom implementation. This ticket is to
> evaluate the impact to the codebase of changing. Ideally, introduction of
> immutables would both add flexibility and reduce the amount of code
> associated with these classes.
> Immutables works via annotation processor which means that it is should be
> relatively seamless to build systems and IDEs.
> The switch would also make it easier to work with these objects types in the
> context of aot compilation tools like GraalVM.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-4790) Make Gradle pass the 'user.timezone' property to the test JVM
[ https://issues.apache.org/jira/browse/CALCITE-4790?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17418796#comment-17418796 ] Vladimir Sitnikov commented on CALCITE-4790: Travis uses TZ environment variable which should be inherited by the process, so Travis should not be impacted. However, Travis becomes less and less reliable, so we might try randomizing the matrix at GitHub via https://github.com/vlsi/github-actions-random-matrix or something like that > Make Gradle pass the 'user.timezone' property to the test JVM > - > > Key: CALCITE-4790 > URL: https://issues.apache.org/jira/browse/CALCITE-4790 > Project: Calcite > Issue Type: Improvement >Affects Versions: 1.27.0 >Reporter: Alessandro Solimando >Assignee: Alessandro Solimando >Priority: Major > Labels: pull-request-available > > Tests run in the forked JVM, only the explicit set of properties is passed > there, which are listed > [here|https://github.com/apache/calcite/blob/4b1e9ed1a513eae0c873a660b755bb4f27b39da9/build.gradle.kts#L711-L726] > Add -Duser.timezone to the list of properties to be passed along. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-4789) Build is broken on Guava versions < 21
[
https://issues.apache.org/jira/browse/CALCITE-4789?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17418741#comment-17418741
]
Vladimir Sitnikov commented on CALCITE-4789:
[~asolimando], {{-Duser.timezone}} is not automatically passed to the test
execution.
The thing is that tests are runned in the forked JVM, so only the explicit set
of properties is passed there.
The properties are listed here:
https://github.com/apache/calcite/blob/4b1e9ed1a513eae0c873a660b755bb4f27b39da9/build.gradle.kts#L711-L726
I think we could add {{user.timezone}} there as well.
> Build is broken on Guava versions < 21
> --
>
> Key: CALCITE-4789
> URL: https://issues.apache.org/jira/browse/CALCITE-4789
> Project: Calcite
> Issue Type: Bug
> Environment: The build is currently broken on Guava versions 20 and
> lower. We claim in the release notes to support Guava 19 and higher.
> As part of this change, enable testing in CI of the lowest and highest
> supported Guava version. (We used to do this, but we stopped when we moved
> from Maven to Gradle. I still don't know how to set the Guava version from
> the Gradle command line.)
>Reporter: Julian Hyde
>Assignee: Julian Hyde
>Priority: Major
> Fix For: 1.28.0
>
>
> The build is broken on versions of Gradle less than 21. In our release notes
> we say we support Gradle 19 and higher.
> We used to test the supported range of Guava versions in CI. The fix for this
> issue must resume CI testing for the range of supported versions (currently
> 19.0 to 29.0-jre per
> [history.md|https://calcite.apache.org/docs/history.html] and 19.0 and higher
> per a comment in {{gradle.properties}}).
> How do I set the Guava version from the Gradle command line? I’d expect
> {code:java}
> ./gradlew -Dguava.version=19.0
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-2736) ReduceExpressionsRule never reduces dynamic expressions but this should be configurable
[
https://issues.apache.org/jira/browse/CALCITE-2736?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17401866#comment-17401866
]
Vladimir Sitnikov commented on CALCITE-2736:
I don't fully understand the use case (it would be sad to cache dynamic value
and get wrong results), however, the defaults are not changed, so I see no
issues.
The PR #980 looks good to me, except "rebase/squash" and the naming.
I would avoid naming fields and methods with {{Not}} since "non-constant" might
have multiple meanings.
> ReduceExpressionsRule never reduces dynamic expressions but this should be
> configurable
> ---
>
> Key: CALCITE-2736
> URL: https://issues.apache.org/jira/browse/CALCITE-2736
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: Jacques Nadeau
>Assignee: Jacques Nadeau
>Priority: Major
> Labels: pull-request-available
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> There are situations where it is helpful to reduce dynamic SqlCalls. Right
> now, the ReduceExpressionsRule always avoids doing this. We should enhance
> the rule so this can be configurable depending on where in planning the rule
> is used.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-4715) Create CITATION.cff for BibTex, APA citation UI in GitHub
[ https://issues.apache.org/jira/browse/CALCITE-4715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17392219#comment-17392219 ] Vladimir Sitnikov commented on CALCITE-4715: I assume CITATION.cff is there so give a hint how Calcite should be cited. I think CITATION.cff can point to the paper we want, however, that is just my wild guess. I've no idea regarding file formats, papers, citation rules, etc :-/ > Create CITATION.cff for BibTex, APA citation UI in GitHub > - > > Key: CALCITE-4715 > URL: https://issues.apache.org/jira/browse/CALCITE-4715 > Project: Calcite > Issue Type: Improvement >Reporter: Vladimir Sitnikov >Priority: Major > > See https://twitter.com/natfriedman/status/1420122675813441540 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CALCITE-4715) Create CITATION.cff for BibTex, APA citation UI in GitHub
Vladimir Sitnikov created CALCITE-4715: -- Summary: Create CITATION.cff for BibTex, APA citation UI in GitHub Key: CALCITE-4715 URL: https://issues.apache.org/jira/browse/CALCITE-4715 Project: Calcite Issue Type: Improvement Reporter: Vladimir Sitnikov See https://twitter.com/natfriedman/status/1420122675813441540 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-4704) Log produced plan after rule application using explain formatting
[
https://issues.apache.org/jira/browse/CALCITE-4704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17388164#comment-17388164
]
Vladimir Sitnikov commented on CALCITE-4704:
{quote} by extra category? A separate logger? {quote}
Yes, something like
{code:java}
private static final Logger SHORT_PLANS;
private static final Logger FULL_PLANS;
...
{code}
{quote}Do you mean "before"/"after" registering the produced RelNode. {quote}
I mean "before rule application" and "after rule application"
> Log produced plan after rule application using explain formatting
> -
>
> Key: CALCITE-4704
> URL: https://issues.apache.org/jira/browse/CALCITE-4704
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.27.0
>Reporter: Stamatis Zampetakis
>Assignee: Stamatis Zampetakis
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.28.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> In many cases, we want to identify which rule lead to a certain
> transformation in the plan or need to observe how the query plan evolves by
> applying some rules in order to fix some bug or find the right place to
> introduce another optimization step.
> Currently there are some logs during the application of a rule triggered by
> the
> [HepPlanner|https://github.com/apache/calcite/blob/e04f3b08dcfb6910ff4df3810772c346b25ed424/core/src/main/java/org/apache/calcite/plan/AbstractRelOptPlanner.java#L367]
> and
> [VolcanoPlanner|https://github.com/apache/calcite/blob/e04f3b08dcfb6910ff4df3810772c346b25ed424/core/src/main/java/org/apache/calcite/plan/volcano/VolcanoRuleCall.java#L126]
> but they more or less display only the top operator of the transformation
> and not the whole subtree. Moreover, the {{RelNode#toString}} used in these
> logs, is not self-contained, so in order to check the transformation the log
> entry needs to be matched with other logs.
> It would help if instead of displaying only the top operator we logged the
> equivalent of explain (i.e., {{RelOptUtil.toString}}) on the transformed
> sub-tree.
> You can find below some extracts from the current logs and how the proposed
> log could look like.
> *HepPlanner*
> +Current logging+
> {noformat}
> 2021-07-27 14:37:58,252 [ForkJoinPool-1-worker-9] DEBUG - call#0: Rule
> FilterIntoJoinRule arguments
> [rel#9:LogicalFilter.NONE.[](input=HepRelVertex#8,condition==($7, $8)),
> rel#7:LogicalJoin.NONE.[](left=HepRelVertex#5,right=HepRelVertex#6,condition=true,joinType=left)]
> produced
> rel#14:LogicalProject.NONE.[](input=LogicalJoin#13,inputs=0..7,exprs=[CAST($8):TINYINT,
> $9, $10])
> 2021-07-27 14:37:58,266 [ForkJoinPool-1-worker-9] DEBUG - call#1: Rule
> ProjectJoinTransposeRule arguments
> [rel#16:LogicalProject.NONE.[](input=HepRelVertex#15,inputs=0..7,exprs=[CAST($8):TINYINT,
> $9, $10]),
> rel#13:LogicalJoin.NONE.[](left=HepRelVertex#5,right=HepRelVertex#6,condition==($7,
> $8),joinType=inner)] produced
> rel#21:LogicalProject.NONE.[](input=LogicalJoin#20,inputs=0..7,exprs=[$11,
> $9, $10])
> 2021-07-27 14:37:58,269 [ForkJoinPool-1-worker-9] DEBUG - call#3: Rule
> ProjectMergeRule arguments
> [rel#11:LogicalProject.NONE.[](input=HepRelVertex#27,exprs=[$1]),
> rel#26:LogicalProject.NONE.[](input=HepRelVertex#25,inputs=0..7,exprs=[$11,
> $9, $10])] produced
> rel#28:LogicalProject.NONE.[](input=HepRelVertex#25,exprs=[$1])
> 2021-07-27 14:37:58,272 [ForkJoinPool-1-worker-9] DEBUG - call#4: Rule
> ProjectJoinTransposeRule arguments
> [rel#28:LogicalProject.NONE.[](input=HepRelVertex#25,exprs=[$1]),
> rel#24:LogicalJoin.NONE.[](left=HepRelVertex#22,right=HepRelVertex#23,condition==($7,
> $8),joinType=inner)] produced
> rel#33:LogicalProject.NONE.[](input=LogicalJoin#32,inputs=0)
> 2021-07-27 14:37:58,274 [ForkJoinPool-1-worker-9] DEBUG - call#6: Rule
> ProjectMergeRule arguments
> [rel#30:LogicalProject.NONE.[](input=HepRelVertex#22,exprs=[$1, $7]),
> rel#18:LogicalProject.NONE.[0](input=HepRelVertex#5,inputs=0..7)] produced
> rel#40:LogicalProject.NONE.[](input=HepRelVertex#5,exprs=[$1, $7])
> 2021-07-27 14:37:58,275 [ForkJoinPool-1-worker-9] DEBUG - call#7: Rule
> ProjectMergeRule arguments
> [rel#31:LogicalProject.NONE.[0](input=HepRelVertex#23,inputs=0),
> rel#19:LogicalProject.NONE.[[0],
> [3]](input=HepRelVertex#6,inputs=0..2,exprs=[CAST($0):TINYINT])] produced
> rel#42:LogicalProject.NONE.[0](input=HepRelVertex#6,inputs=0)
> {noformat}
> +Proposed logging+
> {noformat}
> 2021-07-27 14:37:58,260 [ForkJoinPool-1-worker-9] DEBUG - Rule
> FilterIntoJoinRule produced:
> LogicalProject(EMPNO=[$0], ENAME=[$1], JOB=[$2], MGR=[$3], HIREDATE=[$4],
> SAL=[$5], COMM=[$6], DEPTNO=[$7], DEPTNO0=[CAST($8):TINYINT],
[jira] [Commented] (CALCITE-4704) Log produced plan after rule application using explain formatting
[
https://issues.apache.org/jira/browse/CALCITE-4704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17388040#comment-17388040
]
Vladimir Sitnikov commented on CALCITE-4704:
How about adding an extra category for the full tree logging so one can
explicitly enable or disable tree logging?
I'm afraid if we always log "before and after" explains, the system would log
too much information.
Side ideas:
a) log "after" plans as "diffs"
b) implement "per-session trace file". For instance: "alter session trace
(explain) to ...; explain plan for ...; alter session disable trace". Then
fine-grained output could be written to a dedicated trace file so it is might
be easier to parse in the future (e.g. open with visualizers, etc)
> Log produced plan after rule application using explain formatting
> -
>
> Key: CALCITE-4704
> URL: https://issues.apache.org/jira/browse/CALCITE-4704
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.27.0
>Reporter: Stamatis Zampetakis
>Assignee: Stamatis Zampetakis
>Priority: Major
> Fix For: 1.28.0
>
>
> In many cases, we want to identify which rule lead to a certain
> transformation in the plan or need to observe how the query plan evolves by
> applying some rules in order to fix some bug or find the right place to
> introduce another optimization step.
> Currently there are some logs during the application of a rule triggered by
> the
> [HepPlanner|https://github.com/apache/calcite/blob/e04f3b08dcfb6910ff4df3810772c346b25ed424/core/src/main/java/org/apache/calcite/plan/AbstractRelOptPlanner.java#L367]
> and
> [VolcanoPlanner|https://github.com/apache/calcite/blob/e04f3b08dcfb6910ff4df3810772c346b25ed424/core/src/main/java/org/apache/calcite/plan/volcano/VolcanoRuleCall.java#L126]
> but they more or less display only the top operator of the transformation
> and not the whole subtree. Moreover, the {{RelNode#toString}} used in these
> logs, is not self-contained, so in order to check the transformation the log
> entry needs to be matched with other logs.
> It would help if instead of displaying only the top operator we logged the
> equivalent of explain (i.e., {{RelOptUtil.toString}}) on the transformed
> sub-tree.
> You can find below some extracts from the current logs and how the proposed
> log could look like.
> *HepPlanner*
> +Current logging+
> {noformat}
> 2021-07-27 14:37:58,252 [ForkJoinPool-1-worker-9] DEBUG - call#0: Rule
> FilterIntoJoinRule arguments
> [rel#9:LogicalFilter.NONE.[](input=HepRelVertex#8,condition==($7, $8)),
> rel#7:LogicalJoin.NONE.[](left=HepRelVertex#5,right=HepRelVertex#6,condition=true,joinType=left)]
> produced
> rel#14:LogicalProject.NONE.[](input=LogicalJoin#13,inputs=0..7,exprs=[CAST($8):TINYINT,
> $9, $10])
> 2021-07-27 14:37:58,266 [ForkJoinPool-1-worker-9] DEBUG - call#1: Rule
> ProjectJoinTransposeRule arguments
> [rel#16:LogicalProject.NONE.[](input=HepRelVertex#15,inputs=0..7,exprs=[CAST($8):TINYINT,
> $9, $10]),
> rel#13:LogicalJoin.NONE.[](left=HepRelVertex#5,right=HepRelVertex#6,condition==($7,
> $8),joinType=inner)] produced
> rel#21:LogicalProject.NONE.[](input=LogicalJoin#20,inputs=0..7,exprs=[$11,
> $9, $10])
> 2021-07-27 14:37:58,269 [ForkJoinPool-1-worker-9] DEBUG - call#3: Rule
> ProjectMergeRule arguments
> [rel#11:LogicalProject.NONE.[](input=HepRelVertex#27,exprs=[$1]),
> rel#26:LogicalProject.NONE.[](input=HepRelVertex#25,inputs=0..7,exprs=[$11,
> $9, $10])] produced
> rel#28:LogicalProject.NONE.[](input=HepRelVertex#25,exprs=[$1])
> 2021-07-27 14:37:58,272 [ForkJoinPool-1-worker-9] DEBUG - call#4: Rule
> ProjectJoinTransposeRule arguments
> [rel#28:LogicalProject.NONE.[](input=HepRelVertex#25,exprs=[$1]),
> rel#24:LogicalJoin.NONE.[](left=HepRelVertex#22,right=HepRelVertex#23,condition==($7,
> $8),joinType=inner)] produced
> rel#33:LogicalProject.NONE.[](input=LogicalJoin#32,inputs=0)
> 2021-07-27 14:37:58,274 [ForkJoinPool-1-worker-9] DEBUG - call#6: Rule
> ProjectMergeRule arguments
> [rel#30:LogicalProject.NONE.[](input=HepRelVertex#22,exprs=[$1, $7]),
> rel#18:LogicalProject.NONE.[0](input=HepRelVertex#5,inputs=0..7)] produced
> rel#40:LogicalProject.NONE.[](input=HepRelVertex#5,exprs=[$1, $7])
> 2021-07-27 14:37:58,275 [ForkJoinPool-1-worker-9] DEBUG - call#7: Rule
> ProjectMergeRule arguments
> [rel#31:LogicalProject.NONE.[0](input=HepRelVertex#23,inputs=0),
> rel#19:LogicalProject.NONE.[[0],
> [3]](input=HepRelVertex#6,inputs=0..2,exprs=[CAST($0):TINYINT])] produced
> rel#42:LogicalProject.NONE.[0](input=HepRelVertex#6,inputs=0)
> {noformat}
> +Proposed logging+
> {noformat}
> 2021-07-27 14:37:58,260 [ForkJoinPool-1-worker-9] DEBUG - Rule
> FilterIntoJoinRule produced:
>
[jira] [Commented] (CALCITE-4701) Implement and publish Gradle plugin for extending the parser
[ https://issues.apache.org/jira/browse/CALCITE-4701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17387520#comment-17387520 ] Vladimir Sitnikov commented on CALCITE-4701: Sample parser extension: https://github.com/vmware/declarative-cluster-management/pull/124 > Implement and publish Gradle plugin for extending the parser > > > Key: CALCITE-4701 > URL: https://issues.apache.org/jira/browse/CALCITE-4701 > Project: Calcite > Issue Type: Improvement > Components: core >Affects Versions: 1.27.0 >Reporter: Vladimir Sitnikov >Priority: Major > > Currently, calcite-core.jar contains the relevant parser template files, > however, the usage of the templates is not clear from the client perspective > (especially when you are new to Calcite). > It would be nice if Calcite published a plugin that simplifies building a > parser extension. > We could reuse the same plugin in calcite-babel module. Currently babel > references $rootDir/core/... directrly rather than fetching the parser > templates from core jar. > It might make sense to ship parser templates in its own jar file, however, I > have no strong opinion here. Parser.jj consumes <1% of the compressed jar > size(225K compresses to 44K), so it is not a big deal, yet having a > meaningful artifact name for the parser templates looks like the right thing > to do. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CALCITE-4701) Implement and publish Gradle plugin for extending the parser
Vladimir Sitnikov created CALCITE-4701: -- Summary: Implement and publish Gradle plugin for extending the parser Key: CALCITE-4701 URL: https://issues.apache.org/jira/browse/CALCITE-4701 Project: Calcite Issue Type: Improvement Components: core Affects Versions: 1.27.0 Reporter: Vladimir Sitnikov Currently, calcite-core.jar contains the relevant parser template files, however, the usage of the templates is not clear from the client perspective (especially when you are new to Calcite). It would be nice if Calcite published a plugin that simplifies building a parser extension. We could reuse the same plugin in calcite-babel module. Currently babel references $rootDir/core/... directrly rather than fetching the parser templates from core jar. It might make sense to ship parser templates in its own jar file, however, I have no strong opinion here. Parser.jj consumes <1% of the compressed jar size(225K compresses to 44K), so it is not a big deal, yet having a meaningful artifact name for the parser templates looks like the right thing to do. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CALCITE-4679) Search/sarg simplification leaves is not null(literal) unsimplified
Vladimir Sitnikov created CALCITE-4679:
--
Summary: Search/sarg simplification leaves is not null(literal)
unsimplified
Key: CALCITE-4679
URL: https://issues.apache.org/jira/browse/CALCITE-4679
Project: Calcite
Issue Type: Improvement
Components: core
Reporter: Vladimir Sitnikov
Case: {{SEARCH(100500, Sarg[=])}} (Sarg[=] is "all values match, unknown as
unknown").
While the issue does not look severe, it results in rex fuzzer false positives,
so it might mask true bugs.
Expected: {{true}}
Actual:
{noformat}
unknown as unknown: OR(IS NOT NULL(0), null)
unknown as false: IS NOT NULL(0)
unknown as true: true <-- finally got the right answer
{noformat}
Test:
{code:java}
checkSimplify(
rexBuilder.makeCall(
SqlStdOperatorTable.SEARCH,
literal(BigDecimal.ZERO),
rexBuilder.makeSearchArgumentLiteral(
Sarg.of(RexUnknownAs.UNKNOWN,
ImmutableRangeSet.of(Range.all())),
tInt())),
"true"
);
{code}
---
fuzzer:
{code:java}
@Test void singleFuzzyTest() {
Random r = new Random();
r.setSeed(-8889103384303613092L);
RexFuzzer fuzzer = new RexFuzzer(rexBuilder, typeFactory);
generateRexAndCheckTrueFalse(fuzzer, r);
}{code}
{noformat}
AssertionFailedError: SEARCH(100500, Sarg[=])
rexBuilder.makeCall(SqlStdOperatorTable.SEARCH, literal(100500),
literal(Sarg[=])) isAlwaysTrue, so it should simplify to TRUE unknownAsFalse
==> expected: but was:
at org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:55)
at
org.junit.jupiter.api.AssertionUtils.failNotEqual(AssertionUtils.java:69)
at
org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:188)
at org.junit.jupiter.api.Assertions.assertEquals(Assertions.java:1146)
at
org.apache.calcite.test.fuzzer.RexProgramFuzzyTest.checkUnknownAs(RexProgramFuzzyTest.java:251)
at
org.apache.calcite.test.fuzzer.RexProgramFuzzyTest.checkUnknownAsAndShrink(RexProgramFuzzyTest.java:202)
at
org.apache.calcite.test.fuzzer.RexProgramFuzzyTest.checkUnknownAs(RexProgramFuzzyTest.java:165)
at
org.apache.calcite.test.fuzzer.RexProgramFuzzyTest.generateRexAndCheckTrueFalse(RexProgramFuzzyTest.java:454)
at
org.apache.calcite.test.fuzzer.RexProgramFuzzyTest.singleFuzzyTest(RexProgramFuzzyTest.java:463)
{noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (CALCITE-4678) AssertionError: result mismatch when simplifying case+search+isdistinctfrom+isnottrue
Vladimir Sitnikov created CALCITE-4678:
--
Summary: AssertionError: result mismatch when simplifying
case+search+isdistinctfrom+isnottrue
Key: CALCITE-4678
URL: https://issues.apache.org/jira/browse/CALCITE-4678
Project: Calcite
Issue Type: Improvement
Components: core
Reporter: Vladimir Sitnikov
Frankly speaking, I do not know what triggers the issue. so the issue summary
is abstract for now.
I do not know the expected outcome, however, I expect that Calcite should not
fail with AssertionErrors.
Test case:
{code:java}
checkSimplifyAs(
isNotTrue(
case_(
rexBuilder.makeCall(
SqlStdOperatorTable.SEARCH,
vInt(1),
rexBuilder.makeSearchArgumentLiteral(
Sarg.of(
RexUnknownAs.TRUE,
ImmutableRangeSet.of(Range.lessThan(BigDecimal.ZERO))),
tInt())),
trueLiteral,
le(trueLiteral, isDistinctFrom(literal(0), literal(0),
RexUnknownAs.TRUE,
is("no idea what is expected"));
{code}
Error:
{noformat}
result mismatch (unknown as TRUE): when applied to {?0.int1=NULL},
IS NOT TRUE(CASE(SEARCH(?0.int1, Sarg[(-∞..0); NULL AS TRUE]), true, <=(true,
IS DISTINCT FROM(0, 0 yielded false;
AND(IS NOT DISTINCT FROM(0, 0), >=(?0.int1, 0)) yielded true
java.lang.AssertionError: result mismatch (unknown as TRUE): when applied to
{?0.int1=NULL},
IS NOT TRUE(CASE(SEARCH(?0.int1, Sarg[(-∞..0); NULL AS TRUE]), true, <=(true,
IS DISTINCT FROM(0, 0 yielded false;
AND(IS NOT DISTINCT FROM(0, 0), >=(?0.int1, 0)) yielded true
at org.apache.calcite.rex.RexSimplify.verify(RexSimplify.java:2098)
at
org.apache.calcite.rex.RexSimplify.simplifyUnknownAs(RexSimplify.java:250)
at
org.apache.calcite.rex.RexProgramTestBase.checkSimplifyAs(RexProgramTestBase.java:152){noformat}
The relevant fuzzer-driven case is
{code:java}
@Test void singleFuzzyTest() {
Random r = new Random();
r.setSeed(6192825841324574146L);
RexFuzzer fuzzer = new RexFuzzer(rexBuilder, typeFactory);
generateRexAndCheckTrueFalse(fuzzer, r);
}{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (CALCITE-2322) Add fetch size support to connection url and JDBC statement
[
https://issues.apache.org/jira/browse/CALCITE-2322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17371594#comment-17371594
]
Vladimir Sitnikov edited comment on CALCITE-2322 at 6/29/21, 7:22 PM:
--
Just in case, I think {{(default_)fetch_size_rows}} and
{{(default_)fetch_size_bytes}} are more consistent (and they are consistent
with {{setFetchSize}} JDBC API name) than {{fetch_row_count}} and
{{fetch_byte_count}} (?) {{fetch_bytes}} (?). I don't really know how to add a
byte-sized property side by side with {{fetch_row_count}}.
Julian asked for a byte-size property in 2018
(https://issues.apache.org/jira/browse/CALCITE-2322?focusedCommentId=16484416=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16484416),
and I missed the comments completely.
was (Author: vladimirsitnikov):
Just in case, I think {{(default_)fetch_size_rows}} and
{{(default_)fetch_size_bytes}} are more consistent than {{fetch_row_count}} and
{{fetch_byte_count}} (?) {{fetch_bytes}} (?). I don't really know how to add a
byte-sized property side by side with {{fetch_row_count}}.
Julian asked for a byte-size property in 2018
(https://issues.apache.org/jira/browse/CALCITE-2322?focusedCommentId=16484416=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16484416),
and I missed the comments completely.
> Add fetch size support to connection url and JDBC statement
> ---
>
> Key: CALCITE-2322
> URL: https://issues.apache.org/jira/browse/CALCITE-2322
> Project: Calcite
> Issue Type: Improvement
> Components: avatica, core
>Affects Versions: 1.11.0
>Reporter: Kevin Minder
>Priority: Major
> Time Spent: 2h 40m
> Remaining Estimate: 0h
>
> Currently the remote driver defaults to hard coded fetch size of 100 rows.
> When a connection is operating in HTTP mode having such a small fetch size
> can add enormous overhead. This is especially true if TLS connections are
> used and made worse if each connection flows throw multiple proxies.
> Consider that 100K rows returned 100 rows at a time will make 1K HTTP POST
> requests. One might say that nobody should ever do that but some tools like
> Spotfire may end up doing this.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-2322) Add fetch size support to connection url and JDBC statement
[
https://issues.apache.org/jira/browse/CALCITE-2322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17371594#comment-17371594
]
Vladimir Sitnikov commented on CALCITE-2322:
Just in case, I think {{(default_)fetch_size_rows}} and
{{(default_)fetch_size_bytes}} are more consistent than {{fetch_row_count}} and
{{fetch_byte_count}} (?) {{fetch_bytes}} (?). I don't really know how to add a
byte-sized property side by side with {{fetch_row_count}}.
Julian asked for a byte-size property in 2018
(https://issues.apache.org/jira/browse/CALCITE-2322?focusedCommentId=16484416=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16484416),
and I missed the comments completely.
> Add fetch size support to connection url and JDBC statement
> ---
>
> Key: CALCITE-2322
> URL: https://issues.apache.org/jira/browse/CALCITE-2322
> Project: Calcite
> Issue Type: Improvement
> Components: avatica, core
>Affects Versions: 1.11.0
>Reporter: Kevin Minder
>Priority: Major
> Time Spent: 2h 40m
> Remaining Estimate: 0h
>
> Currently the remote driver defaults to hard coded fetch size of 100 rows.
> When a connection is operating in HTTP mode having such a small fetch size
> can add enormous overhead. This is especially true if TLS connections are
> used and made worse if each connection flows throw multiple proxies.
> Consider that 100K rows returned 100 rows at a time will make 1K HTTP POST
> requests. One might say that nobody should ever do that but some tools like
> Spotfire may end up doing this.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-2322) Add fetch size support to connection url and JDBC statement
[ https://issues.apache.org/jira/browse/CALCITE-2322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17371587#comment-17371587 ] Vladimir Sitnikov commented on CALCITE-2322: Just in case, the users rarely need "row count" when they configure fetch size. In 99.42% of the cases what they need is to make sure fetch size is big enough (to avoid too many roundtrips), and they want it small enough (to avoid out of memory conditions). So, in my opinion, what they really need is "fetch_size_bytes" rather than "fetch_size_rows". Unfortunately, JDBC spec is broken there, and there's no API for "fetch size bytes", however, the databases might support that (e.g. "please fetch 1 rows maximum, but stop as soon as you overflow 1 megabyte"). Suppose dynamic fetch would be implemented in the future. In other words, Avatica could fetch more or fewer rows depending on the volume of the data (e.g. to prevent too small or too large resultsets). I guess it is more or less the direction many JDBC drivers are moving. In that case, default_... makes it easier to reason: ok, this is a default fetch size we start from, then it could adapt. In other words: suppose you configure fetch_row_count=42, and you do not call setFetchSize with Java API. Is the system allowed to fetch 1000 rows behind the scenes? My point is that default_fetch_row_count=42 (or default_fetch_size_rows or even default_fetch_size_bytes) would keep the door open. However, I do not insist on the naming since there is no single right answer. As far as I know, Microsoft SQL Server JDBC driver supports only dynamic fetch algorithm (I guess they just ignore setFetchSize calls). > Add fetch size support to connection url and JDBC statement > --- > > Key: CALCITE-2322 > URL: https://issues.apache.org/jira/browse/CALCITE-2322 > Project: Calcite > Issue Type: Improvement > Components: avatica, core >Affects Versions: 1.11.0 >Reporter: Kevin Minder >Priority: Major > Time Spent: 2h 40m > Remaining Estimate: 0h > > Currently the remote driver defaults to hard coded fetch size of 100 rows. > When a connection is operating in HTTP mode having such a small fetch size > can add enormous overhead. This is especially true if TLS connections are > used and made worse if each connection flows throw multiple proxies. > Consider that 100K rows returned 100 rows at a time will make 1K HTTP POST > requests. One might say that nobody should ever do that but some tools like > Spotfire may end up doing this. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-2322) Add fetch size support to connection url and JDBC statement
[ https://issues.apache.org/jira/browse/CALCITE-2322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17371499#comment-17371499 ] Vladimir Sitnikov commented on CALCITE-2322: "fetch_row_count" implies that Avatica would **always** use the given row count. That is too restrictive, and it creates ambiguities: "what if I specify fetch_row_count both at connection and at the statement level?" "default_fetch_row_count" makes perfect sense for the connection property: it tells the connection which value to start with, and then the implementation should be free to adjust it. > Add fetch size support to connection url and JDBC statement > --- > > Key: CALCITE-2322 > URL: https://issues.apache.org/jira/browse/CALCITE-2322 > Project: Calcite > Issue Type: Improvement > Components: avatica, core >Affects Versions: 1.11.0 >Reporter: Kevin Minder >Priority: Major > Time Spent: 2h 40m > Remaining Estimate: 0h > > Currently the remote driver defaults to hard coded fetch size of 100 rows. > When a connection is operating in HTTP mode having such a small fetch size > can add enormous overhead. This is especially true if TLS connections are > used and made worse if each connection flows throw multiple proxies. > Consider that 100K rows returned 100 rows at a time will make 1K HTTP POST > requests. One might say that nobody should ever do that but some tools like > Spotfire may end up doing this. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (CALCITE-2322) Add fetch size support to connection url and JDBC statement
[ https://issues.apache.org/jira/browse/CALCITE-2322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17371499#comment-17371499 ] Vladimir Sitnikov edited comment on CALCITE-2322 at 6/29/21, 3:50 PM: -- "fetch_row_count" implies that Avatica would **always** use the given row count. That is too restrictive, and it creates ambiguities: "what if I specify fetch_row_count both at connection and at the statement level?" "default_fetch_row_count" makes perfect sense for the connection property: it tells the connection which value to start with, and then the implementation should be free to adjust it (e.g. the implementation could use dynamic fetch size if it wants). was (Author: vladimirsitnikov): "fetch_row_count" implies that Avatica would **always** use the given row count. That is too restrictive, and it creates ambiguities: "what if I specify fetch_row_count both at connection and at the statement level?" "default_fetch_row_count" makes perfect sense for the connection property: it tells the connection which value to start with, and then the implementation should be free to adjust it. > Add fetch size support to connection url and JDBC statement > --- > > Key: CALCITE-2322 > URL: https://issues.apache.org/jira/browse/CALCITE-2322 > Project: Calcite > Issue Type: Improvement > Components: avatica, core >Affects Versions: 1.11.0 >Reporter: Kevin Minder >Priority: Major > Time Spent: 2h 40m > Remaining Estimate: 0h > > Currently the remote driver defaults to hard coded fetch size of 100 rows. > When a connection is operating in HTTP mode having such a small fetch size > can add enormous overhead. This is especially true if TLS connections are > used and made worse if each connection flows throw multiple proxies. > Consider that 100K rows returned 100 rows at a time will make 1K HTTP POST > requests. One might say that nobody should ever do that but some tools like > Spotfire may end up doing this. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CALCITE-4658) Introduce refaster for automatic code refactoring
[
https://issues.apache.org/jira/browse/CALCITE-4658?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Sitnikov updated CALCITE-4658:
---
Summary: Introduce refaster for automatic code refactoring (was: Introduce
refaster for automatic reformat of the code)
> Introduce refaster for automatic code refactoring
> -
>
> Key: CALCITE-4658
> URL: https://issues.apache.org/jira/browse/CALCITE-4658
> Project: Calcite
> Issue Type: Improvement
>Reporter: Vladimir Sitnikov
>Priority: Major
>
> Sometimes we have API usage rules which require manual actions to correct.
> For instance, we "forbid" the use of {{Lists#newArrayList()}}, and suggest
> replacing it with {{new ArrayList()}}.
> It would be better if the build script could perform such replacements
> automatically.
> Refaster is a smart refactoring library for Java:
> https://errorprone.info/docs/refaster, and it could help us to keep the code
> up to date.
> Of course, forbidden-apis checks might still be there (e.g. for those who
> prefer manual replacements), however, adding automatic code cleanups would be
> great.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (CALCITE-4659) Introduce AssertJ and gradually migrate to its usage instead of Hamcrest
Vladimir Sitnikov created CALCITE-4659:
--
Summary: Introduce AssertJ and gradually migrate to its usage
instead of Hamcrest
Key: CALCITE-4659
URL: https://issues.apache.org/jira/browse/CALCITE-4659
Project: Calcite
Issue Type: Improvement
Reporter: Vladimir Sitnikov
AssertJ has already been discussed in CALCITE-2457, yet it was forgotten.
Note: I do not suggest replacing all the assertions with AssertJ, especially
"compare with golden output" ones.
The current issues with {{assertThat}}-based tests:
1) {{asertTrue}}, {{assertEquals(Object, Object)}} are prone to mistakes so one
can get "expected vs actual wrong".
2) Hamcrest matches are hard to discover. In other words, one cant use
autocomplete menu in IDE to see which other matches are available.
3) Hamcrest matches are hard to extend/implement. For instance, we have very
limited amount of Hamcrest-based matches, and we do have a lot of
Calcite-specific assertions.
AssertJ solves the issue of API discoverability (one writes
{{assertThat(...).containsExactly("skippedTest")}}), and AssertJ has a
well-known path for extensibility. We can implement Calcite-specific assertions
with AssertJ style, so the tests would be more consistent.
Refaster templates (see CALCITE-4658) might help to perform automatic
conversion from JUnit-style assertions to AssertJ.
There are templates to cleanup AssertJ assertions:
https://github.com/palantir/assertj-automation
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (CALCITE-4658) Introduce refaster for automatic reformat of the code
Vladimir Sitnikov created CALCITE-4658:
--
Summary: Introduce refaster for automatic reformat of the code
Key: CALCITE-4658
URL: https://issues.apache.org/jira/browse/CALCITE-4658
Project: Calcite
Issue Type: Improvement
Reporter: Vladimir Sitnikov
Sometimes we have API usage rules which require manual actions to correct.
For instance, we "forbid" the use of {{Lists#newArrayList()}}, and suggest
replacing it with {{new ArrayList()}}.
It would be better if the build script could perform such replacements
automatically.
Refaster is a smart refactoring library for Java:
https://errorprone.info/docs/refaster, and it could help us to keep the code up
to date.
Of course, forbidden-apis checks might still be there (e.g. for those who
prefer manual replacements), however, adding automatic code cleanups would be
great.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-4655) NullPointerException in JdbcTable.scan
[
https://issues.apache.org/jira/browse/CALCITE-4655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17366272#comment-17366272
]
Vladimir Sitnikov commented on CALCITE-4655:
Oh, no idea how I missed the initialization. Thanks for the correction
> NullPointerException in JdbcTable.scan
> --
>
> Key: CALCITE-4655
> URL: https://issues.apache.org/jira/browse/CALCITE-4655
> Project: Calcite
> Issue Type: Improvement
>Affects Versions: 1.26.0, 1.27.0
>Reporter: Ulrich Kramer
>Priority: Major
> Labels: pull-request-available
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Calling {{JdbcTable.scan}} will result in a {{NullPointerException}} because
> inside {{JdbcTable.fieldClasses}} {{protoRowType}} is null.
> This could easily be fixed by replacing
> {code:java}
> final RelDataType rowType = requireNonNull(protoRowType,
> "protoRowType").apply(typeFactory);
> {code}
> with
> {code:java}
> final RelDataType rowType = getRowType(typeFactory);
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-4657) Replace cancel-workflow-runs with GitHub in-core cancel-in-progress feature
[ https://issues.apache.org/jira/browse/CALCITE-4657?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Sitnikov updated CALCITE-4657: --- Description: See https://docs.github.com/en/actions/reference/workflow-syntax-for-github-actions#concurrency https://github.com/potiuk/cancel-workflow-runs is deprecated See Airflow commit https://github.com/apache/airflow/commit/9c98a60cdd29f0b005bf3abdbfc42aba419fded8 was: See https://docs.github.com/en/actions/reference/workflow-syntax-for-github-actions#concurrency https://github.com/potiuk/cancel-workflow-runs is deprecated > Replace cancel-workflow-runs with GitHub in-core cancel-in-progress feature > --- > > Key: CALCITE-4657 > URL: https://issues.apache.org/jira/browse/CALCITE-4657 > Project: Calcite > Issue Type: Improvement >Reporter: Vladimir Sitnikov >Priority: Major > > See > https://docs.github.com/en/actions/reference/workflow-syntax-for-github-actions#concurrency > https://github.com/potiuk/cancel-workflow-runs is deprecated > See Airflow commit > https://github.com/apache/airflow/commit/9c98a60cdd29f0b005bf3abdbfc42aba419fded8 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CALCITE-4657) Replace cancel-workflow-runs with GitHub in-core cancel-in-progress feature
Vladimir Sitnikov created CALCITE-4657: -- Summary: Replace cancel-workflow-runs with GitHub in-core cancel-in-progress feature Key: CALCITE-4657 URL: https://issues.apache.org/jira/browse/CALCITE-4657 Project: Calcite Issue Type: Improvement Reporter: Vladimir Sitnikov See https://docs.github.com/en/actions/reference/workflow-syntax-for-github-actions#concurrency https://github.com/potiuk/cancel-workflow-runs is deprecated -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-4655) NullPointerException in JdbcTable.scan
[
https://issues.apache.org/jira/browse/CALCITE-4655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17366139#comment-17366139
]
Vladimir Sitnikov commented on CALCITE-4655:
In practice, `protoRowType` is a `private` field in `JdbcTable` which is never
initialized:
https://github.com/apache/calcite/blob/4e679f03771c89ffa463051b5698ead1d935748b/core/src/main/java/org/apache/calcite/adapter/jdbc/JdbcTable.java#L78
I suggest we remove {{JdbcTable#protoRowType}} field to avoid confusion.
> NullPointerException in JdbcTable.scan
> --
>
> Key: CALCITE-4655
> URL: https://issues.apache.org/jira/browse/CALCITE-4655
> Project: Calcite
> Issue Type: Improvement
>Affects Versions: 1.26.0, 1.27.0
>Reporter: Ulrich Kramer
>Priority: Major
> Labels: pull-request-available
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Calling {{JdbcTable.scan}} will result in a {{NullPointerException}} because
> inside {{JdbcTable.fieldClasses}} {{protoRowType}} is null.
> This could easily be fixed by replacing
> {code:java}
> final RelDataType rowType = requireNonNull(protoRowType,
> "protoRowType").apply(typeFactory);
> {code}
> with
> {code:java}
> final RelDataType rowType = getRowType(typeFactory);
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (CALCITE-4618) Refine dependency declarations to better account for type annotations
Vladimir Sitnikov created CALCITE-4618: -- Summary: Refine dependency declarations to better account for type annotations Key: CALCITE-4618 URL: https://issues.apache.org/jira/browse/CALCITE-4618 Project: Calcite Issue Type: Improvement Affects Versions: 1.26.0 Reporter: Vladimir Sitnikov -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-4613) OWASP dependency-check tasks fail due to missing resources
[
https://issues.apache.org/jira/browse/CALCITE-4613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17348547#comment-17348547
]
Vladimir Sitnikov commented on CALCITE-4613:
Thanks for the pointer. I should probably isolate the dependencies for
s3-build-cache
> OWASP dependency-check tasks fail due to missing resources
> --
>
> Key: CALCITE-4613
> URL: https://issues.apache.org/jira/browse/CALCITE-4613
> Project: Calcite
> Issue Type: Bug
> Components: build
>Affects Versions: 1.26.0
>Reporter: Stamatis Zampetakis
>Assignee: Stamatis Zampetakis
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.27.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Running any of the following Gradle tasks:
> * dependencyCheckAggregate
> * dependencyCheckAnalyze
> * dependencyCheckPurge
> * dependencyCheckUpdate
> fails due to missing resources.
> For instance the following command:
> {code:sh}
> ./gradlew dependencyCheckUpdate
> {code}
> leads to the following stacktrace:
> {noformat}
> Unable to download meta file:
> https://nvd.nist.gov/feeds/json/cve/1.0/nvdcve-1.0-modified.meta; received
> 404 -- resource not found
> org.owasp.dependencycheck.data.update.exception.UpdateException: Unable to
> download meta file:
> https://nvd.nist.gov/feeds/json/cve/1.0/nvdcve-1.0-modified.meta; received
> 404 -- resource not found
> at
> org.owasp.dependencycheck.data.update.NvdCveUpdater.getMetaFile(NvdCveUpdater.java:351)
> at
> org.owasp.dependencycheck.data.update.NvdCveUpdater.getUpdatesNeeded(NvdCveUpdater.java:385)
> at
> org.owasp.dependencycheck.data.update.NvdCveUpdater.update(NvdCveUpdater.java:122)
> at org.owasp.dependencycheck.Engine.doUpdates(Engine.java:922)
> at org.owasp.dependencycheck.Engine.doUpdates(Engine.java:889)
> at org.owasp.dependencycheck.Engine$doUpdates.call(Unknown Source)
> at
> org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:47)
> at
> org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:115)
> at
> org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:119)
> at
> org.owasp.dependencycheck.gradle.tasks.Update.update(Update.groovy:70)
> 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.gradle.internal.reflect.JavaMethod.invoke(JavaMethod.java:104)
> at
> org.gradle.api.internal.project.taskfactory.StandardTaskAction.doExecute(StandardTaskAction.java:58)
> at
> org.gradle.api.internal.project.taskfactory.StandardTaskAction.execute(StandardTaskAction.java:51)
> at
> org.gradle.api.internal.project.taskfactory.StandardTaskAction.execute(StandardTaskAction.java:29)
> at
> org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter$2.run(ExecuteActionsTaskExecuter.java:494)
> at
> org.gradle.internal.operations.DefaultBuildOperationRunner$1.execute(DefaultBuildOperationRunner.java:29)
> at
> org.gradle.internal.operations.DefaultBuildOperationRunner$1.execute(DefaultBuildOperationRunner.java:26)
> at
> org.gradle.internal.operations.DefaultBuildOperationRunner$3.execute(DefaultBuildOperationRunner.java:75)
> at
> org.gradle.internal.operations.DefaultBuildOperationRunner$3.execute(DefaultBuildOperationRunner.java:68)
> at
> org.gradle.internal.operations.DefaultBuildOperationRunner.execute(DefaultBuildOperationRunner.java:153)
> at
> org.gradle.internal.operations.DefaultBuildOperationRunner.execute(DefaultBuildOperationRunner.java:68)
> at
> org.gradle.internal.operations.DefaultBuildOperationRunner.run(DefaultBuildOperationRunner.java:56)
> at
> org.gradle.internal.operations.DefaultBuildOperationExecutor.lambda$run$1(DefaultBuildOperationExecutor.java:71)
> at
> org.gradle.internal.operations.UnmanagedBuildOperationWrapper.runWithUnmanagedSupport(UnmanagedBuildOperationWrapper.java:45)
> at
> org.gradle.internal.operations.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:71)
> at
> org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.executeAction(ExecuteActionsTaskExecuter.java:479)
> at
> org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.executeActions(ExecuteActionsTaskExecuter.java:462)
> at
>
[jira] [Updated] (CALCITE-4612) Fuzzer for RelBuilder
[ https://issues.apache.org/jira/browse/CALCITE-4612?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Sitnikov updated CALCITE-4612: --- Description: A generator of random rels would be useful for testing: a) Generate rel, write it down as SQL (ensures "Rel to SQL" does not fail), parse it back (ensures parser works OK), plans the tree (ensures the rules do not throw exceptions) b) Generate rel, serialize with one of the adapters (e.g. serialize to ElasticSearch). c) Generate rel, and execute it with https://github.com/sqlancer/sqlancer (or alike) approach to verify the results of the query. It might surface **correctness** bugs in optimizer, not just NPEs Open questions: Q1) Which tables/columns should be used? It looks like we should start with VALUES, and then we could add a random table/column generator. was: A generator of random rels would be useful for testing: a) Generate rel, write it down as SQL (ensures "Rel to SQL" does not fail), parse it back (ensures parser works OK), plans the tree (ensures the rules do not throw exceptions) b) Generate rel, serialize with one of the adapters (e.g. serialize to ElasticSearch). c) Generate rel, and execute it with https://github.com/sqlancer/sqlancer (or alike) approach to verify the results of the query. It might surface **correctness** bugs in optimizer, not just NPEs > Fuzzer for RelBuilder > - > > Key: CALCITE-4612 > URL: https://issues.apache.org/jira/browse/CALCITE-4612 > Project: Calcite > Issue Type: Test > Components: core >Reporter: Vladimir Sitnikov >Priority: Major > > A generator of random rels would be useful for testing: > a) Generate rel, write it down as SQL (ensures "Rel to SQL" does not fail), > parse it back (ensures parser works OK), plans the tree (ensures the rules do > not throw exceptions) > b) Generate rel, serialize with one of the adapters (e.g. serialize to > ElasticSearch). > c) Generate rel, and execute it with https://github.com/sqlancer/sqlancer (or > alike) approach to verify the results of the query. It might surface > **correctness** bugs in optimizer, not just NPEs > > Open questions: > Q1) Which tables/columns should be used? It looks like we should start with > VALUES, and then we could add a random table/column generator. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-4610) Sarg in JOIN -> AssertionError in RelToSqlConverter
[
https://issues.apache.org/jira/browse/CALCITE-4610?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17347364#comment-17347364
]
Vladimir Sitnikov commented on CALCITE-4610:
{quote} you'll find and log a bunch of bugs but you won't fix any of them. And
they'll land on my shoulders.{quote}
Not sure why you say that. I did file several issues re Sarg, however, you were
in way better position to assess and fix them, because, well, you introduced
Sarg in the same release cycle.
I do not say you are to support Sarg in the foreseeable future, however, it
would be nice if you could assist with the issues detected during the cycle you
introduced Sarg.
What I say here is it is hard to predict how features would interfere so it
might be worth trying to implement an automatic bug detector. I've filed
CALCITE-4612 to avoid off-topic here.
I've no idea how much time would it take to implement Rel fuzzer (it even
requires tables and other schema objects to work with :-/ ), but it would be
nice to get there one day.
> Sarg in JOIN -> AssertionError in RelToSqlConverter
> ---
>
> Key: CALCITE-4610
> URL: https://issues.apache.org/jira/browse/CALCITE-4610
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Steven Talbot
>Assignee: Julian Hyde
>Priority: Blocker
> Fix For: 1.27.0
>
>
>
> {code:java}
> @Test void testSargGeneratingJoinCondition() {
> final String sql = "SELECT v1.deptno, v2.deptno\n"
> + "FROM dept v1 LEFT JOIN emp v2 ON v1.deptno = v2.deptno AND v1.deptno
> < 15 AND v1.deptno > 10\n"
> + "WHERE v2.job LIKE 'PRESIDENT'";
> // note: not quite the right expected SQL, but the point is this test just
> blows up
> final String expected = "SELECT \"DEPT\".\"DEPTNO\","
> + " \"EMP\".\"DEPTNO\" AS \"DEPTNO0\"\n"
> + "FROM \"SCOTT\".\"DEPT\"\n"
> + "LEFT JOIN \"SCOTT\".\"EMP\""
> + " ON \"DEPT\".\"DEPTNO\" = \"EMP\".\"DEPTNO\"\n"
> + "WHERE \"EMP\".\"JOB\" LIKE 'PRESIDENT'";
> sql(sql)
> .schema(CalciteAssert.SchemaSpec.JDBC_SCOTT)
> .ok(expected);
> }
> {code}
> ^^ test in RelToSqlConverterTest.java
> I'm not entirely sure where in the flow between the parse into RelNode and
> the conversion from RelNode->SqlNode the Sarg is supposed to be expanded, but
> clearly, by the time it hits the RelToSqlConverter, it's too late.
>
> Stack trace:
>
> {noformat}
> SEARCH($0, Sarg[(10..15)])SEARCH($0, Sarg[(10..15)])java.lang.AssertionError:
> SEARCH($0, Sarg[(10..15)]) at
> org.apache.calcite.rel.rel2sql.SqlImplementor.convertConditionToSqlNode(SqlImplementor.java:379)
> at
> org.apache.calcite.rel.rel2sql.SqlImplementor.convertConditionToSqlNode(SqlImplementor.java:320)
> at
> org.apache.calcite.rel.rel2sql.RelToSqlConverter.visit(RelToSqlConverter.java:215)
> 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.apache.calcite.util.ReflectUtil$2.invoke(ReflectUtil.java:525) at
> org.apache.calcite.rel.rel2sql.RelToSqlConverter.dispatch(RelToSqlConverter.java:131)
> at
> org.apache.calcite.rel.rel2sql.RelToSqlConverter.visitInput(RelToSqlConverter.java:139)
> at
> org.apache.calcite.rel.rel2sql.SqlImplementor.visitInput(SqlImplementor.java:186)
> at
> org.apache.calcite.rel.rel2sql.SqlImplementor.visitInput(SqlImplementor.java:180)
> at
> org.apache.calcite.rel.rel2sql.RelToSqlConverter.visit(RelToSqlConverter.java:326)
> 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.apache.calcite.util.ReflectUtil$2.invoke(ReflectUtil.java:525) at
> org.apache.calcite.rel.rel2sql.RelToSqlConverter.dispatch(RelToSqlConverter.java:131)
> at
> org.apache.calcite.rel.rel2sql.RelToSqlConverter.visitInput(RelToSqlConverter.java:139)
> at
> org.apache.calcite.rel.rel2sql.SqlImplementor.visitInput(SqlImplementor.java:186)
> at
> org.apache.calcite.rel.rel2sql.SqlImplementor.visitInput(SqlImplementor.java:180)
> at
> org.apache.calcite.rel.rel2sql.RelToSqlConverter.visit(RelToSqlConverter.java:336)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at
[jira] [Created] (CALCITE-4612) Fuzzer for RelBuilder
Vladimir Sitnikov created CALCITE-4612: -- Summary: Fuzzer for RelBuilder Key: CALCITE-4612 URL: https://issues.apache.org/jira/browse/CALCITE-4612 Project: Calcite Issue Type: Test Components: core Reporter: Vladimir Sitnikov A generator of random rels would be useful for testing: a) Generate rel, write it down as SQL (ensures "Rel to SQL" does not fail), parse it back (ensures parser works OK), plans the tree (ensures the rules do not throw exceptions) b) Generate rel, serialize with one of the adapters (e.g. serialize to ElasticSearch). c) Generate rel, and execute it with https://github.com/sqlancer/sqlancer (or alike) approach to verify the results of the query. It might surface **correctness** bugs in optimizer, not just NPEs -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CALCITE-4610) Sarg in JOIN -> AssertionError in RelToSqlConverter
[
https://issues.apache.org/jira/browse/CALCITE-4610?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Sitnikov updated CALCITE-4610:
---
Component/s: core
Priority: Blocker (was: Major)
Updating to "blocker" as I guess the issue blocks Calcite 1.27 release :-(
[~julianhyde], WDYT?
Rel fuzzer is probably long overdue (e.g. fuzz rels via RelBuilder API). I'm
not sure if it is worth trying https://github.com/sqlancer/sqlancer for Calcite
though.
> Sarg in JOIN -> AssertionError in RelToSqlConverter
> ---
>
> Key: CALCITE-4610
> URL: https://issues.apache.org/jira/browse/CALCITE-4610
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Steven Talbot
>Priority: Blocker
> Fix For: 1.27.0
>
>
>
> {code:java}
> @Test void testSargGeneratingJoinCondition() {
> final String sql = "SELECT v1.deptno, v2.deptno\n"
> + "FROM dept v1 LEFT JOIN emp v2 ON v1.deptno = v2.deptno AND v1.deptno
> < 15 AND v1.deptno > 10\n"
> + "WHERE v2.job LIKE 'PRESIDENT'";
> // note: not quite the right expected SQL, but the point is this test just
> blows up
> final String expected = "SELECT \"DEPT\".\"DEPTNO\","
> + " \"EMP\".\"DEPTNO\" AS \"DEPTNO0\"\n"
> + "FROM \"SCOTT\".\"DEPT\"\n"
> + "LEFT JOIN \"SCOTT\".\"EMP\""
> + " ON \"DEPT\".\"DEPTNO\" = \"EMP\".\"DEPTNO\"\n"
> + "WHERE \"EMP\".\"JOB\" LIKE 'PRESIDENT'";
> sql(sql)
> .schema(CalciteAssert.SchemaSpec.JDBC_SCOTT)
> .ok(expected);
> }
> {code}
> ^^ test in RelToSqlConverterTest.java
> I'm not entirely sure where in the flow between the parse into RelNode and
> the conversion from RelNode->SqlNode the Sarg is supposed to be expanded, but
> clearly, by the time it hits the RelToSqlConverter, it's too late.
>
> Stack trace:
>
> {noformat}
> SEARCH($0, Sarg[(10..15)])SEARCH($0, Sarg[(10..15)])java.lang.AssertionError:
> SEARCH($0, Sarg[(10..15)]) at
> org.apache.calcite.rel.rel2sql.SqlImplementor.convertConditionToSqlNode(SqlImplementor.java:379)
> at
> org.apache.calcite.rel.rel2sql.SqlImplementor.convertConditionToSqlNode(SqlImplementor.java:320)
> at
> org.apache.calcite.rel.rel2sql.RelToSqlConverter.visit(RelToSqlConverter.java:215)
> 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.apache.calcite.util.ReflectUtil$2.invoke(ReflectUtil.java:525) at
> org.apache.calcite.rel.rel2sql.RelToSqlConverter.dispatch(RelToSqlConverter.java:131)
> at
> org.apache.calcite.rel.rel2sql.RelToSqlConverter.visitInput(RelToSqlConverter.java:139)
> at
> org.apache.calcite.rel.rel2sql.SqlImplementor.visitInput(SqlImplementor.java:186)
> at
> org.apache.calcite.rel.rel2sql.SqlImplementor.visitInput(SqlImplementor.java:180)
> at
> org.apache.calcite.rel.rel2sql.RelToSqlConverter.visit(RelToSqlConverter.java:326)
> 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.apache.calcite.util.ReflectUtil$2.invoke(ReflectUtil.java:525) at
> org.apache.calcite.rel.rel2sql.RelToSqlConverter.dispatch(RelToSqlConverter.java:131)
> at
> org.apache.calcite.rel.rel2sql.RelToSqlConverter.visitInput(RelToSqlConverter.java:139)
> at
> org.apache.calcite.rel.rel2sql.SqlImplementor.visitInput(SqlImplementor.java:186)
> at
> org.apache.calcite.rel.rel2sql.SqlImplementor.visitInput(SqlImplementor.java:180)
> at
> org.apache.calcite.rel.rel2sql.RelToSqlConverter.visit(RelToSqlConverter.java:336)
> 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.apache.calcite.util.ReflectUtil$2.invoke(ReflectUtil.java:525) at
> org.apache.calcite.rel.rel2sql.RelToSqlConverter.dispatch(RelToSqlConverter.java:131)
> at
> org.apache.calcite.rel.rel2sql.RelToSqlConverter.visitInput(RelToSqlConverter.java:139)
> at
> org.apache.calcite.rel.rel2sql.SqlImplementor.visitInput(SqlImplementor.java:186)
> at
> org.apache.calcite.rel.rel2sql.SqlImplementor.visitInput(SqlImplementor.java:174)
> at
> org.apache.calcite.rel.rel2sql.SqlImplementor.visitRoot(SqlImplementor.java:154)
> at
>
[jira] [Updated] (CALCITE-4610) Sarg in JOIN -> AssertionError in RelToSqlConverter
[
https://issues.apache.org/jira/browse/CALCITE-4610?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Sitnikov updated CALCITE-4610:
---
Fix Version/s: 1.27.0
> Sarg in JOIN -> AssertionError in RelToSqlConverter
> ---
>
> Key: CALCITE-4610
> URL: https://issues.apache.org/jira/browse/CALCITE-4610
> Project: Calcite
> Issue Type: Bug
>Reporter: Steven Talbot
>Priority: Major
> Fix For: 1.27.0
>
>
>
> {code:java}
> @Test void testSargGeneratingJoinCondition() {
> final String sql = "SELECT v1.deptno, v2.deptno\n"
> + "FROM dept v1 LEFT JOIN emp v2 ON v1.deptno = v2.deptno AND v1.deptno
> < 15 AND v1.deptno > 10\n"
> + "WHERE v2.job LIKE 'PRESIDENT'";
> // note: not quite the right expected SQL, but the point is this test just
> blows up
> final String expected = "SELECT \"DEPT\".\"DEPTNO\","
> + " \"EMP\".\"DEPTNO\" AS \"DEPTNO0\"\n"
> + "FROM \"SCOTT\".\"DEPT\"\n"
> + "LEFT JOIN \"SCOTT\".\"EMP\""
> + " ON \"DEPT\".\"DEPTNO\" = \"EMP\".\"DEPTNO\"\n"
> + "WHERE \"EMP\".\"JOB\" LIKE 'PRESIDENT'";
> sql(sql)
> .schema(CalciteAssert.SchemaSpec.JDBC_SCOTT)
> .ok(expected);
> }
> {code}
> ^^ test in RelToSqlConverterTest.java
> I'm not entirely sure where in the flow between the parse into RelNode and
> the conversion from RelNode->SqlNode the Sarg is supposed to be expanded, but
> clearly, by the time it hits the RelToSqlConverter, it's too late.
>
> Stack trace:
>
> {noformat}
> SEARCH($0, Sarg[(10..15)])SEARCH($0, Sarg[(10..15)])java.lang.AssertionError:
> SEARCH($0, Sarg[(10..15)]) at
> org.apache.calcite.rel.rel2sql.SqlImplementor.convertConditionToSqlNode(SqlImplementor.java:379)
> at
> org.apache.calcite.rel.rel2sql.SqlImplementor.convertConditionToSqlNode(SqlImplementor.java:320)
> at
> org.apache.calcite.rel.rel2sql.RelToSqlConverter.visit(RelToSqlConverter.java:215)
> 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.apache.calcite.util.ReflectUtil$2.invoke(ReflectUtil.java:525) at
> org.apache.calcite.rel.rel2sql.RelToSqlConverter.dispatch(RelToSqlConverter.java:131)
> at
> org.apache.calcite.rel.rel2sql.RelToSqlConverter.visitInput(RelToSqlConverter.java:139)
> at
> org.apache.calcite.rel.rel2sql.SqlImplementor.visitInput(SqlImplementor.java:186)
> at
> org.apache.calcite.rel.rel2sql.SqlImplementor.visitInput(SqlImplementor.java:180)
> at
> org.apache.calcite.rel.rel2sql.RelToSqlConverter.visit(RelToSqlConverter.java:326)
> 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.apache.calcite.util.ReflectUtil$2.invoke(ReflectUtil.java:525) at
> org.apache.calcite.rel.rel2sql.RelToSqlConverter.dispatch(RelToSqlConverter.java:131)
> at
> org.apache.calcite.rel.rel2sql.RelToSqlConverter.visitInput(RelToSqlConverter.java:139)
> at
> org.apache.calcite.rel.rel2sql.SqlImplementor.visitInput(SqlImplementor.java:186)
> at
> org.apache.calcite.rel.rel2sql.SqlImplementor.visitInput(SqlImplementor.java:180)
> at
> org.apache.calcite.rel.rel2sql.RelToSqlConverter.visit(RelToSqlConverter.java:336)
> 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.apache.calcite.util.ReflectUtil$2.invoke(ReflectUtil.java:525) at
> org.apache.calcite.rel.rel2sql.RelToSqlConverter.dispatch(RelToSqlConverter.java:131)
> at
> org.apache.calcite.rel.rel2sql.RelToSqlConverter.visitInput(RelToSqlConverter.java:139)
> at
> org.apache.calcite.rel.rel2sql.SqlImplementor.visitInput(SqlImplementor.java:186)
> at
> org.apache.calcite.rel.rel2sql.SqlImplementor.visitInput(SqlImplementor.java:174)
> at
> org.apache.calcite.rel.rel2sql.SqlImplementor.visitRoot(SqlImplementor.java:154)
> at
> org.apache.calcite.rel.rel2sql.RelToSqlConverterTest.toSql(RelToSqlConverterTest.java:197)
> at
> org.apache.calcite.rel.rel2sql.RelToSqlConverterTest.access$300(RelToSqlConverterTest.java:99)
> at
> org.apache.calcite.rel.rel2sql.RelToSqlConverterTest$Sql.exec(RelToSqlConverterTest.java:5723)
> at
>
