[jira] [Commented] (CALCITE-6393) Byte code of SqlFunctions is invalid
[
https://issues.apache.org/jira/browse/CALCITE-6393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17843075#comment-17843075
]
Stamatis Zampetakis commented on CALCITE-6393:
--
I don't think the Checkerframework is modifying the bytecode. Probably the
compiler messes up when there are annotations.
For the testing part, I have an idea of how we can plug the checks nicely to
the Gradle build. I will try to create a PR tomorrow.
> Byte code of SqlFunctions is invalid
>
>
> Key: CALCITE-6393
> URL: https://issues.apache.org/jira/browse/CALCITE-6393
> Project: Calcite
> Issue Type: Bug
>Affects Versions: 1.36.0
>Reporter: Sergey Nuyanzin
>Assignee: Stamatis Zampetakis
>Priority: Major
>
> The issue is a result of testing of Apache Calcite 1.37.0 rc 4 in this thread
> [1]
> There is test project andprocedure provided by [~MasseGuillaume] [2] (see
> also original thread where this was first discussed [3])
> it shows that since Calcite 1.36.0 it starts failing as
> {noformat}
> java.lang.ArrayIndexOutOfBoundsException: Index 65536 out of bounds for
> length 297
> at org.objectweb.asm.ClassReader.readLabel(ClassReader.java:2695)
> at org.objectweb.asm.ClassReader.createLabel(ClassReader.java:2711)
> at
> org.objectweb.asm.ClassReader.readTypeAnnotations(ClassReader.java:2777)
> at org.objectweb.asm.ClassReader.readCode(ClassReader.java:1929)
> at org.objectweb.asm.ClassReader.readMethod(ClassReader.java:1515)
> at org.objectweb.asm.ClassReader.accept(ClassReader.java:745)
> {noformat}
> Also since Calcite 1.27.0 it starts failing as
> {noformat}
> java.lang.IllegalArgumentException: Invalid end label (must be visited
> first)
> at
> org.objectweb.asm.util.CheckMethodAdapter.checkLabel(CheckMethodAdapter.java:1453)
> at
> org.objectweb.asm.util.CheckMethodAdapter.visitLocalVariableAnnotation(CheckMethodAdapter.java:996)
> at
> org.objectweb.asm.MethodVisitor.visitLocalVariableAnnotation(MethodVisitor.java:757)
> at
> org.objectweb.asm.commons.MethodRemapper.visitLocalVariableAnnotation(MethodRemapper.java:257)
> at org.objectweb.asm.ClassReader.readCode(ClassReader.java:2614)
> at org.objectweb.asm.ClassReader.readMethod(ClassReader.java:1515)
> {noformat}
> [1] https://lists.apache.org/thread/n6cs1l86mt6fc5q8pcxr97czs3p6w65f
> [2] https://github.com/MasseGuillaume/asm-remapper-bug
> [3] https://lists.apache.org/thread/o736wz4qnr4l285bj5gv073cy0qll9t0
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (CALCITE-6393) Byte code of SqlFunctions is invalid
[
https://issues.apache.org/jira/browse/CALCITE-6393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stamatis Zampetakis reassigned CALCITE-6393:
Assignee: Stamatis Zampetakis
> Byte code of SqlFunctions is invalid
>
>
> Key: CALCITE-6393
> URL: https://issues.apache.org/jira/browse/CALCITE-6393
> Project: Calcite
> Issue Type: Bug
>Affects Versions: 1.36.0
>Reporter: Sergey Nuyanzin
>Assignee: Stamatis Zampetakis
>Priority: Major
>
> The issue is a result of testing of Apache Calcite 1.37.0 rc 4 in this thread
> [1]
> There is test project andprocedure provided by [~MasseGuillaume] [2] (see
> also original thread where this was first discussed [3])
> it shows that since Calcite 1.36.0 it starts failing as
> {noformat}
> java.lang.ArrayIndexOutOfBoundsException: Index 65536 out of bounds for
> length 297
> at org.objectweb.asm.ClassReader.readLabel(ClassReader.java:2695)
> at org.objectweb.asm.ClassReader.createLabel(ClassReader.java:2711)
> at
> org.objectweb.asm.ClassReader.readTypeAnnotations(ClassReader.java:2777)
> at org.objectweb.asm.ClassReader.readCode(ClassReader.java:1929)
> at org.objectweb.asm.ClassReader.readMethod(ClassReader.java:1515)
> at org.objectweb.asm.ClassReader.accept(ClassReader.java:745)
> {noformat}
> Also since Calcite 1.27.0 it starts failing as
> {noformat}
> java.lang.IllegalArgumentException: Invalid end label (must be visited
> first)
> at
> org.objectweb.asm.util.CheckMethodAdapter.checkLabel(CheckMethodAdapter.java:1453)
> at
> org.objectweb.asm.util.CheckMethodAdapter.visitLocalVariableAnnotation(CheckMethodAdapter.java:996)
> at
> org.objectweb.asm.MethodVisitor.visitLocalVariableAnnotation(MethodVisitor.java:757)
> at
> org.objectweb.asm.commons.MethodRemapper.visitLocalVariableAnnotation(MethodRemapper.java:257)
> at org.objectweb.asm.ClassReader.readCode(ClassReader.java:2614)
> at org.objectweb.asm.ClassReader.readMethod(ClassReader.java:1515)
> {noformat}
> [1] https://lists.apache.org/thread/n6cs1l86mt6fc5q8pcxr97czs3p6w65f
> [2] https://github.com/MasseGuillaume/asm-remapper-bug
> [3] https://lists.apache.org/thread/o736wz4qnr4l285bj5gv073cy0qll9t0
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-6394) Be able to use input names instead of $i in explain
[
https://issues.apache.org/jira/browse/CALCITE-6394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17842872#comment-17842872
]
Stamatis Zampetakis commented on CALCITE-6394:
--
In order to complete/define the spec for this new feature it would be nice to
include the current calcite plan for the certain queries and the
expected/desired ones.
In terms of implementation, as others have mentioned in the dev list, probably
we need a new implementation of the {{RelWriter}} interface that leverages the
{{RelMetadataQuery#getColumnOrigins}} metadata.
> Be able to use input names instead of $i in explain
> ---
>
> Key: CALCITE-6394
> URL: https://issues.apache.org/jira/browse/CALCITE-6394
> Project: Calcite
> Issue Type: Improvement
>Reporter: Gonzalo Ortiz
>Priority: Major
>
> As Apache Pinot committer, one of the request I've found from our users is to
> make explains easier to read. The main complain here is that it requires some
> training to be able to read them, specially because in explain names of the
> inputs is index based ($0, $1, etc) but the rows itself are indirectly
> defined by the each input. A person with enough experience may understand
> that the rows generated by a join is formed by appending the input of the
> left hand side with the input of the right hand side, but in complex queries
> it takes time to get use to that and to picture these rows in your mind.
> These complains are also based by the fact that other databases have solved
> this issue long ago. For example, in Postgres, given a table `a` and
> `two_cols` such as:
> {{postgres=# \d a}}
> {{Table "public.a"}}
> {{Column | Type | Collation | Nullable | Default }}
> {{+-+---+--+-}}
> {{a | integer | | | }}
> {{postgres=# \d two_cols}}
> {{ Table "public.two_cols"}}
> {{Column | Type | Collation | Nullable | Default }}
> {{+-+---+--+-}}
> {{a | integer | | | }}
> {{b | integer | | |}}
> A join explain shows:
> {{postgres=# explain select * from a join two_cols on a.a = two_cols.a;}}
> {{ QUERY PLAN }}
> {{}}
> {{Merge Join (cost=338.29..781.81 rows=28815 width=12)}}
> {{ Merge Cond: ({*}two_cols.a = a.a{*})}}
> {{ -> Sort (cost=158.51..164.16 rows=2260 width=8)}}
> {{Sort Key: *two_cols.a*}}
> {{-> Seq Scan on two_cols (cost=0.00..32.60 rows=2260 width=8)}}
> {{ -> Sort (cost=179.78..186.16 rows=2550 width=4)}}
> {{Sort Key: *a.a*}}
> {{-> Seq Scan on a (cost=0.00..35.50 rows=2550 width=4)}}
> {{(8 rows)}}
>
> In Postgres the explain even conserves the name of the aliases if used.
> To be clear, I don't know if it is possible to do this right now. I didn't
> find a way myself and after asking in the dev mail least I was invited to
> write a Jira issue to discuss about the specific requirements.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-6390) ArrowAdapterTest fails on Windows
[
https://issues.apache.org/jira/browse/CALCITE-6390?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17841931#comment-17841931
]
Stamatis Zampetakis commented on CALCITE-6390:
--
Skipping the entire project or build when running on Windows may have undesired
side-effects. For instance, if the RM is running on Windows we may end up with
a release that does not contain the Arrow adapter and it may even pass
unnoticed. If the tests are the only problem then skipping only those makes
sense.
> ArrowAdapterTest fails on Windows
> -
>
> Key: CALCITE-6390
> URL: https://issues.apache.org/jira/browse/CALCITE-6390
> Project: Calcite
> Issue Type: Sub-task
>Reporter: Sergey Nuyanzin
>Assignee: Stamatis Zampetakis
>Priority: Major
> Labels: pull-request-available
>
> -That's seems somehow highlights the difference between Windows Server and
> non Server-
> -we have tests against Windows Server on gha (windows-latest) and they are
> green-
> -At the same time local tests on Windows 11 show that {{ArrowAdapterTest}}
> fails like-
> Based on deeper analysis Arrow module was never tested on Windows since for
> Windows conf on gha it is {{--exclude-task :arrow:build}} which makes it
> skipping the tests for this module
> https://github.com/apache/calcite/blob/aa8d81bf1ff39e3632aeb856fc4cc247ce9727e5/.github/workflows/main.yml#L110C60-L110C88
> Any attempt to test it leads to
> {noformat}
> FAILURE 0.0sec, org.apache.calcite.adapter.arrow.ArrowAdapterTest >
> executionError
> java.io.IOException: Failed to delete temp directory
> D:\MyConfiguration\cancai.cai\AppData\Local\Temp\junit5105379620525559011.
> The following paths could not be deleted (see suppressed exceptions for
> details): , arrow
> at
> org.junit.jupiter.engine.extension.TempDirectory$CloseablePath.createIOExceptionWithAttachedFailures(TempDirectory.java:350)
> at
> org.junit.jupiter.engine.extension.TempDirectory$CloseablePath.close(TempDirectory.java:251)
> at
> org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
> at
> org.junit.jupiter.engine.execution.ExtensionValuesStore.lambda$closeAllStoredCloseableValues$3(ExtensionValuesStore.java:68)
> at
> java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:184)
> at
> java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
> at java.util.ArrayList.forEach(ArrayList.java:1259)
> at java.util.stream.SortedOps$RefSortingSink.end(SortedOps.java:390)
> at java.util.stream.Sink$ChainedReference.end(Sink.java:258)
> at
> java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:483)
> at
> java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:472)
> at
> java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:151)
> at
> java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:174)
> at
> java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> at
> java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:418)
> at
> org.junit.jupiter.engine.execution.ExtensionValuesStore.closeAllStoredCloseableValues(ExtensionValuesStore.java:68)
> at
> org.junit.jupiter.engine.descriptor.AbstractExtensionContext.close(AbstractExtensionContext.java:80)
> at
> org.junit.jupiter.engine.execution.JupiterEngineExecutionContext.close(JupiterEngineExecutionContext.java:53)
> at
> org.junit.jupiter.engine.descriptor.JupiterTestDescriptor.cleanUp(JupiterTestDescriptor.java:222)
> at
> org.junit.jupiter.engine.descriptor.JupiterTestDescriptor.cleanUp(JupiterTestDescriptor.java:57)
> at
> org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$cleanUp$10(NodeTestTask.java:167)
> at
> org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
> at
> org.junit.platform.engine.support.hierarchical.NodeTestTask.cleanUp(NodeTestTask.java:167)
> at
> org.junit.platform.engine.support.hierarchical.NodeTestTask.execute(NodeTestTask.java:98)
> at
> org.junit.platform.engine.support.hierarchical.ForkJoinPoolHierarchicalTestExecutorService$ExclusiveTask.compute(ForkJoinPoolHierarchicalTestExecutorService.java:185)
> at
> org.junit.platform.engine.support.hierarchical.ForkJoinPoolHierarchicalTestExecutorService.invokeAll(ForkJoinPoolHierarchicalTestExecutorService.java:129)
> at
> org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$6(NodeTestTask.java:155)
> at
>
[jira] [Commented] (CALCITE-6390) ArrowAdapterTest fails on Windows
[
https://issues.apache.org/jira/browse/CALCITE-6390?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17841929#comment-17841929
]
Stamatis Zampetakis commented on CALCITE-6390:
--
Actually Ruben's idea of just disabling the Arrow tests on Windows is less
brutal so I updated the PR accordingly to see if everything else works as
expected.
> ArrowAdapterTest fails on Windows
> -
>
> Key: CALCITE-6390
> URL: https://issues.apache.org/jira/browse/CALCITE-6390
> Project: Calcite
> Issue Type: Sub-task
>Reporter: Sergey Nuyanzin
>Assignee: Stamatis Zampetakis
>Priority: Major
> Labels: pull-request-available
>
> -That's seems somehow highlights the difference between Windows Server and
> non Server-
> -we have tests against Windows Server on gha (windows-latest) and they are
> green-
> -At the same time local tests on Windows 11 show that {{ArrowAdapterTest}}
> fails like-
> Based on deeper analysis Arrow module was never tested on Windows since for
> Windows conf on gha it is {{--exclude-task :arrow:build}} which makes it
> skipping the tests for this module
> https://github.com/apache/calcite/blob/aa8d81bf1ff39e3632aeb856fc4cc247ce9727e5/.github/workflows/main.yml#L110C60-L110C88
> Any attempt to test it leads to
> {noformat}
> FAILURE 0.0sec, org.apache.calcite.adapter.arrow.ArrowAdapterTest >
> executionError
> java.io.IOException: Failed to delete temp directory
> D:\MyConfiguration\cancai.cai\AppData\Local\Temp\junit5105379620525559011.
> The following paths could not be deleted (see suppressed exceptions for
> details): , arrow
> at
> org.junit.jupiter.engine.extension.TempDirectory$CloseablePath.createIOExceptionWithAttachedFailures(TempDirectory.java:350)
> at
> org.junit.jupiter.engine.extension.TempDirectory$CloseablePath.close(TempDirectory.java:251)
> at
> org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
> at
> org.junit.jupiter.engine.execution.ExtensionValuesStore.lambda$closeAllStoredCloseableValues$3(ExtensionValuesStore.java:68)
> at
> java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:184)
> at
> java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
> at java.util.ArrayList.forEach(ArrayList.java:1259)
> at java.util.stream.SortedOps$RefSortingSink.end(SortedOps.java:390)
> at java.util.stream.Sink$ChainedReference.end(Sink.java:258)
> at
> java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:483)
> at
> java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:472)
> at
> java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:151)
> at
> java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:174)
> at
> java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> at
> java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:418)
> at
> org.junit.jupiter.engine.execution.ExtensionValuesStore.closeAllStoredCloseableValues(ExtensionValuesStore.java:68)
> at
> org.junit.jupiter.engine.descriptor.AbstractExtensionContext.close(AbstractExtensionContext.java:80)
> at
> org.junit.jupiter.engine.execution.JupiterEngineExecutionContext.close(JupiterEngineExecutionContext.java:53)
> at
> org.junit.jupiter.engine.descriptor.JupiterTestDescriptor.cleanUp(JupiterTestDescriptor.java:222)
> at
> org.junit.jupiter.engine.descriptor.JupiterTestDescriptor.cleanUp(JupiterTestDescriptor.java:57)
> at
> org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$cleanUp$10(NodeTestTask.java:167)
> at
> org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
> at
> org.junit.platform.engine.support.hierarchical.NodeTestTask.cleanUp(NodeTestTask.java:167)
> at
> org.junit.platform.engine.support.hierarchical.NodeTestTask.execute(NodeTestTask.java:98)
> at
> org.junit.platform.engine.support.hierarchical.ForkJoinPoolHierarchicalTestExecutorService$ExclusiveTask.compute(ForkJoinPoolHierarchicalTestExecutorService.java:185)
> at
> org.junit.platform.engine.support.hierarchical.ForkJoinPoolHierarchicalTestExecutorService.invokeAll(ForkJoinPoolHierarchicalTestExecutorService.java:129)
> at
> org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$6(NodeTestTask.java:155)
> at
> org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
> at
>
[jira] [Commented] (CALCITE-6390) ArrowAdapterTest fails on Windows
[
https://issues.apache.org/jira/browse/CALCITE-6390?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17841922#comment-17841922
]
Stamatis Zampetakis commented on CALCITE-6390:
--
Given that the Arrow build was never tested on Windows I would be inclined to
skip the project automatically (and transparently for the end users) when
running on Windows instead of adding OS specific instructions in the
documentation. I raised a PR with this approach. WDYT?
> ArrowAdapterTest fails on Windows
> -
>
> Key: CALCITE-6390
> URL: https://issues.apache.org/jira/browse/CALCITE-6390
> Project: Calcite
> Issue Type: Sub-task
>Reporter: Sergey Nuyanzin
>Assignee: Stamatis Zampetakis
>Priority: Major
> Labels: pull-request-available
>
> -That's seems somehow highlights the difference between Windows Server and
> non Server-
> -we have tests against Windows Server on gha (windows-latest) and they are
> green-
> -At the same time local tests on Windows 11 show that {{ArrowAdapterTest}}
> fails like-
> Based on deeper analysis Arrow module was never tested on Windows since for
> Windows conf on gha it is {{--exclude-task :arrow:build}} which makes it
> skipping the tests for this module
> https://github.com/apache/calcite/blob/aa8d81bf1ff39e3632aeb856fc4cc247ce9727e5/.github/workflows/main.yml#L110C60-L110C88
> Any attempt to test it leads to
> {noformat}
> FAILURE 0.0sec, org.apache.calcite.adapter.arrow.ArrowAdapterTest >
> executionError
> java.io.IOException: Failed to delete temp directory
> D:\MyConfiguration\cancai.cai\AppData\Local\Temp\junit5105379620525559011.
> The following paths could not be deleted (see suppressed exceptions for
> details): , arrow
> at
> org.junit.jupiter.engine.extension.TempDirectory$CloseablePath.createIOExceptionWithAttachedFailures(TempDirectory.java:350)
> at
> org.junit.jupiter.engine.extension.TempDirectory$CloseablePath.close(TempDirectory.java:251)
> at
> org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
> at
> org.junit.jupiter.engine.execution.ExtensionValuesStore.lambda$closeAllStoredCloseableValues$3(ExtensionValuesStore.java:68)
> at
> java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:184)
> at
> java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
> at java.util.ArrayList.forEach(ArrayList.java:1259)
> at java.util.stream.SortedOps$RefSortingSink.end(SortedOps.java:390)
> at java.util.stream.Sink$ChainedReference.end(Sink.java:258)
> at
> java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:483)
> at
> java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:472)
> at
> java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:151)
> at
> java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:174)
> at
> java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> at
> java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:418)
> at
> org.junit.jupiter.engine.execution.ExtensionValuesStore.closeAllStoredCloseableValues(ExtensionValuesStore.java:68)
> at
> org.junit.jupiter.engine.descriptor.AbstractExtensionContext.close(AbstractExtensionContext.java:80)
> at
> org.junit.jupiter.engine.execution.JupiterEngineExecutionContext.close(JupiterEngineExecutionContext.java:53)
> at
> org.junit.jupiter.engine.descriptor.JupiterTestDescriptor.cleanUp(JupiterTestDescriptor.java:222)
> at
> org.junit.jupiter.engine.descriptor.JupiterTestDescriptor.cleanUp(JupiterTestDescriptor.java:57)
> at
> org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$cleanUp$10(NodeTestTask.java:167)
> at
> org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
> at
> org.junit.platform.engine.support.hierarchical.NodeTestTask.cleanUp(NodeTestTask.java:167)
> at
> org.junit.platform.engine.support.hierarchical.NodeTestTask.execute(NodeTestTask.java:98)
> at
> org.junit.platform.engine.support.hierarchical.ForkJoinPoolHierarchicalTestExecutorService$ExclusiveTask.compute(ForkJoinPoolHierarchicalTestExecutorService.java:185)
> at
> org.junit.platform.engine.support.hierarchical.ForkJoinPoolHierarchicalTestExecutorService.invokeAll(ForkJoinPoolHierarchicalTestExecutorService.java:129)
> at
> org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$6(NodeTestTask.java:155)
> at
> org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
>
[jira] [Assigned] (CALCITE-6390) ArrowAdapterTest fails on Windows
[
https://issues.apache.org/jira/browse/CALCITE-6390?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stamatis Zampetakis reassigned CALCITE-6390:
Assignee: Stamatis Zampetakis
> ArrowAdapterTest fails on Windows
> -
>
> Key: CALCITE-6390
> URL: https://issues.apache.org/jira/browse/CALCITE-6390
> Project: Calcite
> Issue Type: Sub-task
>Reporter: Sergey Nuyanzin
>Assignee: Stamatis Zampetakis
>Priority: Major
>
> -That's seems somehow highlights the difference between Windows Server and
> non Server-
> -we have tests against Windows Server on gha (windows-latest) and they are
> green-
> -At the same time local tests on Windows 11 show that {{ArrowAdapterTest}}
> fails like-
> Based on deeper analysis Arrow module was never tested on Windows since for
> Windows conf on gha it is {{--exclude-task :arrow:build}} which makes it
> skipping the tests for this module
> https://github.com/apache/calcite/blob/aa8d81bf1ff39e3632aeb856fc4cc247ce9727e5/.github/workflows/main.yml#L110C60-L110C88
> Any attempt to test it leads to
> {noformat}
> FAILURE 0.0sec, org.apache.calcite.adapter.arrow.ArrowAdapterTest >
> executionError
> java.io.IOException: Failed to delete temp directory
> D:\MyConfiguration\cancai.cai\AppData\Local\Temp\junit5105379620525559011.
> The following paths could not be deleted (see suppressed exceptions for
> details): , arrow
> at
> org.junit.jupiter.engine.extension.TempDirectory$CloseablePath.createIOExceptionWithAttachedFailures(TempDirectory.java:350)
> at
> org.junit.jupiter.engine.extension.TempDirectory$CloseablePath.close(TempDirectory.java:251)
> at
> org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
> at
> org.junit.jupiter.engine.execution.ExtensionValuesStore.lambda$closeAllStoredCloseableValues$3(ExtensionValuesStore.java:68)
> at
> java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:184)
> at
> java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
> at java.util.ArrayList.forEach(ArrayList.java:1259)
> at java.util.stream.SortedOps$RefSortingSink.end(SortedOps.java:390)
> at java.util.stream.Sink$ChainedReference.end(Sink.java:258)
> at
> java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:483)
> at
> java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:472)
> at
> java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:151)
> at
> java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:174)
> at
> java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> at
> java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:418)
> at
> org.junit.jupiter.engine.execution.ExtensionValuesStore.closeAllStoredCloseableValues(ExtensionValuesStore.java:68)
> at
> org.junit.jupiter.engine.descriptor.AbstractExtensionContext.close(AbstractExtensionContext.java:80)
> at
> org.junit.jupiter.engine.execution.JupiterEngineExecutionContext.close(JupiterEngineExecutionContext.java:53)
> at
> org.junit.jupiter.engine.descriptor.JupiterTestDescriptor.cleanUp(JupiterTestDescriptor.java:222)
> at
> org.junit.jupiter.engine.descriptor.JupiterTestDescriptor.cleanUp(JupiterTestDescriptor.java:57)
> at
> org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$cleanUp$10(NodeTestTask.java:167)
> at
> org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
> at
> org.junit.platform.engine.support.hierarchical.NodeTestTask.cleanUp(NodeTestTask.java:167)
> at
> org.junit.platform.engine.support.hierarchical.NodeTestTask.execute(NodeTestTask.java:98)
> at
> org.junit.platform.engine.support.hierarchical.ForkJoinPoolHierarchicalTestExecutorService$ExclusiveTask.compute(ForkJoinPoolHierarchicalTestExecutorService.java:185)
> at
> org.junit.platform.engine.support.hierarchical.ForkJoinPoolHierarchicalTestExecutorService.invokeAll(ForkJoinPoolHierarchicalTestExecutorService.java:129)
> at
> org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$6(NodeTestTask.java:155)
> at
> org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
> at
> org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$8(NodeTestTask.java:141)
> at
> org.junit.platform.engine.support.hierarchical.Node.around(Node.java:137)
> at
>
[jira] [Resolved] (CALCITE-6384) Missing ASF header from buildcache.yml, gradle-wrapper-validation.yml
[ https://issues.apache.org/jira/browse/CALCITE-6384?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stamatis Zampetakis resolved CALCITE-6384. -- Fix Version/s: 1.37.0 Resolution: Fixed Fixed in [aa8d81bf1ff39e3632aeb856fc4cc247ce9727e5|https://github.com/apache/calcite/commit/aa8d81bf1ff39e3632aeb856fc4cc247ce9727e5]. Thanks for the reviews [~asolimando] and [~snuyanzin]! > Missing ASF header from buildcache.yml, gradle-wrapper-validation.yml > - > > Key: CALCITE-6384 > URL: https://issues.apache.org/jira/browse/CALCITE-6384 > Project: Calcite > Issue Type: Task >Affects Versions: 1.36.0 >Reporter: Stamatis Zampetakis >Assignee: Stamatis Zampetakis >Priority: Major > Labels: pull-request-available > Fix For: 1.37.0 > > > The header is required as per [ASF > policy|https://www.apache.org/legal/src-headers.html]. > * > [https://github.com/apache/calcite/blob/153494207c24318d4c1d2c908df4a15c4aa4/.github/workflows/buildcache.yml] > * > [https://github.com/apache/calcite/blob/153494207c24318d4c1d2c908df4a15c4aa4/.github/workflows/gradle-wrapper-validation.yml] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CALCITE-6385) LintTest fails when run in source distribution
[
https://issues.apache.org/jira/browse/CALCITE-6385?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stamatis Zampetakis resolved CALCITE-6385.
--
Fix Version/s: 1.37.0
Resolution: Fixed
Fixed in
[f78dd940d745a5242c35546308ebf74a97f26610|https://github.com/apache/calcite/commit/f78dd940d745a5242c35546308ebf74a97f26610].
Thanks for the reviews [~rubenql] and [~Sergey Nuyanzin]!
> LintTest fails when run in source distribution
> --
>
> Key: CALCITE-6385
> URL: https://issues.apache.org/jira/browse/CALCITE-6385
> Project: Calcite
> Issue Type: Bug
>Affects Versions: 1.36.0
>Reporter: Stamatis Zampetakis
>Assignee: Stamatis Zampetakis
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.37.0
>
>
> Steps to reproduce:
> # Download
> [https://dist.apache.org/repos/dist/dev/calcite/apache-calcite-1.37.0-rc0/apache-calcite-1.37.0-src.tar.gz]
> # tar -xvf apache-calcite-1.37.0-src.tar.gz
> # cd apache-calcite-1.37.0-src
> # /opt/gradle/gradle-7.6.1/bin/gradle cleanTest :core:test --tests LintTest
> {noformat}
> FAILURE 0.1sec, org.apache.calcite.test.LintTest >
> testContributorsFileIsSorted()
> java.lang.RuntimeException: command [git, ls-files, *.bat, *.cmd, *.csv,
> *.fmpp, *.ftl, *.iq, *.java, *.json, *.jj, *.kt, *.kts, .mailmap, *.md,
> *.properties, *.sh, *.sql, *.txt, *.xml, *.yaml, *.yml]: failed with exception
> at org.apache.calcite.util.TestUnsafe.getGitFiles(TestUnsafe.java:185)
> at
> org.apache.calcite.util.TestUnsafe.getTextFiles(TestUnsafe.java:158)
> at
> org.apache.calcite.test.LintTest.testContributorsFileIsSorted(LintTest.java:400)
> Caused by: java.lang.RuntimeException: command [git, ls-files, *.bat,
> *.cmd, *.csv, *.fmpp, *.ftl, *.iq, *.java, *.json, *.jj, *.kt, *.kts,
> .mailmap, *.md, *.properties, *.sh, *.sql, *.txt, *.xml, *.yaml, *.yml]:
> exited with status 128
> at
> org.apache.calcite.util.TestUnsafe.getGitFiles(TestUnsafe.java:180)
> ... 2 more
> FAILURE 0.0sec, org.apache.calcite.test.LintTest > testMailmapFile()
> java.lang.RuntimeException: command [git, ls-files, *.bat, *.cmd, *.csv,
> *.fmpp, *.ftl, *.iq, *.java, *.json, *.jj, *.kt, *.kts, .mailmap, *.md,
> *.properties, *.sh, *.sql, *.txt, *.xml, *.yaml, *.yml]: failed with exception
> at org.apache.calcite.util.TestUnsafe.getGitFiles(TestUnsafe.java:185)
> at
> org.apache.calcite.util.TestUnsafe.getTextFiles(TestUnsafe.java:158)
> at org.apache.calcite.test.LintTest.testMailmapFile(LintTest.java:419)
> Caused by: java.lang.RuntimeException: command [git, ls-files, *.bat,
> *.cmd, *.csv, *.fmpp, *.ftl, *.iq, *.java, *.json, *.jj, *.kt, *.kts,
> .mailmap, *.md, *.properties, *.sh, *.sql, *.txt, *.xml, *.yaml, *.yml]:
> exited with status 128
> at
> org.apache.calcite.util.TestUnsafe.getGitFiles(TestUnsafe.java:180)
> ... 2 more
> FAILURE 0.1sec,6 completed, 2 failed, 2 skipped,
> org.apache.calcite.test.LintTest
> {noformat}
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-6385) LintTest fails when run in source distribution
[
https://issues.apache.org/jira/browse/CALCITE-6385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17840747#comment-17840747
]
Stamatis Zampetakis commented on CALCITE-6385:
--
I didn't realize that I assigned this to me :D I will upload a fix in a few
minutes. The tests do not really need git so I guess we don't have to skip them
anywhere.
> LintTest fails when run in source distribution
> --
>
> Key: CALCITE-6385
> URL: https://issues.apache.org/jira/browse/CALCITE-6385
> Project: Calcite
> Issue Type: Bug
>Affects Versions: 1.36.0
>Reporter: Stamatis Zampetakis
>Assignee: Stamatis Zampetakis
>Priority: Major
>
> Steps to reproduce:
> # Download
> [https://dist.apache.org/repos/dist/dev/calcite/apache-calcite-1.37.0-rc0/apache-calcite-1.37.0-src.tar.gz]
> # tar -xvf apache-calcite-1.37.0-src.tar.gz
> # cd apache-calcite-1.37.0-src
> # /opt/gradle/gradle-7.6.1/bin/gradle cleanTest :core:test --tests LintTest
> {noformat}
> FAILURE 0.1sec, org.apache.calcite.test.LintTest >
> testContributorsFileIsSorted()
> java.lang.RuntimeException: command [git, ls-files, *.bat, *.cmd, *.csv,
> *.fmpp, *.ftl, *.iq, *.java, *.json, *.jj, *.kt, *.kts, .mailmap, *.md,
> *.properties, *.sh, *.sql, *.txt, *.xml, *.yaml, *.yml]: failed with exception
> at org.apache.calcite.util.TestUnsafe.getGitFiles(TestUnsafe.java:185)
> at
> org.apache.calcite.util.TestUnsafe.getTextFiles(TestUnsafe.java:158)
> at
> org.apache.calcite.test.LintTest.testContributorsFileIsSorted(LintTest.java:400)
> Caused by: java.lang.RuntimeException: command [git, ls-files, *.bat,
> *.cmd, *.csv, *.fmpp, *.ftl, *.iq, *.java, *.json, *.jj, *.kt, *.kts,
> .mailmap, *.md, *.properties, *.sh, *.sql, *.txt, *.xml, *.yaml, *.yml]:
> exited with status 128
> at
> org.apache.calcite.util.TestUnsafe.getGitFiles(TestUnsafe.java:180)
> ... 2 more
> FAILURE 0.0sec, org.apache.calcite.test.LintTest > testMailmapFile()
> java.lang.RuntimeException: command [git, ls-files, *.bat, *.cmd, *.csv,
> *.fmpp, *.ftl, *.iq, *.java, *.json, *.jj, *.kt, *.kts, .mailmap, *.md,
> *.properties, *.sh, *.sql, *.txt, *.xml, *.yaml, *.yml]: failed with exception
> at org.apache.calcite.util.TestUnsafe.getGitFiles(TestUnsafe.java:185)
> at
> org.apache.calcite.util.TestUnsafe.getTextFiles(TestUnsafe.java:158)
> at org.apache.calcite.test.LintTest.testMailmapFile(LintTest.java:419)
> Caused by: java.lang.RuntimeException: command [git, ls-files, *.bat,
> *.cmd, *.csv, *.fmpp, *.ftl, *.iq, *.java, *.json, *.jj, *.kt, *.kts,
> .mailmap, *.md, *.properties, *.sh, *.sql, *.txt, *.xml, *.yaml, *.yml]:
> exited with status 128
> at
> org.apache.calcite.util.TestUnsafe.getGitFiles(TestUnsafe.java:180)
> ... 2 more
> FAILURE 0.1sec,6 completed, 2 failed, 2 skipped,
> org.apache.calcite.test.LintTest
> {noformat}
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CALCITE-6385) LintTest fails when run in source distribution
Stamatis Zampetakis created CALCITE-6385:
Summary: LintTest fails when run in source distribution
Key: CALCITE-6385
URL: https://issues.apache.org/jira/browse/CALCITE-6385
Project: Calcite
Issue Type: Bug
Affects Versions: 1.36.0
Reporter: Stamatis Zampetakis
Assignee: Stamatis Zampetakis
Steps to reproduce:
# Download
[https://dist.apache.org/repos/dist/dev/calcite/apache-calcite-1.37.0-rc0/apache-calcite-1.37.0-src.tar.gz]
# tar -xvf apache-calcite-1.37.0-src.tar.gz
# cd apache-calcite-1.37.0-src
# /opt/gradle/gradle-7.6.1/bin/gradle cleanTest :core:test --tests LintTest
{noformat}
FAILURE 0.1sec, org.apache.calcite.test.LintTest >
testContributorsFileIsSorted()
java.lang.RuntimeException: command [git, ls-files, *.bat, *.cmd, *.csv,
*.fmpp, *.ftl, *.iq, *.java, *.json, *.jj, *.kt, *.kts, .mailmap, *.md,
*.properties, *.sh, *.sql, *.txt, *.xml, *.yaml, *.yml]: failed with exception
at org.apache.calcite.util.TestUnsafe.getGitFiles(TestUnsafe.java:185)
at org.apache.calcite.util.TestUnsafe.getTextFiles(TestUnsafe.java:158)
at
org.apache.calcite.test.LintTest.testContributorsFileIsSorted(LintTest.java:400)
Caused by: java.lang.RuntimeException: command [git, ls-files, *.bat,
*.cmd, *.csv, *.fmpp, *.ftl, *.iq, *.java, *.json, *.jj, *.kt, *.kts, .mailmap,
*.md, *.properties, *.sh, *.sql, *.txt, *.xml, *.yaml, *.yml]: exited with
status 128
at
org.apache.calcite.util.TestUnsafe.getGitFiles(TestUnsafe.java:180)
... 2 more
FAILURE 0.0sec, org.apache.calcite.test.LintTest > testMailmapFile()
java.lang.RuntimeException: command [git, ls-files, *.bat, *.cmd, *.csv,
*.fmpp, *.ftl, *.iq, *.java, *.json, *.jj, *.kt, *.kts, .mailmap, *.md,
*.properties, *.sh, *.sql, *.txt, *.xml, *.yaml, *.yml]: failed with exception
at org.apache.calcite.util.TestUnsafe.getGitFiles(TestUnsafe.java:185)
at org.apache.calcite.util.TestUnsafe.getTextFiles(TestUnsafe.java:158)
at org.apache.calcite.test.LintTest.testMailmapFile(LintTest.java:419)
Caused by: java.lang.RuntimeException: command [git, ls-files, *.bat,
*.cmd, *.csv, *.fmpp, *.ftl, *.iq, *.java, *.json, *.jj, *.kt, *.kts, .mailmap,
*.md, *.properties, *.sh, *.sql, *.txt, *.xml, *.yaml, *.yml]: exited with
status 128
at
org.apache.calcite.util.TestUnsafe.getGitFiles(TestUnsafe.java:180)
... 2 more
FAILURE 0.1sec,6 completed, 2 failed, 2 skipped,
org.apache.calcite.test.LintTest
{noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CALCITE-6384) Missing ASF header from buildcache.yml, gradle-wrapper-validation.yml
Stamatis Zampetakis created CALCITE-6384: Summary: Missing ASF header from buildcache.yml, gradle-wrapper-validation.yml Key: CALCITE-6384 URL: https://issues.apache.org/jira/browse/CALCITE-6384 Project: Calcite Issue Type: Task Affects Versions: 1.36.0 Reporter: Stamatis Zampetakis Assignee: Stamatis Zampetakis The header is required as per [ASF policy|https://www.apache.org/legal/src-headers.html]. * [https://github.com/apache/calcite/blob/153494207c24318d4c1d2c908df4a15c4aa4/.github/workflows/buildcache.yml] * [https://github.com/apache/calcite/blob/153494207c24318d4c1d2c908df4a15c4aa4/.github/workflows/gradle-wrapper-validation.yml] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CALCITE-6322) Casts to DECIMAL types are ignored
[
https://issues.apache.org/jira/browse/CALCITE-6322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17839000#comment-17839000
]
Stamatis Zampetakis commented on CALCITE-6322:
--
Hey [~mbudiu], this work seems to have some overlap with CALCITE-5860 and same
goes for the respective PRs (PR#3733 and PR#3326) which touch very similar
pieces of code & tests. Can they be merged independently? Does one subsume the
other? If you can highlight similarities and differences that would help in
reviewing the PR here.
Some time ago while reviewing CALCITE-5860, I left some comments that may also
apply to this jira as well. For instance, various tests in SqlOperatorTest that
involve casts and decimals are skipped due to the [DECIMAL
fla|https://github.com/apache/calcite/blob/0551b8903391c1706422a2c1b8b648a6941f39a2/testkit/src/main/java/org/apache/calcite/test/SqlOperatorTest.java#L354];
looking at the description of this JIRA ticket I would expect that this tests
would be enabled after fixing the casts to decimal but it doesn't seem to be
the case.
> Casts to DECIMAL types are ignored
> --
>
> Key: CALCITE-6322
> URL: https://issues.apache.org/jira/browse/CALCITE-6322
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.36.0
>Reporter: Mihai Budiu
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.37.0
>
>
> The following SqlOperatorTest fails:
> {code:java}
> f.checkScalar("CAST(1.123 AS DECIMAL(4, 0))", "1.0", "DECIMAL(4, 0) NOT
> NULL");
> {code}
> The result computed by Calcite is 1.123, ignoring the scale of the DECIMAL
> result.
> Spark, Postgres, MySQL all return 1.0.
> I have marked this as a major bug.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-6331) The third-party source code file doesn't have a License file.
[ https://issues.apache.org/jira/browse/CALCITE-6331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17827126#comment-17827126 ] Stamatis Zampetakis commented on CALCITE-6331: -- I don't remember the motivation behind this packaging structure but I remember various discussions on the topic. If you look into the git/JIRA history or the archives of dev@calcite you may find something relevant. > The third-party source code file doesn't have a License file. > - > > Key: CALCITE-6331 > URL: https://issues.apache.org/jira/browse/CALCITE-6331 > Project: Calcite > Issue Type: Improvement >Reporter: Calvin Kirs >Priority: Major > Labels: pull-request-available > > [https://github.com/apache/calcite/blob/main/LICENSE#L184-L196] > We reference these third-party source code files but don't provide the > corresponding LICENSE files. > FYI : [https://www.apache.org/legal/release-policy.html#license-file] > > Here is the MIT license: > > Permission is hereby granted, free of charge, to any person obtaining a copy > of this software and associated documentation files (the "Software"), to deal > in the Software without restriction, including without limitation the rights > to use, copy, modify, merge, publish, distribute, sublicense, and/or sell > copies of the Software, and to permit persons to whom the Software is > furnished to do so, subject to the following conditions: The above copyright > notice and this permission notice shall be included in all copies or > substantial portions of the Software. > > > > > > > > > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CALCITE-6330) Print the average row size when when explaining an operator
[
https://issues.apache.org/jira/browse/CALCITE-6330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17827073#comment-17827073
]
Stamatis Zampetakis commented on CALCITE-6330:
--
Based on the SqlExplainLevel specification I am not sure if it was ever
intended to bring anything else except the cost. The average row size may be a
nice thing to have but others would possibly find other metadata useful as
well. Every new thing that we add increases the serialization cost so there is
a fine line with how many things we can put in there.
Usually people who need to add more metadata tend to extend or implement their
own RelWriter.
> Print the average row size when when explaining an operator
> ---
>
> Key: CALCITE-6330
> URL: https://issues.apache.org/jira/browse/CALCITE-6330
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: mengdou
>Assignee: mengdou
>Priority: Minor
>
> In this time, when we dump the plan of a RelNode Tree, there is no average
> row size exported in the output string, even if
> SqlExplainLevel.ALL_ATTRIBUTES is specified.
> Because the implementation in explain_() in class RelWriterImpl doesn't
> include the metric average_row_size:
>
> {code:java}
> switch (detailLevel) {
> case ALL_ATTRIBUTES:
> s.append(": rowcount = ")
> .append(mq.getRowCount(rel))
> .append(", cumulative cost = ")
> .append(mq.getCumulativeCost(rel));
> }
> switch (detailLevel) {
> case NON_COST_ATTRIBUTES:
> case ALL_ATTRIBUTES:
> if (!withIdPrefix) {
> // If we didn't print the rel id at the start of the line, print
> // it at the end.
> s.append(", id = ").append(rel.getId());
> }
> break;
> } {code}
>
> So I'd like to add this metric by calling md.getAverageRowSize(rel)
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-6331) The third-party source code file doesn't have a License file.
[ https://issues.apache.org/jira/browse/CALCITE-6331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17827068#comment-17827068 ] Stamatis Zampetakis commented on CALCITE-6331: -- The licenses can be found here: [https://github.com/apache/calcite/tree/f0dc2b0aea46b1fd3f37e0cc126edaf82ade2344/src/main/config/licenses] Are you sure that there is something missing? > The third-party source code file doesn't have a License file. > - > > Key: CALCITE-6331 > URL: https://issues.apache.org/jira/browse/CALCITE-6331 > Project: Calcite > Issue Type: Improvement >Reporter: Calvin Kirs >Priority: Major > Labels: pull-request-available > > [https://github.com/apache/calcite/blob/main/LICENSE#L184-L196] > We reference these third-party source code files but don't provide the > corresponding LICENSE files. > FYI : [https://www.apache.org/legal/release-policy.html#license-file] > > Here is the MIT license: > > Permission is hereby granted, free of charge, to any person obtaining a copy > of this software and associated documentation files (the "Software"), to deal > in the Software without restriction, including without limitation the rights > to use, copy, modify, merge, publish, distribute, sublicense, and/or sell > copies of the Software, and to permit persons to whom the Software is > furnished to do so, subject to the following conditions: The above copyright > notice and this permission notice shall be included in all copies or > substantial portions of the Software. > > > > > > > > > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[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=17824299#comment-17824299 ] Stamatis Zampetakis commented on CALCITE-2040: -- Many people contributed to this work so please give add an appropriate mention (use "Co-authored-by" in the commit message) before merging this to main. > 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: hongyu guo >Priority: Major > Labels: pull-request-available > Fix For: 1.37.0 > > Attachments: arrow_data.py > > Time Spent: 1.5h > 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.20.10#820010)
[jira] [Commented] (CALCITE-6271) The supportsFunction method of the SqlDialect class is never called in calcite
[
https://issues.apache.org/jira/browse/CALCITE-6271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17821573#comment-17821573
]
Stamatis Zampetakis commented on CALCITE-6271:
--
[~eveywu] is right. This is a method that may be used by other projects. For
instance, there are usages of this method in Hive (see
[JDBCRexCallValidator.java|https://github.com/apache/hive/blob/8dc9cba8889206a1241d9cf037f65876df658c62/ql/src/java/org/apache/hadoop/hive/ql/optimizer/calcite/rules/jdbc/JDBCRexCallValidator.java#L63]).
For the Hive use-case above it is true that it doesn't bring much value as it
is right now but there may be projects who define new dialects and use this
method in a more meaningful way.
For Calcite, I think it would make sense to call the supportsFunction method in
rules such as {{JdbcFilterRule}} etc.
> The supportsFunction method of the SqlDialect class is never called in calcite
> --
>
> Key: CALCITE-6271
> URL: https://issues.apache.org/jira/browse/CALCITE-6271
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Bertil Chapuis
>Priority: Minor
>
> Several sql dialects implement the supportsFunction method. However, after
> searching Calcite's code base, it looks like this function is never called.
> I'm not sure if it was used in the past. We could either search the history
> or clean this code.
> This seems to affects the ablity to push functions down such as in
> CALCITE-6239.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (CALCITE-6276) The javadocs JAR in 1.36 changed to Chinese headers
[ https://issues.apache.org/jira/browse/CALCITE-6276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stamatis Zampetakis resolved CALCITE-6276. -- Resolution: Duplicate > The javadocs JAR in 1.36 changed to Chinese headers > --- > > Key: CALCITE-6276 > URL: https://issues.apache.org/jira/browse/CALCITE-6276 > Project: Calcite > Issue Type: Bug > Components: core, druid-adapter, file-adapter, linq4j >Affects Versions: 1.36.0 >Reporter: Adam Kennedy >Priority: Major > Fix For: 1.37.0 > > Attachments: Screenshot 2024-02-20 at 12.49.08 PM.png > > > Between Calcite 1.35 and Calcite 1.36 the headers in the main javadocs appear > to have changed from English to Chinese. > 1.35 > [https://javadoc.io/doc/org.apache.calcite/calcite-core/1.35.0/index.html] > 1.36 (latest) > [https://javadoc.io/doc/org.apache.calcite/calcite-core/latest/index.html] > This is not just the website, it's also in the Maven javadocs package which > also causes the Chinese headings to show up in IDE tooltips and hosted docs. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CALCITE-6236) EnumerableBatchNestedLoopJoin uses wrong row count for cost calculation
[
https://issues.apache.org/jira/browse/CALCITE-6236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17813606#comment-17813606
]
Stamatis Zampetakis commented on CALCITE-6236:
--
For the record, pre-storing selectivity or other kind of metadata information
in the operator also feels like we are going to the wrong direction. Apologies
but I don't have enough cycles to figure out a good solution so from now on I
think I will just refrain from commenting more cause I am afraid I am just
adding negative karma to the discussion :D There are already 3 committers
involved in this thread so I will let them drive this issue forward.
> EnumerableBatchNestedLoopJoin uses wrong row count for cost calculation
> ---
>
> Key: CALCITE-6236
> URL: https://issues.apache.org/jira/browse/CALCITE-6236
> Project: Calcite
> Issue Type: Bug
>Reporter: Ulrich Kramer
>Priority: Major
> Labels: pull-request-available
>
> {{EnumerableBatchNestedLoopJoin}} always adds a {{Filter}} on the right
> relation.
> This filter reduces the number of rows by it's selectivity (in our case by a
> factor of 4).
> Therefore, {{RelMdUtil.getJoinRowCount}} returns a value 4 times lower
> compared to the one returned for a {{JdbcJoin}}.
> This leads to the fact that in most cases {{EnumerableBatchNestedLoopJoin}}
> is preferred over {{JdbcJoin}}.
> This is an example for the different costs
> {code}
> EnumerableProject rows=460.0 self_costs=460.0 cumulative_costs=1465.0
> EnumerableBatchNestedLoopJoin rows=460.0 self_costs=687.5
> cumulative_costs=1005.0
> JdbcToEnumerableConverter rows=100.0 self_costs=10.0
> cumulative_costs=190.0
> JdbcProject rows=100.0 self_costs=80.0 cumulative_costs=180.0
> JdbcTableScan rows=100.0 self_costs=100.0 cumulative_costs=100.0
> JdbcToEnumerableConverter rows=25.0 self_costs=2.5 cumulative_costs=127.5
> JdbcFilter rows=25.0 self_costs=25.0 cumulative_costs=125.0
> JdbcTableScan rows=100.0 self_costs=100.0 cumulative_costs=100.0
> {code}
> vs.
> {code}
> JdbcToEnumerableConverter rows=1585.0 self_costs=158.5 cumulative_costs=2023.5
> JdbcJoin rows=1585.0 self_costs=1585.0 cumulative_costs=1865.0
> JdbcProject rows=100.0 self_costs=80.0 cumulative_costs=180.0
> JdbcTableScan rows=100.0 self_costs=100.0 cumulative_costs=100.0
> JdbcTableScan rows=100.0 self_costs=100.0 cumulative_costs=100.0
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-6236) EnumerableBatchNestedLoopJoin uses wrong row count for cost calculation
[
https://issues.apache.org/jira/browse/CALCITE-6236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17813266#comment-17813266
]
Stamatis Zampetakis commented on CALCITE-6236:
--
Rules create semantically equivalent plans. Someone could argue that equivalent
means that they should have the same number of rows/costs. If we harcode the
row count for every "equivalent" relation then we no longer have cost-based
optimization since everything will have the same rows/costs. Also if we say
that every Enumerable operator that originates from a Logical one has the same
rowCount then why not saying the same for Jdbc operators and other conventions
as well.
> EnumerableBatchNestedLoopJoin uses wrong row count for cost calculation
> ---
>
> Key: CALCITE-6236
> URL: https://issues.apache.org/jira/browse/CALCITE-6236
> Project: Calcite
> Issue Type: Bug
>Reporter: Ulrich Kramer
>Priority: Major
> Labels: pull-request-available
>
> {{EnumerableBatchNestedLoopJoin}} always adds a {{Filter}} on the right
> relation.
> This filter reduces the number of rows by it's selectivity (in our case by a
> factor of 4).
> Therefore, {{RelMdUtil.getJoinRowCount}} returns a value 4 times lower
> compared to the one returned for a {{JdbcJoin}}.
> This leads to the fact that in most cases {{EnumerableBatchNestedLoopJoin}}
> is preferred over {{JdbcJoin}}.
> This is an example for the different costs
> {code}
> EnumerableProject rows=460.0 self_costs=460.0 cumulative_costs=1465.0
> EnumerableBatchNestedLoopJoin rows=460.0 self_costs=687.5
> cumulative_costs=1005.0
> JdbcToEnumerableConverter rows=100.0 self_costs=10.0
> cumulative_costs=190.0
> JdbcProject rows=100.0 self_costs=80.0 cumulative_costs=180.0
> JdbcTableScan rows=100.0 self_costs=100.0 cumulative_costs=100.0
> JdbcToEnumerableConverter rows=25.0 self_costs=2.5 cumulative_costs=127.5
> JdbcFilter rows=25.0 self_costs=25.0 cumulative_costs=125.0
> JdbcTableScan rows=100.0 self_costs=100.0 cumulative_costs=100.0
> {code}
> vs.
> {code}
> JdbcToEnumerableConverter rows=1585.0 self_costs=158.5 cumulative_costs=2023.5
> JdbcJoin rows=1585.0 self_costs=1585.0 cumulative_costs=1865.0
> JdbcProject rows=100.0 self_costs=80.0 cumulative_costs=180.0
> JdbcTableScan rows=100.0 self_costs=100.0 cumulative_costs=100.0
> JdbcTableScan rows=100.0 self_costs=100.0 cumulative_costs=100.0
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-6236) EnumerableBatchNestedLoopJoin uses wrong row count for cost calculation
[
https://issues.apache.org/jira/browse/CALCITE-6236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17813258#comment-17813258
]
Stamatis Zampetakis commented on CALCITE-6236:
--
If the Filter is the one who throws off the estimation then maybe the fix
should be in that logic. Alternatively the {{EnumerableBatchNestedLoopJoin}}
estimation could be multiplied by some constant factor (may be in correlation
with the batch size) to rectify the underestimate. Adding more fields to the
join or traversing the tree to perform the estimation are not customary
solutions.
> EnumerableBatchNestedLoopJoin uses wrong row count for cost calculation
> ---
>
> Key: CALCITE-6236
> URL: https://issues.apache.org/jira/browse/CALCITE-6236
> Project: Calcite
> Issue Type: Bug
>Reporter: Ulrich Kramer
>Priority: Major
> Labels: pull-request-available
>
> {{EnumerableBatchNestedLoopJoin}} always adds a {{Filter}} on the right
> relation.
> This filter reduces the number of rows by it's selectivity (in our case by a
> factor of 4).
> Therefore, {{RelMdUtil.getJoinRowCount}} returns a value 4 times lower
> compared to the one returned for a {{JdbcJoin}}.
> This leads to the fact that in most cases {{EnumerableBatchNestedLoopJoin}}
> is preferred over {{JdbcJoin}}.
> This is an example for the different costs
> {code}
> EnumerableProject rows=460.0 self_costs=460.0 cumulative_costs=1465.0
> EnumerableBatchNestedLoopJoin rows=460.0 self_costs=687.5
> cumulative_costs=1005.0
> JdbcToEnumerableConverter rows=100.0 self_costs=10.0
> cumulative_costs=190.0
> JdbcProject rows=100.0 self_costs=80.0 cumulative_costs=180.0
> JdbcTableScan rows=100.0 self_costs=100.0 cumulative_costs=100.0
> JdbcToEnumerableConverter rows=25.0 self_costs=2.5 cumulative_costs=127.5
> JdbcFilter rows=25.0 self_costs=25.0 cumulative_costs=125.0
> JdbcTableScan rows=100.0 self_costs=100.0 cumulative_costs=100.0
> {code}
> vs.
> {code}
> JdbcToEnumerableConverter rows=1585.0 self_costs=158.5 cumulative_costs=2023.5
> JdbcJoin rows=1585.0 self_costs=1585.0 cumulative_costs=1865.0
> JdbcProject rows=100.0 self_costs=80.0 cumulative_costs=180.0
> JdbcTableScan rows=100.0 self_costs=100.0 cumulative_costs=100.0
> JdbcTableScan rows=100.0 self_costs=100.0 cumulative_costs=100.0
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-6236) EnumerableBatchNestedLoopJoin uses wrong row count for cost calculation
[
https://issues.apache.org/jira/browse/CALCITE-6236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17813240#comment-17813240
]
Stamatis Zampetakis commented on CALCITE-6236:
--
It's pretty strange to derive the cost of an operator using another operator.
It is also pretty unusual to store an operator inside another operator just for
provenance purposes. I don't think we should endorse this pattern cause if we
allow this in the Calcite code base other projects will start mimicing what
they see.
The EnumerableBatchNestedLoopJoin is similar to a Correlate so maybe the row
count estimation should be done in a similar fashion. An idea would be to drop
{{RelMdRowCount.getRowCount}} for join thus fall back to
{{Join.estimateRowCount}} and in EnumerableBatchNestedLoopJoin override that
method with the appropriate estimation (copy/reuse of
{{Correlate.estimateRowCount}}).
> EnumerableBatchNestedLoopJoin uses wrong row count for cost calculation
> ---
>
> Key: CALCITE-6236
> URL: https://issues.apache.org/jira/browse/CALCITE-6236
> Project: Calcite
> Issue Type: Bug
>Reporter: Ulrich Kramer
>Priority: Major
> Labels: pull-request-available
>
> {{EnumerableBatchNestedLoopJoin}} always adds a {{Filter}} on the right
> relation.
> This filter reduces the number of rows by it's selectivity (in our case by a
> factor of 4).
> Therefore, {{RelMdUtil.getJoinRowCount}} returns a value 4 times lower
> compared to the one returned for a {{JdbcJoin}}.
> This leads to the fact that in most cases {{EnumerableBatchNestedLoopJoin}}
> is preferred over {{JdbcJoin}}.
> This is an example for the different costs
> {code}
> EnumerableProject rows=460.0 self_costs=460.0 cumulative_costs=1465.0
> EnumerableBatchNestedLoopJoin rows=460.0 self_costs=687.5
> cumulative_costs=1005.0
> JdbcToEnumerableConverter rows=100.0 self_costs=10.0
> cumulative_costs=190.0
> JdbcProject rows=100.0 self_costs=80.0 cumulative_costs=180.0
> JdbcTableScan rows=100.0 self_costs=100.0 cumulative_costs=100.0
> JdbcToEnumerableConverter rows=25.0 self_costs=2.5 cumulative_costs=127.5
> JdbcFilter rows=25.0 self_costs=25.0 cumulative_costs=125.0
> JdbcTableScan rows=100.0 self_costs=100.0 cumulative_costs=100.0
> {code}
> vs.
> {code}
> JdbcToEnumerableConverter rows=1585.0 self_costs=158.5 cumulative_costs=2023.5
> JdbcJoin rows=1585.0 self_costs=1585.0 cumulative_costs=1865.0
> JdbcProject rows=100.0 self_costs=80.0 cumulative_costs=180.0
> JdbcTableScan rows=100.0 self_costs=100.0 cumulative_costs=100.0
> JdbcTableScan rows=100.0 self_costs=100.0 cumulative_costs=100.0
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-6188) Multi-query optimization
[
https://issues.apache.org/jira/browse/CALCITE-6188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17809478#comment-17809478
]
Stamatis Zampetakis commented on CALCITE-6188:
--
Regarding the Multi DML use case, some systems (e.g., Hive, Snowflake) provide
a SQL syntax for inserting data into multiple tables, usually know as MULTI
TABLE INSERT statements.
The Hive syntax can be found
[here|https://cwiki.apache.org/confluence/display/hive/languagemanual+dml#LanguageManualDML-InsertingdataintoHiveTablesfromqueries]
and a basic example is outlined below.
{code:sql}
FROM (SELECT * FROM emp2 EXCEPT SELECT * FROM emp) empDelta
INSERT INTO TABLE tbl1 SELECT * WHERE empno > 100
INSERT INTO TABLE tbl2 SELECT * WHERE empno < 50;
{code}
The Snowflake syntax along with examples can be found
[here|https://docs.snowflake.com/en/sql-reference/sql/insert-multi-table].
> Multi-query optimization
>
>
> Key: CALCITE-6188
> URL: https://issues.apache.org/jira/browse/CALCITE-6188
> Project: Calcite
> Issue Type: Improvement
>Reporter: Julian Hyde
>Priority: Major
>
> Devise extensions to SQL for multi-query optimization (MQO). Queries with
> multiple input tables, multiple intermediate tables, and multiple output data
> sets (result sets and DML operations) can be defined in one SQL statement,
> optimized, and executed atomically.
> There are many flavors of multi-query optimization, depending on whether each
> occurrence of "multiple" in the previous paragraph is replaced with 0, 1 or
> "several". Our goal, here, is to allow them all to be expressed. We can then
> devise planning strategies that work for particular flavors.
> Examples of multi-queries:
> * {*}Multiple DML outputs{*}. An INSERT statement that writes into a table
> but also updates an index,
> * {*}Multiple DML outputs, complex intermediate tables{*}. A DAG that
> represents an ETL/ELT job;
> * {*}Multiple query outputs{*}. A query that produces several data sets (say
> a list of invoices for
> orders and a list of products that need to be restocked);
> * {*}DAG query{*}. A query that uses intermediate results more than once.
> See discussion in the [Multi-query optimization email
> thread|https://lists.apache.org/thread/mcdqwrtpx0os54t2nn9vtk17spkp5o5k].
> Here are some SQL examples.
> We add a new keyword {{MULTI}} that represents a statement whose output
> contains multiple data sets and DML operations, each with a unique name. For
> intermediate results, we use the existing {{WITH}} clause.
> h3. 1. Multi DML
> Read from one or more tables, write to one or more tables.
> An example is inserting into a table and also an index on that table
> (represented as a sorted table).
> {code:sql}
> WITH
> empDelta AS (
> SELECT * FROM emp2
> EXCEPT
> SELECT * FROM emp)
> MULTI
> insertEmp AS (
> INSERT INTO emp
> TABLE empDelta),
> insertEmpDeptno AS (
> MERGE empDeptno AS e
> USING TABLE empDelta AS d
> ON e.deptno = d.deptno
> WHEN NOT MATCHED THEN INSERT VALUES (deptno));
> {code}
> h3. 2. Query that creates temporary table and uses it more than once
> {code:sql}
> WITH
> temp AS (
> SELECT *
> FROM emp AS e
> JOIN dept USING (deptno)
> WHERE e.job = 'MANAGER'
> OR d.location = 'CHICAGO')
> SELECT deptno,
> (SELECT AVG(sal)
> FROM temp AS t
> WHERE t.deptno = e.deptno) AS deptAvgSal,
> (SELECT AVG(sal)
> FROM temp AS t
> WHERE t.job = e.job) AS jobAvgSal
> FROM e
> WHERE e.deptno IN (10, 20);
> {code}
> h3. 3. Query whose optimal plan might use a temporary table
> This query produces the same result as the previous query. There is a common
> relational expression, so the optimizer should consider a DAG plan with a
> reified intermediate result.
> {code:sql}
> SELECT deptno,
> (SELECT AVG(e2.sal)
> FROM emp AS e2
> JOIN dept AS d USING (deptno)
> WHERE (e2.job = 'MANAGER'
> OR d.location = 'CHICAGO')
> AND e2.deptno = e.deptno) AS deptAvgSal,
> (SELECT AVG(e3.sal)
> FROM emp AS e3
> JOIN dept AS d USING (deptno)
> WHERE (e3.job = 'MANAGER'
> OR d.location = 'CHICAGO')
> AND e3.job = e.job) AS jobAvgSal
> FROM e
> WHERE e.deptno IN (10, 20);
> {code}
> h3. 4. Query that produces several data sets
> {code:sql}
> WITH
> newOrders AS (
> SELECT *
> FROM orders
> WHERE orderDate > DATE '2023-01-25')
> MULTI
> invoices AS (
> SELECT customerName, SUM(amount)
> FROM newOrders
> GROUP BY customerName),
> restock AS (
> SELECT productId
> FROM inventory
> WHERE productId IN (
> SELECT productId FROM newOrders)
> AND itemsOnHand < 10);
> {code}
> h3. 5. Query with a complex DAG, multiple output data sets and one DML
> {code:sql}
> WITH
> t0 AS (
> SELECT * FROM t WHERE x > 5),
>
[jira] [Resolved] (CALCITE-6099) Missing LICENSE entry for _pygments.scss
[ https://issues.apache.org/jira/browse/CALCITE-6099?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stamatis Zampetakis resolved CALCITE-6099. -- Fix Version/s: 1.37.0 Assignee: Stamatis Zampetakis Resolution: Fixed Superceded by CALCITE-6098. > Missing LICENSE entry for _pygments.scss > > > Key: CALCITE-6099 > URL: https://issues.apache.org/jira/browse/CALCITE-6099 > Project: Calcite > Issue Type: Bug >Affects Versions: avatica-1.24.0, 1.36.0 >Reporter: Stamatis Zampetakis >Assignee: Stamatis Zampetakis >Priority: Major > Fix For: 1.37.0 > > > The > [_pygment.scss|https://github.com/apache/calcite/blob/4c9011c388f826c36463ae7da875ddb525104376/site/_sass/_pygments.scss] > file is present both in git and source distribution but there is no info > about its LICENSE. > I don't know the exact provenance of the file but I found a lot of > similarities with: > [desert.css|https://github.com/StylishThemes/Syntax-Themes/blob/bfeb1da4fbbb895b9c247e0f289b0e945243e94d/pygments/css-other/desert.css]. > If that's the true origin of the file then we should examine the respective > [LICENSE|https://github.com/StylishThemes/Syntax-Themes/blob/bfeb1da4fbbb895b9c247e0f289b0e945243e94d/LICENSE] > and if necessary include it. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CALCITE-6098) Update LICENSE and NOTICE for Jekyll website template
[
https://issues.apache.org/jira/browse/CALCITE-6098?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stamatis Zampetakis resolved CALCITE-6098.
--
Fix Version/s: 1.37.0
Resolution: Fixed
Fixed in
https://github.com/apache/calcite/commit/58edb0e85f01580961f9fb07f171686166a0da34.
Thanks everyone for the comments and valuable feedback!
> Update LICENSE and NOTICE for Jekyll website template
> -
>
> Key: CALCITE-6098
> URL: https://issues.apache.org/jira/browse/CALCITE-6098
> Project: Calcite
> Issue Type: Task
>Affects Versions: 1.36.0
>Reporter: Stamatis Zampetakis
>Assignee: Stamatis Zampetakis
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.37.0
>
> Attachments: fdupes_cross_repo.sh
>
>
> The NOTICE file contains the following statement:
> {noformat}
> The web site includes files generated by Jekyll.{noformat}
>
> However, there is nothing in the [LICENSE of Jekyll
> |https://github.com/jekyll/jekyll/blob/3f3a283018a976da11a0bfcc13a20d43d37ee29f/LICENSE]
> that requires such attribution.
> According to the instructions of composing the [NOTICE
> file|https://infra.apache.org/licensing-howto.html#mod-notice] for ASF
> projects we shouldn't add anything in there that is not *legally* required.
> Moreover the generated files are not necessary licensed under the same
> LICENSE with the generator.
> JavaCC, ANTLR, and lots of other source generators use a variety of licenses
> but the generated output is not licensed under the same terms. For instance,
> Calcite uses JavaCC, which is licensed under
> [BSD-3|https://github.com/javacc/javacc/blob/master/LICENSE] but both the
> grammar as well as the generated .java files are AL2.
> As long as we are not packaging bits of Jekyll in Calcite there is no need to
> add explicit mentions in LICENSE or NOTICE files.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-6098) Update LICENSE and NOTICE for Jekyll website template
[
https://issues.apache.org/jira/browse/CALCITE-6098?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17808152#comment-17808152
]
Stamatis Zampetakis commented on CALCITE-6098:
--
I compared the content of calcite, orc, and jekyll git repositories at those
revisions that introduced the website content discussed here using the script
in [^fdupes_cross_repo.sh]. Given that I was not sure from which revision
exactly was the copy made from the jekyll repository, I configured the script
to check all those spanning ~2 months before the ORC website was first created
(May 9, 2015). The results of the script are shown below:
{noformat}
307 ./calcite/site/css/screen.scss ./orc/site/css/screen.scss
./jekyll/site/css/screen.scss
307 ./calcite/site/fonts/fontawesome-webfont.eot
./orc/site/fonts/fontawesome-webfont.eot
./jekyll/site/fonts/fontawesome-webfont.eot
307 ./calcite/site/fonts/fontawesome-webfont.svg
./orc/site/fonts/fontawesome-webfont.svg
./jekyll/site/fonts/fontawesome-webfont.svg
307 ./calcite/site/fonts/fontawesome-webfont.ttf
./orc/site/fonts/fontawesome-webfont.ttf
./jekyll/site/fonts/fontawesome-webfont.ttf
307 ./calcite/site/fonts/fontawesome-webfont.woff
./orc/site/fonts/fontawesome-webfont.woff
./jekyll/site/fonts/fontawesome-webfont.woff
307 ./calcite/site/Gemfile ./orc/site/Gemfile
307 ./calcite/site/.gitignore ./orc/site/.gitignore
307 ./calcite/site/_includes/anchor_links.html
./orc/site/_includes/anchor_links.html
./jekyll/site/_includes/anchor_links.html
307 ./calcite/site/_includes/docs_contents.html
./orc/site/_includes/docs_contents.html
./jekyll/site/_includes/docs_contents.html
307 ./calcite/site/_includes/docs_contents_mobile.html
./orc/site/_includes/docs_contents_mobile.html
./jekyll/site/_includes/docs_contents_mobile.html
307 ./calcite/site/_includes/docs_ul.html ./orc/site/_includes/docs_ul.html
307 ./calcite/site/_includes/news_contents_mobile.html
./orc/site/_includes/news_contents_mobile.html
./jekyll/site/_includes/news_contents_mobile.html
307 ./calcite/site/_includes/primary-nav-items.html
./orc/site/_includes/primary-nav-items.html
307 ./calcite/site/_includes/top.html ./orc/site/_includes/top.html
307 ./calcite/site/js/html5shiv.min.js ./orc/site/js/html5shiv.min.js
./jekyll/site/js/html5shiv.min.js
307 ./calcite/site/js/respond.min.js ./orc/site/js/respond.min.js
./jekyll/site/js/respond.min.js
307 ./calcite/site/_layouts/default.html ./orc/site/_layouts/default.html
305 ./calcite/site/_layouts/docs.html ./orc/site/_layouts/docs.html
2 ./calcite/site/_layouts/docs.html ./orc/site/_layouts/docs.html
./jekyll/site/_layouts/docs.html
307 ./calcite/site/_layouts/news.html ./orc/site/_layouts/news.html
./jekyll/site/_layouts/news.html
307 ./calcite/site/_layouts/page.html ./orc/site/_layouts/page.html
./jekyll/site/_layouts/page.html
307 ./calcite/site/news/releases/index.html
./orc/site/news/releases/index.html ./jekyll/site/news/releases/index.html
2 ./calcite/site/_sass/_font-awesome.scss
./orc/site/_sass/_font-awesome.scss
305 ./calcite/site/_sass/_font-awesome.scss
./orc/site/_sass/_font-awesome.scss ./jekyll/site/_sass/_font-awesome.scss
307 ./calcite/site/_sass/_gridism.scss ./orc/site/_sass/_gridism.scss
./jekyll/site/_sass/_gridism.scss
307 ./calcite/site/_sass/_mixins.scss ./orc/site/_sass/_mixins.scss
./jekyll/site/_sass/_mixins.scss
307 ./calcite/site/_sass/_normalize.scss ./orc/site/_sass/_normalize.scss
./jekyll/site/_sass/_normalize.scss
307 ./calcite/site/_sass/_pygments.scss ./orc/site/_sass/_pygments.scss
./jekyll/site/_sass/_pygments.scss
307 ./jekyll/test/source/_slides/octojekyll.png
./jekyll/site/img/octojekyll.png
307 ./orc/site/_includes/docs_option.html
./jekyll/site/_includes/docs_option.html
307 ./orc/site/_includes/news_item.html
./jekyll/site/_includes/news_item.html
{noformat}
Observe that many files under _includes, _layouts, _sass, etc., are exact
duplicates. Some files (e.g., such as header.html and footer.html) do not
appear as duplicates because essentially the content was modified before
committing to make sense for the Apache project.
My take from the above is that the Jekyll template was used for both ORC, and
Calcite website so the files under the respective directories should be under
MIT and this should be mentioned in the main LICENSE file.
I updated the current PR essentially attributing all template based files to
Jekyll. There have been some extensions to the initial template but to avoid
over-complicating the LICENSE and confusing our end-users I attributed
everything under site/_includes, site/_layouts, site/_sass, and site/css to
Jekyll.
I will leave the PR open for 72h in case someone wants to have a look and merge
it afterwards.
[~omalley] since
[jira] [Updated] (CALCITE-6098) Update LICENSE and NOTICE for Jekyll website template
[
https://issues.apache.org/jira/browse/CALCITE-6098?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stamatis Zampetakis updated CALCITE-6098:
-
Attachment: fdupes_cross_repo.sh
> Update LICENSE and NOTICE for Jekyll website template
> -
>
> Key: CALCITE-6098
> URL: https://issues.apache.org/jira/browse/CALCITE-6098
> Project: Calcite
> Issue Type: Task
>Affects Versions: 1.36.0
>Reporter: Stamatis Zampetakis
>Assignee: Stamatis Zampetakis
>Priority: Major
> Labels: pull-request-available
> Attachments: fdupes_cross_repo.sh
>
>
> The NOTICE file contains the following statement:
> {noformat}
> The web site includes files generated by Jekyll.{noformat}
>
> However, there is nothing in the [LICENSE of Jekyll
> |https://github.com/jekyll/jekyll/blob/3f3a283018a976da11a0bfcc13a20d43d37ee29f/LICENSE]
> that requires such attribution.
> According to the instructions of composing the [NOTICE
> file|https://infra.apache.org/licensing-howto.html#mod-notice] for ASF
> projects we shouldn't add anything in there that is not *legally* required.
> Moreover the generated files are not necessary licensed under the same
> LICENSE with the generator.
> JavaCC, ANTLR, and lots of other source generators use a variety of licenses
> but the generated output is not licensed under the same terms. For instance,
> Calcite uses JavaCC, which is licensed under
> [BSD-3|https://github.com/javacc/javacc/blob/master/LICENSE] but both the
> grammar as well as the generated .java files are AL2.
> As long as we are not packaging bits of Jekyll in Calcite there is no need to
> add explicit mentions in LICENSE or NOTICE files.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6098) Update LICENSE and NOTICE for Jekyll website template
[
https://issues.apache.org/jira/browse/CALCITE-6098?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stamatis Zampetakis updated CALCITE-6098:
-
Summary: Update LICENSE and NOTICE for Jekyll website template (was:
Remove mentions of Jekyll from LICENSE and NOTICE files)
> Update LICENSE and NOTICE for Jekyll website template
> -
>
> Key: CALCITE-6098
> URL: https://issues.apache.org/jira/browse/CALCITE-6098
> Project: Calcite
> Issue Type: Task
>Affects Versions: 1.36.0
>Reporter: Stamatis Zampetakis
>Assignee: Stamatis Zampetakis
>Priority: Major
> Labels: pull-request-available
>
> The NOTICE file contains the following statement:
> {noformat}
> The web site includes files generated by Jekyll.{noformat}
>
> However, there is nothing in the [LICENSE of Jekyll
> |https://github.com/jekyll/jekyll/blob/3f3a283018a976da11a0bfcc13a20d43d37ee29f/LICENSE]
> that requires such attribution.
> According to the instructions of composing the [NOTICE
> file|https://infra.apache.org/licensing-howto.html#mod-notice] for ASF
> projects we shouldn't add anything in there that is not *legally* required.
> Moreover the generated files are not necessary licensed under the same
> LICENSE with the generator.
> JavaCC, ANTLR, and lots of other source generators use a variety of licenses
> but the generated output is not licensed under the same terms. For instance,
> Calcite uses JavaCC, which is licensed under
> [BSD-3|https://github.com/javacc/javacc/blob/master/LICENSE] but both the
> grammar as well as the generated .java files are AL2.
> As long as we are not packaging bits of Jekyll in Calcite there is no need to
> add explicit mentions in LICENSE or NOTICE files.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-6098) Remove mentions of Jekyll from LICENSE and NOTICE files
[
https://issues.apache.org/jira/browse/CALCITE-6098?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17807453#comment-17807453
]
Stamatis Zampetakis commented on CALCITE-6098:
--
It looks like a copy yes. However, I wouldn't say that is simply an example. It
is kinda of a template and there are many Jekyll templates available out there.
I agree that we don't need to add something in the NOTICE file but I think the
Jekyll license should be referenced from our main LICENSE file.
> Remove mentions of Jekyll from LICENSE and NOTICE files
> ---
>
> Key: CALCITE-6098
> URL: https://issues.apache.org/jira/browse/CALCITE-6098
> Project: Calcite
> Issue Type: Task
>Affects Versions: 1.36.0
>Reporter: Stamatis Zampetakis
>Assignee: Stamatis Zampetakis
>Priority: Major
> Labels: pull-request-available
>
> The NOTICE file contains the following statement:
> {noformat}
> The web site includes files generated by Jekyll.{noformat}
>
> However, there is nothing in the [LICENSE of Jekyll
> |https://github.com/jekyll/jekyll/blob/3f3a283018a976da11a0bfcc13a20d43d37ee29f/LICENSE]
> that requires such attribution.
> According to the instructions of composing the [NOTICE
> file|https://infra.apache.org/licensing-howto.html#mod-notice] for ASF
> projects we shouldn't add anything in there that is not *legally* required.
> Moreover the generated files are not necessary licensed under the same
> LICENSE with the generator.
> JavaCC, ANTLR, and lots of other source generators use a variety of licenses
> but the generated output is not licensed under the same terms. For instance,
> Calcite uses JavaCC, which is licensed under
> [BSD-3|https://github.com/javacc/javacc/blob/master/LICENSE] but both the
> grammar as well as the generated .java files are AL2.
> As long as we are not packaging bits of Jekyll in Calcite there is no need to
> add explicit mentions in LICENSE or NOTICE files.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6097) cobyism/gridism CSS dependency is mispelled in LICENSE
[ https://issues.apache.org/jira/browse/CALCITE-6097?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stamatis Zampetakis updated CALCITE-6097: - Fix Version/s: 1.37.0 > cobyism/gridism CSS dependency is mispelled in LICENSE > -- > > Key: CALCITE-6097 > URL: https://issues.apache.org/jira/browse/CALCITE-6097 > Project: Calcite > Issue Type: Bug >Affects Versions: avatica-1.24.0, 1.36.0 >Reporter: Stamatis Zampetakis >Assignee: Stamatis Zampetakis >Priority: Major > Labels: pull-request-available > Fix For: 1.37.0 > > > The website uses the > [gridism.css|https://github.com/apache/calcite/blob/4c9011c388f826c36463ae7da875ddb525104376/site/_sass/_gridism.scss] > style for presentation purposes. The file is present in git and also in the > source distribution of Calcite so it should have a proper reference in the > [LICENSE|https://github.com/apache/calcite/blob/4c9011c388f826c36463ae7da875ddb525104376/LICENSE#L186] > file. > There is an entry in the LICENSE file but it is mispelled: gridsim vs gridism -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CALCITE-6097) cobyism/gridism CSS dependency is mispelled in LICENSE
[ https://issues.apache.org/jira/browse/CALCITE-6097?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stamatis Zampetakis resolved CALCITE-6097. -- Resolution: Fixed Fixed in [e71d59fe92c5b39293830ed3416a4db8ac8a369a|https://github.com/apache/calcite/commit/e71d59fe92c5b39293830ed3416a4db8ac8a369a]. Thanks for the review @mbudiu ! > cobyism/gridism CSS dependency is mispelled in LICENSE > -- > > Key: CALCITE-6097 > URL: https://issues.apache.org/jira/browse/CALCITE-6097 > Project: Calcite > Issue Type: Bug >Affects Versions: avatica-1.24.0, 1.36.0 >Reporter: Stamatis Zampetakis >Assignee: Stamatis Zampetakis >Priority: Major > Labels: pull-request-available > > The website uses the > [gridism.css|https://github.com/apache/calcite/blob/4c9011c388f826c36463ae7da875ddb525104376/site/_sass/_gridism.scss] > style for presentation purposes. The file is present in git and also in the > source distribution of Calcite so it should have a proper reference in the > [LICENSE|https://github.com/apache/calcite/blob/4c9011c388f826c36463ae7da875ddb525104376/LICENSE#L186] > file. > There is an entry in the LICENSE file but it is mispelled: gridsim vs gridism -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CALCITE-6096) Remove obsolete html5shiv and respond entries from LICENSE
[ https://issues.apache.org/jira/browse/CALCITE-6096?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stamatis Zampetakis resolved CALCITE-6096. -- Fix Version/s: 1.37.0 Resolution: Fixed > Remove obsolete html5shiv and respond entries from LICENSE > -- > > Key: CALCITE-6096 > URL: https://issues.apache.org/jira/browse/CALCITE-6096 > Project: Calcite > Issue Type: Task > Components: build >Affects Versions: avatica-1.24.0, 1.36.0 >Reporter: Stamatis Zampetakis >Assignee: Stamatis Zampetakis >Priority: Major > Labels: pull-request-available > Fix For: 1.37.0 > > > The [LICENSE > file|https://github.com/apache/calcite/blob/4c9011c388f826c36463ae7da875ddb525104376/LICENSE#L184C3-L184C26] > includes the following entries: > * cobyism:html5shiv:3.7.2 > * respond:respond:1.4.2 > implying that we are bundling the respective dependencies in the project. > These dependencies correspond to minified javascript files that were removed > completely from the project [some time > ago|https://github.com/apache/calcite/commit/7f5e9b8b7e6b4afd8e4f21524aa3c4ce8b7ddb61]. > The references are obsolete and must be removed. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CALCITE-6096) Remove obsolete html5shiv and respond entries from LICENSE
[ https://issues.apache.org/jira/browse/CALCITE-6096?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17806790#comment-17806790 ] Stamatis Zampetakis commented on CALCITE-6096: -- Fixed in [402740d970e162dd0a83172d509199c02a2a23a3|https://github.com/apache/calcite/commit/402740d970e162dd0a83172d509199c02a2a23a3]. Thanks for the review [~mbudiu]! > Remove obsolete html5shiv and respond entries from LICENSE > -- > > Key: CALCITE-6096 > URL: https://issues.apache.org/jira/browse/CALCITE-6096 > Project: Calcite > Issue Type: Task > Components: build >Affects Versions: avatica-1.24.0, 1.36.0 >Reporter: Stamatis Zampetakis >Assignee: Stamatis Zampetakis >Priority: Major > Labels: pull-request-available > > The [LICENSE > file|https://github.com/apache/calcite/blob/4c9011c388f826c36463ae7da875ddb525104376/LICENSE#L184C3-L184C26] > includes the following entries: > * cobyism:html5shiv:3.7.2 > * respond:respond:1.4.2 > implying that we are bundling the respective dependencies in the project. > These dependencies correspond to minified javascript files that were removed > completely from the project [some time > ago|https://github.com/apache/calcite/commit/7f5e9b8b7e6b4afd8e4f21524aa3c4ce8b7ddb61]. > The references are obsolete and must be removed. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CALCITE-6098) Remove mentions of Jekyll from LICENSE and NOTICE files
[
https://issues.apache.org/jira/browse/CALCITE-6098?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17806746#comment-17806746
]
Stamatis Zampetakis commented on CALCITE-6098:
--
Hey [~julianhyde], I would like to finalize this ticket and CALCITE-6099 but I
need some more clarifications just in case you remember.
Initially, I assumed that some of the .html and .css files were automatically
generated by Jekyll as part of CALCITE-355. However, after looking a bit closer
in the history I get the impression that these files were rather copied from
somewhere. My guess is that these files were copied from ORC
(https://github.com/apache/orc/commit/30e8e73443059518544c6c37b038e51679716ce8),
and in tern some of them are probably copied from the [jekyll docs
repo|https://github.com/jekyll/jekyll/tree/b38b7a14798d7231db8ef77d29db1eedeed51f47/docs].
It seems that https://calcite.apache.org/ and https://orc.apache.org/ are built
upon the theme that is used in https://jekyllrb.com/ (introduced by
https://github.com/jekyll/jekyll/pull/583).
If my assumption is correct then I guess that those files that were copied from
ORC and are not present in Jekyll repo should have an ASF header. The rest of
the files are under the Jekyll LICENSE (i.e., MIT) and we should probably add a
relevant mention in our LICENSE file.
> Remove mentions of Jekyll from LICENSE and NOTICE files
> ---
>
> Key: CALCITE-6098
> URL: https://issues.apache.org/jira/browse/CALCITE-6098
> Project: Calcite
> Issue Type: Task
>Affects Versions: 1.36.0
>Reporter: Stamatis Zampetakis
>Assignee: Stamatis Zampetakis
>Priority: Major
> Labels: pull-request-available
>
> The NOTICE file contains the following statement:
> {noformat}
> The web site includes files generated by Jekyll.{noformat}
>
> However, there is nothing in the [LICENSE of Jekyll
> |https://github.com/jekyll/jekyll/blob/3f3a283018a976da11a0bfcc13a20d43d37ee29f/LICENSE]
> that requires such attribution.
> According to the instructions of composing the [NOTICE
> file|https://infra.apache.org/licensing-howto.html#mod-notice] for ASF
> projects we shouldn't add anything in there that is not *legally* required.
> Moreover the generated files are not necessary licensed under the same
> LICENSE with the generator.
> JavaCC, ANTLR, and lots of other source generators use a variety of licenses
> but the generated output is not licensed under the same terms. For instance,
> Calcite uses JavaCC, which is licensed under
> [BSD-3|https://github.com/javacc/javacc/blob/master/LICENSE] but both the
> grammar as well as the generated .java files are AL2.
> As long as we are not packaging bits of Jekyll in Calcite there is no need to
> add explicit mentions in LICENSE or NOTICE files.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-5409) Jdbc doesn't support EnumerableRules.ENUMERABLE_BATCH_NESTED_LOOP_JOIN_RULE
[
https://issues.apache.org/jira/browse/CALCITE-5409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17799471#comment-17799471
]
Stamatis Zampetakis commented on CALCITE-5409:
--
This was previously tagged as a duplicate of CALCITE-4188. The original ticket
had quite a bit of history behind it so not sure why this issue was reopened.
[~kramerul] Is this different from CALCITE-4188? If not then we should continue
the discussion there so other people tracking it can participate as well.
FYI: I had a first look at PR#3562 but didn't fully got how things work. I am
missing the big picture so need to spend more time on it. Will try to go over
it again in the next days.
> Jdbc doesn't support EnumerableRules.ENUMERABLE_BATCH_NESTED_LOOP_JOIN_RULE
> ---
>
> Key: CALCITE-5409
> URL: https://issues.apache.org/jira/browse/CALCITE-5409
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.32.0
>Reporter: Ulrich Kramer
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.33.0
>
>
> Adding the following unit test to {{JdbcAdapterTest}} causes an
> {{NullPointerException}}
> {code:java}
> @Test void testBatchNestedLoopJoin() {
> CalciteAssert.that()
> .with(CalciteConnectionProperty.LEX, Lex.JAVA)
> .with(CalciteConnectionProperty.FORCE_DECORRELATE, false)
> .withSchema("s", new ReflectiveSchema(new HrSchema()))
> .withModel(FoodmartSchema.FOODMART_MODEL)
> .query("select e.name from emps e join foodmart.store x on e.deptno =
> x.store_id")
> .withHook(Hook.PLANNER, (Consumer) planner -> {
> planner.removeRule(EnumerableRules.ENUMERABLE_CORRELATE_RULE);
>
> planner.addRule(EnumerableRules.ENUMERABLE_BATCH_NESTED_LOOP_JOIN_RULE);
> })
> .runs();
> }
> {code}
> {code}
> Error while executing SQL "select e.name from emps e join foodmart.store x on
> e.deptno = x.store_id": Unable to implement
> EnumerableCalc(expr#0..2=[{inputs}], name=[$t0]): rowcount = 375.0,
> cumulative cost = {1465.0 rows, 2968.0 cpu, 0.0 io}, id = 174
> EnumerableBatchNestedLoopJoin(condition=[=($1, $2)], joinType=[inner],
> variablesSet=[[$cor0, ... $cor99]], batchSize=[100]): rowcount = 375.0,
> cumulative cost = {1090.0 rows, 1468.0 cpu, 0.0 io}, id = 170
> EnumerableCalc(expr#0..4=[{inputs}], expr#5=[CAST($t1):INTEGER NOT NULL],
> name=[$t2], deptno0=[$t5]): rowcount = 100.0, cumulative cost = {200.0 rows,
> 901.0 cpu, 0.0 io}, id = 176
> EnumerableTableScan(table=[[s, emps]]): rowcount = 100.0, cumulative
> cost = {100.0 rows, 101.0 cpu, 0.0 io}, id = 52
> JdbcToEnumerableConverter: rowcount = 25.0, cumulative cost = {207.5
> rows, 283.5 cpu, 0.0 io}, id = 168
> JdbcFilter(condition=[OR(=($cor0.deptno0, $0), ...)]): rowcount = 25.0,
> cumulative cost = {205.0 rows, 281.0 cpu, 0.0 io}, id = 166
> JdbcProject(store_id=[$0]): rowcount = 100.0, cumulative cost =
> {180.0 rows, 181.0 cpu, 0.0 io}, id = 164
> JdbcTableScan(table=[[foodmart, store]]): rowcount = 100.0,
> cumulative cost = {100.0 rows, 101.0 cpu, 0.0 io}, id = 3
> ...
> Suppressed: java.lang.NullPointerException: variable $cor0 is not found
> {code}
> See also https://issues.apache.org/jira/browse/CALCITE-5354
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-6162) Add rule(s) to remove joins with constant single tuple relations
[
https://issues.apache.org/jira/browse/CALCITE-6162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17798090#comment-17798090
]
Stamatis Zampetakis commented on CALCITE-6162:
--
I haven't examined all possible joins but I have the feeling that we could
simplify most (if not all) of them. For the left join above we could possibly
make use of CASE WHEN operator:
{code:sql}
select c.empno, c.ename, c.t
from (select e.empno, e.ename, CASE WHEN (e.empno = 7934) THEN
current_timestamp ELSE null END as t from emp e) c
{code}
> Add rule(s) to remove joins with constant single tuple relations
>
>
> Key: CALCITE-6162
> URL: https://issues.apache.org/jira/browse/CALCITE-6162
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: Stamatis Zampetakis
>Assignee: Hanumath Rao Maduri
>Priority: Major
>
> In various cases SQL users tend to create joins even when it is not really
> necessary. One common pattern is creating joins (or cartesian products) with
> constant relations with exactly one tuple.
> *Q1*
> Before:
> {code:sql}
> select e.empno, e.ename, c.* from emp e cross join (select 5,
> current_timestamp) c;
> {code}
> After:
> {code:sql}
> select e.empno, e.ename, 5, current_timestamp from emp e;
> {code}
> *Q2*
> Before:
> {code:sql}
> select e.empno, e.ename, c.t from emp e inner join (select 7934 as ono,
> current_timestamp as t) c on e.empno=c.ono;
> {code}
> After:
> {code:sql}
> select e.empno, e.ename, current_timestamp from emp e where e.empno=7934;
> {code}
> In the queries outlined above the one side of the join is constant and has
> exactly one tuple so the join can be dropped.
> In a nutshell the new rule(s) should be able to transform the "Before" to
> "After" for the above queries.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CALCITE-6162) Add rule(s) to remove joins with constant single tuple relations
Stamatis Zampetakis created CALCITE-6162:
Summary: Add rule(s) to remove joins with constant single tuple
relations
Key: CALCITE-6162
URL: https://issues.apache.org/jira/browse/CALCITE-6162
Project: Calcite
Issue Type: Improvement
Components: core
Reporter: Stamatis Zampetakis
In various cases SQL users tend to create joins even when it is not really
necessary. One common pattern is creating joins (or cartesian products) with
constant relations with exactly one tuple.
*Q1*
Before:
{code:sql}
select e.empno, e.ename, c.* from emp e cross join (select 5,
current_timestamp) c;
{code}
After:
{code:sql}
select e.empno, e.ename, 5, current_timestamp from emp e;
{code}
*Q2*
Before:
{code:sql}
select e.empno, e.ename, c.t from emp e inner join (select 7934 as ono,
current_timestamp as t) c on e.empno=c.ono;
{code}
After:
{code:sql}
select e.empno, e.ename, current_timestamp from emp e where e.empno=7934;
{code}
In the queries outlined above the one side of the join is constant and has
exactly one tuple so the join can be dropped.
In a nutshell the new rule(s) should be able to transform the "Before" to
"After" for the above queries.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-6162) Add rule(s) to remove joins with constant single tuple relations
[
https://issues.apache.org/jira/browse/CALCITE-6162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17795762#comment-17795762
]
Stamatis Zampetakis commented on CALCITE-6162:
--
The
[PruneEmptyRules|https://github.com/apache/calcite/blob/56eb062ba2eae239e9fdda6891830cf2ec60b605/core/src/main/java/org/apache/calcite/rel/rules/PruneEmptyRules.java]
could be a good starting point for getting some inspiration on how to write,
test, and reuse code for the new rules.
> Add rule(s) to remove joins with constant single tuple relations
>
>
> Key: CALCITE-6162
> URL: https://issues.apache.org/jira/browse/CALCITE-6162
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: Stamatis Zampetakis
>Priority: Major
>
> In various cases SQL users tend to create joins even when it is not really
> necessary. One common pattern is creating joins (or cartesian products) with
> constant relations with exactly one tuple.
> *Q1*
> Before:
> {code:sql}
> select e.empno, e.ename, c.* from emp e cross join (select 5,
> current_timestamp) c;
> {code}
> After:
> {code:sql}
> select e.empno, e.ename, 5, current_timestamp from emp e;
> {code}
> *Q2*
> Before:
> {code:sql}
> select e.empno, e.ename, c.t from emp e inner join (select 7934 as ono,
> current_timestamp as t) c on e.empno=c.ono;
> {code}
> After:
> {code:sql}
> select e.empno, e.ename, current_timestamp from emp e where e.empno=7934;
> {code}
> In the queries outlined above the one side of the join is constant and has
> exactly one tuple so the join can be dropped.
> In a nutshell the new rule(s) should be able to transform the "Before" to
> "After" for the above queries.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (CALCITE-6159) SIGABRT when running tests with docker-compose
[
https://issues.apache.org/jira/browse/CALCITE-6159?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stamatis Zampetakis resolved CALCITE-6159.
--
Resolution: Workaround
> SIGABRT when running tests with docker-compose
> --
>
> Key: CALCITE-6159
> URL: https://issues.apache.org/jira/browse/CALCITE-6159
> Project: Calcite
> Issue Type: Bug
> Components: avatica-go
>Affects Versions: avatica-go-5.2.0
> Environment: docker --version
> Docker version 20.10.5, build 55c4c88
> docker-compose --version
> docker-compose version 1.25.5, build 8a1c60f6
>Reporter: Stamatis Zampetakis
>Assignee: Francis Chuang
>Priority: Major
>
> {code:bash}
> docker-compose run test
> {code}
> {noformat}
> WARNING: The GOPATH variable is not set. Defaulting to a blank string.
> Creating network "apache-calcite-avatica-go-530-src_default" with the default
> driver
> Creating apache-calcite-avatica-go-530-src_phoenix_1 ... done
> Creating apache-calcite-avatica-go-530-src_hsqldb_1 ... done
> ? github.com/apache/calcite-avatica-go/v5/errors [no test files]
> ? github.com/apache/calcite-avatica-go/v5/generic [no test files]
> ? github.com/apache/calcite-avatica-go/v5/hsqldb [no test files]
> ? github.com/apache/calcite-avatica-go/v5/internal[no test files]
> ? github.com/apache/calcite-avatica-go/v5/message [no test files]
> ? github.com/apache/calcite-avatica-go/v5/phoenix [no test files]
> runtime/cgo: pthread_create failed: Operation not permitted
> SIGABRT: abort
> PC=0x7f35ff61bd3c m=0 sigcode=18446744073709551610
> goroutine 0 [idle]:
> runtime: g 0: unknown pc 0x7f35ff61bd3c
> stack: frame={sp:0x7fff98c7f800, fp:0x0} stack=[0x7fff98480c80,0x7fff98c7fc90)
> 0x7fff98c7f700: 0x00c58000 0x
> 0x7fff98c7f710: 0x 0x
> 0x7fff98c7f720: 0x 0x7fff98c7f948
> 0x7fff98c7f730: 0x00c32000 0x7fff98c7f968
> 0x7fff98c7f740: 0x0002 0x800e
> 0x7fff98c7f750: 0x 0x
> 0x7fff98c7f760: 0x 0x
> 0x7fff98c7f770: 0x 0x
> 0x7fff98c7f780: 0x009a874d 0x0003
> 0x7fff98c7f790: 0x00e0dc2c 0x
> 0x7fff98c7f7a0: 0x009a91e2 0x0006
> 0x7fff98c7f7b0: 0x00e0dc2a 0x
> 0x7fff98c7f7c0: 0x009a89fe 0x0004
> 0x7fff98c7f7d0: 0x 0x7f35ff689194
> 0x7fff98c7f7e0: 0x 0x000d
> 0x7fff98c7f7f0: 0x00a79653 0x7f35ff61bd2e
> 0x7fff98c7f800: <0x 0x114d148a7e0ab100
> 0x7fff98c7f810: 0x0006 0x7f35ff58e740
> 0x7fff98c7f820: 0x7fff98c7fad0 0x
> 0x7fff98c7f830: 0x00ddde00 0x7f35ff5ccf32
> 0x7fff98c7f840: 0x7f35ff764e70 0x7f35ff5b7472
> 0x7fff98c7f850: 0x0020 0x7f35ff764703
> 0x7fff98c7f860: 0x0d68 0x7f35ff611290
> 0x7fff98c7f870: 0x7f35ff7605e0 0x0001
> 0x7fff98c7f880: 0x000a 0x7f35ff58e740
> 0x7fff98c7f890: 0x 0x00ddde00
> 0x7fff98c7f8a0: 0x0006 0x7f35ff612ee9
> 0x7fff98c7f8b0: 0x7f35ff764680 0x7f35ff6132f3
> 0x7fff98c7f8c0: 0x7f35ff764680 0x000a
> 0x7fff98c7f8d0: 0x7f35ff58e740 0x7f35ff60e87a
> 0x7fff98c7f8e0: 0x7f35ff764840 0x114d148a7e0ab100
> 0x7fff98c7f8f0: 0x7f35ff764840 0x7f35ff764840
> runtime: g 0: unknown pc 0x7f35ff61bd3c
> stack: frame={sp:0x7fff98c7f800, fp:0x0} stack=[0x7fff98480c80,0x7fff98c7fc90)
> 0x7fff98c7f700: 0x00c58000 0x
> 0x7fff98c7f710: 0x 0x
> 0x7fff98c7f720: 0x 0x7fff98c7f948
> 0x7fff98c7f730: 0x00c32000 0x7fff98c7f968
> 0x7fff98c7f740: 0x0002 0x800e
> 0x7fff98c7f750: 0x 0x
> 0x7fff98c7f760: 0x 0x
> 0x7fff98c7f770: 0x 0x
> 0x7fff98c7f780: 0x009a874d 0x0003
> 0x7fff98c7f790: 0x00e0dc2c 0x
> 0x7fff98c7f7a0: 0x009a91e2 0x0006
> 0x7fff98c7f7b0: 0x00e0dc2a 0x
> 0x7fff98c7f7c0: 0x009a89fe 0x0004
> 0x7fff98c7f7d0: 0x 0x7f35ff689194
> 0x7fff98c7f7e0: 0x
[jira] [Commented] (CALCITE-6159) SIGABRT when running tests with docker-compose
[
https://issues.apache.org/jira/browse/CALCITE-6159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17794112#comment-17794112
]
Stamatis Zampetakis commented on CALCITE-6159:
--
I upgraded docker to version 24.0.7, build afdd53b and now the tests run fine
on my environment. Not sure what's the issue with older versions of docker but
I guess we can close this for now.
> SIGABRT when running tests with docker-compose
> --
>
> Key: CALCITE-6159
> URL: https://issues.apache.org/jira/browse/CALCITE-6159
> Project: Calcite
> Issue Type: Bug
> Components: avatica-go
>Affects Versions: avatica-go-5.2.0
> Environment: docker --version
> Docker version 20.10.5, build 55c4c88
> docker-compose --version
> docker-compose version 1.25.5, build 8a1c60f6
>Reporter: Stamatis Zampetakis
>Assignee: Francis Chuang
>Priority: Major
>
> {code:bash}
> docker-compose run test
> {code}
> {noformat}
> WARNING: The GOPATH variable is not set. Defaulting to a blank string.
> Creating network "apache-calcite-avatica-go-530-src_default" with the default
> driver
> Creating apache-calcite-avatica-go-530-src_phoenix_1 ... done
> Creating apache-calcite-avatica-go-530-src_hsqldb_1 ... done
> ? github.com/apache/calcite-avatica-go/v5/errors [no test files]
> ? github.com/apache/calcite-avatica-go/v5/generic [no test files]
> ? github.com/apache/calcite-avatica-go/v5/hsqldb [no test files]
> ? github.com/apache/calcite-avatica-go/v5/internal[no test files]
> ? github.com/apache/calcite-avatica-go/v5/message [no test files]
> ? github.com/apache/calcite-avatica-go/v5/phoenix [no test files]
> runtime/cgo: pthread_create failed: Operation not permitted
> SIGABRT: abort
> PC=0x7f35ff61bd3c m=0 sigcode=18446744073709551610
> goroutine 0 [idle]:
> runtime: g 0: unknown pc 0x7f35ff61bd3c
> stack: frame={sp:0x7fff98c7f800, fp:0x0} stack=[0x7fff98480c80,0x7fff98c7fc90)
> 0x7fff98c7f700: 0x00c58000 0x
> 0x7fff98c7f710: 0x 0x
> 0x7fff98c7f720: 0x 0x7fff98c7f948
> 0x7fff98c7f730: 0x00c32000 0x7fff98c7f968
> 0x7fff98c7f740: 0x0002 0x800e
> 0x7fff98c7f750: 0x 0x
> 0x7fff98c7f760: 0x 0x
> 0x7fff98c7f770: 0x 0x
> 0x7fff98c7f780: 0x009a874d 0x0003
> 0x7fff98c7f790: 0x00e0dc2c 0x
> 0x7fff98c7f7a0: 0x009a91e2 0x0006
> 0x7fff98c7f7b0: 0x00e0dc2a 0x
> 0x7fff98c7f7c0: 0x009a89fe 0x0004
> 0x7fff98c7f7d0: 0x 0x7f35ff689194
> 0x7fff98c7f7e0: 0x 0x000d
> 0x7fff98c7f7f0: 0x00a79653 0x7f35ff61bd2e
> 0x7fff98c7f800: <0x 0x114d148a7e0ab100
> 0x7fff98c7f810: 0x0006 0x7f35ff58e740
> 0x7fff98c7f820: 0x7fff98c7fad0 0x
> 0x7fff98c7f830: 0x00ddde00 0x7f35ff5ccf32
> 0x7fff98c7f840: 0x7f35ff764e70 0x7f35ff5b7472
> 0x7fff98c7f850: 0x0020 0x7f35ff764703
> 0x7fff98c7f860: 0x0d68 0x7f35ff611290
> 0x7fff98c7f870: 0x7f35ff7605e0 0x0001
> 0x7fff98c7f880: 0x000a 0x7f35ff58e740
> 0x7fff98c7f890: 0x 0x00ddde00
> 0x7fff98c7f8a0: 0x0006 0x7f35ff612ee9
> 0x7fff98c7f8b0: 0x7f35ff764680 0x7f35ff6132f3
> 0x7fff98c7f8c0: 0x7f35ff764680 0x000a
> 0x7fff98c7f8d0: 0x7f35ff58e740 0x7f35ff60e87a
> 0x7fff98c7f8e0: 0x7f35ff764840 0x114d148a7e0ab100
> 0x7fff98c7f8f0: 0x7f35ff764840 0x7f35ff764840
> runtime: g 0: unknown pc 0x7f35ff61bd3c
> stack: frame={sp:0x7fff98c7f800, fp:0x0} stack=[0x7fff98480c80,0x7fff98c7fc90)
> 0x7fff98c7f700: 0x00c58000 0x
> 0x7fff98c7f710: 0x 0x
> 0x7fff98c7f720: 0x 0x7fff98c7f948
> 0x7fff98c7f730: 0x00c32000 0x7fff98c7f968
> 0x7fff98c7f740: 0x0002 0x800e
> 0x7fff98c7f750: 0x 0x
> 0x7fff98c7f760: 0x 0x
> 0x7fff98c7f770: 0x 0x
> 0x7fff98c7f780: 0x009a874d 0x0003
> 0x7fff98c7f790: 0x00e0dc2c 0x
> 0x7fff98c7f7a0: 0x009a91e2 0x0006
> 0x7fff98c7f7b0:
[jira] [Resolved] (CALCITE-6160) Missing ASF header from go.mod and go.sum files
[ https://issues.apache.org/jira/browse/CALCITE-6160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stamatis Zampetakis resolved CALCITE-6160. -- Resolution: Not A Problem > Missing ASF header from go.mod and go.sum files > --- > > Key: CALCITE-6160 > URL: https://issues.apache.org/jira/browse/CALCITE-6160 > Project: Calcite > Issue Type: Bug > Components: avatica-go >Affects Versions: avatica-go-5.2.0 >Reporter: Stamatis Zampetakis >Assignee: Francis Chuang >Priority: Major > > The go.mod and go.sum files in [avatica-go > repository|https://github.com/apache/calcite-avatica-go] do not contain the > ASF header according to the [ASF > policy|https://www.apache.org/legal/src-headers.html#headers]. > I am not familiar with go so maybe it is impossible to add comments in these > files so in that case I guess it is ok to leave them as is. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CALCITE-6160) Missing ASF header from go.mod and go.sum files
[ https://issues.apache.org/jira/browse/CALCITE-6160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17794103#comment-17794103 ] Stamatis Zampetakis commented on CALCITE-6160: -- I've just found that there is an explicit exclusion for these files in the [header validation check|https://github.com/apache/calcite-avatica-go/blob/8657d0ac4148dca20f67253e78be222d10cc9c6a/docker.sh#L176] so I assume that its normal that they don't have one. > Missing ASF header from go.mod and go.sum files > --- > > Key: CALCITE-6160 > URL: https://issues.apache.org/jira/browse/CALCITE-6160 > Project: Calcite > Issue Type: Bug > Components: avatica-go >Affects Versions: avatica-go-5.2.0 >Reporter: Stamatis Zampetakis >Assignee: Francis Chuang >Priority: Major > > The go.mod and go.sum files in [avatica-go > repository|https://github.com/apache/calcite-avatica-go] do not contain the > ASF header according to the [ASF > policy|https://www.apache.org/legal/src-headers.html#headers]. > I am not familiar with go so maybe it is impossible to add comments in these > files so in that case I guess it is ok to leave them as is. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CALCITE-6160) Missing ASF header from go.mod and go.sum files
Stamatis Zampetakis created CALCITE-6160: Summary: Missing ASF header from go.mod and go.sum files Key: CALCITE-6160 URL: https://issues.apache.org/jira/browse/CALCITE-6160 Project: Calcite Issue Type: Bug Components: avatica-go Affects Versions: avatica-go-5.2.0 Reporter: Stamatis Zampetakis Assignee: Francis Chuang The go.mod and go.sum files in [avatica-go repository|https://github.com/apache/calcite-avatica-go] do not contain the ASF header according to the [ASF policy|https://www.apache.org/legal/src-headers.html#headers]. I am not familiar with go so maybe it is impossible to add comments in these files so in that case I guess it is ok to leave them as is. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CALCITE-6159) SIGABRT when running tests with docker-compose
Stamatis Zampetakis created CALCITE-6159:
Summary: SIGABRT when running tests with docker-compose
Key: CALCITE-6159
URL: https://issues.apache.org/jira/browse/CALCITE-6159
Project: Calcite
Issue Type: Bug
Components: avatica-go
Affects Versions: avatica-go-5.2.0
Environment: docker --version
Docker version 20.10.5, build 55c4c88
docker-compose --version
docker-compose version 1.25.5, build 8a1c60f6
Reporter: Stamatis Zampetakis
Assignee: Francis Chuang
{code:bash}
docker-compose run test
{code}
{noformat}
WARNING: The GOPATH variable is not set. Defaulting to a blank string.
Creating network "apache-calcite-avatica-go-530-src_default" with the default
driver
Creating apache-calcite-avatica-go-530-src_phoenix_1 ... done
Creating apache-calcite-avatica-go-530-src_hsqldb_1 ... done
? github.com/apache/calcite-avatica-go/v5/errors [no test files]
? github.com/apache/calcite-avatica-go/v5/generic [no test files]
? github.com/apache/calcite-avatica-go/v5/hsqldb [no test files]
? github.com/apache/calcite-avatica-go/v5/internal[no test files]
? github.com/apache/calcite-avatica-go/v5/message [no test files]
? github.com/apache/calcite-avatica-go/v5/phoenix [no test files]
runtime/cgo: pthread_create failed: Operation not permitted
SIGABRT: abort
PC=0x7f35ff61bd3c m=0 sigcode=18446744073709551610
goroutine 0 [idle]:
runtime: g 0: unknown pc 0x7f35ff61bd3c
stack: frame={sp:0x7fff98c7f800, fp:0x0} stack=[0x7fff98480c80,0x7fff98c7fc90)
0x7fff98c7f700: 0x00c58000 0x
0x7fff98c7f710: 0x 0x
0x7fff98c7f720: 0x 0x7fff98c7f948
0x7fff98c7f730: 0x00c32000 0x7fff98c7f968
0x7fff98c7f740: 0x0002 0x800e
0x7fff98c7f750: 0x 0x
0x7fff98c7f760: 0x 0x
0x7fff98c7f770: 0x 0x
0x7fff98c7f780: 0x009a874d 0x0003
0x7fff98c7f790: 0x00e0dc2c 0x
0x7fff98c7f7a0: 0x009a91e2 0x0006
0x7fff98c7f7b0: 0x00e0dc2a 0x
0x7fff98c7f7c0: 0x009a89fe 0x0004
0x7fff98c7f7d0: 0x 0x7f35ff689194
0x7fff98c7f7e0: 0x 0x000d
0x7fff98c7f7f0: 0x00a79653 0x7f35ff61bd2e
0x7fff98c7f800: <0x 0x114d148a7e0ab100
0x7fff98c7f810: 0x0006 0x7f35ff58e740
0x7fff98c7f820: 0x7fff98c7fad0 0x
0x7fff98c7f830: 0x00ddde00 0x7f35ff5ccf32
0x7fff98c7f840: 0x7f35ff764e70 0x7f35ff5b7472
0x7fff98c7f850: 0x0020 0x7f35ff764703
0x7fff98c7f860: 0x0d68 0x7f35ff611290
0x7fff98c7f870: 0x7f35ff7605e0 0x0001
0x7fff98c7f880: 0x000a 0x7f35ff58e740
0x7fff98c7f890: 0x 0x00ddde00
0x7fff98c7f8a0: 0x0006 0x7f35ff612ee9
0x7fff98c7f8b0: 0x7f35ff764680 0x7f35ff6132f3
0x7fff98c7f8c0: 0x7f35ff764680 0x000a
0x7fff98c7f8d0: 0x7f35ff58e740 0x7f35ff60e87a
0x7fff98c7f8e0: 0x7f35ff764840 0x114d148a7e0ab100
0x7fff98c7f8f0: 0x7f35ff764840 0x7f35ff764840
runtime: g 0: unknown pc 0x7f35ff61bd3c
stack: frame={sp:0x7fff98c7f800, fp:0x0} stack=[0x7fff98480c80,0x7fff98c7fc90)
0x7fff98c7f700: 0x00c58000 0x
0x7fff98c7f710: 0x 0x
0x7fff98c7f720: 0x 0x7fff98c7f948
0x7fff98c7f730: 0x00c32000 0x7fff98c7f968
0x7fff98c7f740: 0x0002 0x800e
0x7fff98c7f750: 0x 0x
0x7fff98c7f760: 0x 0x
0x7fff98c7f770: 0x 0x
0x7fff98c7f780: 0x009a874d 0x0003
0x7fff98c7f790: 0x00e0dc2c 0x
0x7fff98c7f7a0: 0x009a91e2 0x0006
0x7fff98c7f7b0: 0x00e0dc2a 0x
0x7fff98c7f7c0: 0x009a89fe 0x0004
0x7fff98c7f7d0: 0x 0x7f35ff689194
0x7fff98c7f7e0: 0x 0x000d
0x7fff98c7f7f0: 0x00a79653 0x7f35ff61bd2e
0x7fff98c7f800: <0x 0x114d148a7e0ab100
0x7fff98c7f810: 0x0006 0x7f35ff58e740
0x7fff98c7f820: 0x7fff98c7fad0 0x
0x7fff98c7f830: 0x00ddde00 0x7f35ff5ccf32
0x7fff98c7f840: 0x7f35ff764e70
[jira] [Created] (CALCITE-6158) No instructions for building/testing the project in README file
Stamatis Zampetakis created CALCITE-6158: Summary: No instructions for building/testing the project in README file Key: CALCITE-6158 URL: https://issues.apache.org/jira/browse/CALCITE-6158 Project: Calcite Issue Type: Bug Components: avatica-go Affects Versions: avatica-go-5.2.0 Reporter: Stamatis Zampetakis Assignee: Francis Chuang The [avatica-go repository|https://github.com/apache/calcite-avatica-go] and subsequently the source distribution do not contain instructions (or links to the appropriate place in the documentation) to build and test the project in the README file at the root of the project. Someone who downloads the released sources and its not familiar with the project may have a hard time using it. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (CALCITE-6123) DruidAdapterIT#testInterleaveBetweenAggregateAndGroupOrderByOnMetrics fails
[
https://issues.apache.org/jira/browse/CALCITE-6123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17793780#comment-17793780
]
Stamatis Zampetakis edited comment on CALCITE-6123 at 12/6/23 3:26 PM:
---
[~jiajunbernoulli] I suspect that it has to do with how the test execution
framework (Junit) defines execution order. Although, I haven't confirmed I
suspect that in our setting test order is defined by the [Random
strategy|https://github.com/junit-team/junit5/blob/9115e233b8d589f1082179f2de17a4698a081cc5/junit-jupiter-api/src/main/java/org/junit/jupiter/api/MethodOrderer.java#L264],
which uses {{System.nanoTime}} as a seed. Every time we run the tests we will
have a different seed for random so I guess test order is sensitive to when the
tests are run.
was (Author: zabetak):
[~jiajunbernoulli] I suspect that it has to do with how text execution
framework (Junit) defines execution order. Although, I haven't confirmed I
suspect that in our setting test order is defined by the [Random
strategy|https://github.com/junit-team/junit5/blob/9115e233b8d589f1082179f2de17a4698a081cc5/junit-jupiter-api/src/main/java/org/junit/jupiter/api/MethodOrderer.java#L264],
which uses {{System.nanoTime}} as a seed. Every time we run the tests we will
have a different seed for random so I guess test order is sensitive to when the
tests are run.
> DruidAdapterIT#testInterleaveBetweenAggregateAndGroupOrderByOnMetrics fails
> ---
>
> Key: CALCITE-6123
> URL: https://issues.apache.org/jira/browse/CALCITE-6123
> Project: Calcite
> Issue Type: Bug
> Components: tests
>Affects Versions: 1.36.0
>Reporter: Benchao Li
>Assignee: Stamatis Zampetakis
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.37.0
>
> Attachments: image-2023-11-19-15-17-53-699.png
>
>
> The test that is failing is
> testInterleaveBetweenAggregateAndGroupOrderByOnMetrics and the error is shown
> below:
> {noformat}
> FAILURE 0.6sec, org.apache.calcite.test.DruidAdapterIT >
> testInterleaveBetweenAggregateAndGroupOrderByOnMetrics()
> java.lang.AssertionError:
> Expected: "store_state=CA; brand_name=King; A=21.4632\nstore_state=OR;
> brand_name=Symphony; A=32.176\nstore_state=CA; brand_name=Toretti;
> A=32.2465\nstore_state=WA; brand_name=King; A=34.6104\nstore_state=OR;
> brand_name=Toretti; A=36.3"
> but: was "store_state=OR; brand_name=ADJ; A=83.8764\nstore_state=WA;
> brand_name=Akron; A=85.8402\nstore_state=OR; brand_name=American;
> A=86.7898\nstore_state=WA; brand_name=ADJ; A=97.6488\nstore_state=CA;
> brand_name=ADJ; A=98.0076"
> at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:18)
> at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:6)
> at
> org.apache.calcite.test.CalciteAssert.lambda$checkResult$6(CalciteAssert.java:453)
> at
> org.apache.calcite.test.CalciteAssert.assertQuery(CalciteAssert.java:582)
> at
> org.apache.calcite.test.CalciteAssert$AssertQuery.lambda$returns$1(CalciteAssert.java:1495)
> at
> org.apache.calcite.test.CalciteAssert$AssertQuery.withConnection(CalciteAssert.java:1434)
> at
> org.apache.calcite.test.CalciteAssert$AssertQuery.returns(CalciteAssert.java:1493)
> at
> org.apache.calcite.test.CalciteAssert$AssertQuery.returns(CalciteAssert.java:1483)
> at
> org.apache.calcite.test.CalciteAssert$AssertQuery.returnsOrdered(CalciteAssert.java:1509)
> at
> org.apache.calcite.test.DruidAdapterIT.testInterleaveBetweenAggregateAndGroupOrderByOnMetrics(DruidAdapterIT.java:2336)
> Suppressed: org.apache.calcite.util.TestUtil$ExtraInformation: With
> materializationsEnabled=false, limit=-1, sql=select "store_state",
> "brand_name", "A" from (
> select sum("store_sales")-sum("store_cost") as a, "store_state",
> "brand_name"
> from "foodmart"
> group by "store_state", "brand_name" ) subq
> order by "A" limit 5
> at
> app//org.apache.calcite.util.TestUtil.rethrow(TestUtil.java:389)
> at
> app//org.apache.calcite.test.CalciteAssert.assertQuery(CalciteAssert.java:598)
> ... 6 more
> {noformat}
>
> The test is all failing after
> [https://github.com/apache/calcite/commit/55034513b463c938035e5d2436949bbf734b84b6],
> I'm not sure whether it's related.
> See following jobs:
> * [https://github.com/apache/calcite/actions/runs/6886169664/job/18731435605]
> * [https://github.com/apache/calcite/actions/runs/6885301555/job/18729238762]
> * [https://github.com/apache/calcite/actions/runs/6871630651/job/18688793776]
> * [https://github.com/apache/calcite/actions/runs/6860287671/job/18653876601]
--
This
[jira] [Comment Edited] (CALCITE-6123) DruidAdapterIT#testInterleaveBetweenAggregateAndGroupOrderByOnMetrics fails
[
https://issues.apache.org/jira/browse/CALCITE-6123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17793780#comment-17793780
]
Stamatis Zampetakis edited comment on CALCITE-6123 at 12/6/23 3:25 PM:
---
[~jiajunbernoulli] I suspect that it has to do with how text execution
framework (Junit) defines execution order. Although, I haven't confirmed I
suspect that in our setting test order is defined by the [Random
strategy|https://github.com/junit-team/junit5/blob/9115e233b8d589f1082179f2de17a4698a081cc5/junit-jupiter-api/src/main/java/org/junit/jupiter/api/MethodOrderer.java#L264],
which uses {{System.nanoTime}} as a seed. Every time we run the tests we will
have a different seed for random so I guess test order is sensitive to when the
tests are run.
was (Author: zabetak):
[~jiajunbernoulli] I suspect that it has to do with how text execution
framework (Junit) defines execution order. Although, I haven't confirmed I
suspect that in our setting test order is defined by the [Random|
https://github.com/junit-team/junit5/blob/9115e233b8d589f1082179f2de17a4698a081cc5/junit-jupiter-api/src/main/java/org/junit/jupiter/api/MethodOrderer.java#L264]
strategy which uses {{System.nanoTime}} as a seed. Every time we run the tests
we will have a different seed for random so I guess test order is sensitive to
when the tests are run.
> DruidAdapterIT#testInterleaveBetweenAggregateAndGroupOrderByOnMetrics fails
> ---
>
> Key: CALCITE-6123
> URL: https://issues.apache.org/jira/browse/CALCITE-6123
> Project: Calcite
> Issue Type: Bug
> Components: tests
>Affects Versions: 1.36.0
>Reporter: Benchao Li
>Assignee: Stamatis Zampetakis
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.37.0
>
> Attachments: image-2023-11-19-15-17-53-699.png
>
>
> The test that is failing is
> testInterleaveBetweenAggregateAndGroupOrderByOnMetrics and the error is shown
> below:
> {noformat}
> FAILURE 0.6sec, org.apache.calcite.test.DruidAdapterIT >
> testInterleaveBetweenAggregateAndGroupOrderByOnMetrics()
> java.lang.AssertionError:
> Expected: "store_state=CA; brand_name=King; A=21.4632\nstore_state=OR;
> brand_name=Symphony; A=32.176\nstore_state=CA; brand_name=Toretti;
> A=32.2465\nstore_state=WA; brand_name=King; A=34.6104\nstore_state=OR;
> brand_name=Toretti; A=36.3"
> but: was "store_state=OR; brand_name=ADJ; A=83.8764\nstore_state=WA;
> brand_name=Akron; A=85.8402\nstore_state=OR; brand_name=American;
> A=86.7898\nstore_state=WA; brand_name=ADJ; A=97.6488\nstore_state=CA;
> brand_name=ADJ; A=98.0076"
> at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:18)
> at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:6)
> at
> org.apache.calcite.test.CalciteAssert.lambda$checkResult$6(CalciteAssert.java:453)
> at
> org.apache.calcite.test.CalciteAssert.assertQuery(CalciteAssert.java:582)
> at
> org.apache.calcite.test.CalciteAssert$AssertQuery.lambda$returns$1(CalciteAssert.java:1495)
> at
> org.apache.calcite.test.CalciteAssert$AssertQuery.withConnection(CalciteAssert.java:1434)
> at
> org.apache.calcite.test.CalciteAssert$AssertQuery.returns(CalciteAssert.java:1493)
> at
> org.apache.calcite.test.CalciteAssert$AssertQuery.returns(CalciteAssert.java:1483)
> at
> org.apache.calcite.test.CalciteAssert$AssertQuery.returnsOrdered(CalciteAssert.java:1509)
> at
> org.apache.calcite.test.DruidAdapterIT.testInterleaveBetweenAggregateAndGroupOrderByOnMetrics(DruidAdapterIT.java:2336)
> Suppressed: org.apache.calcite.util.TestUtil$ExtraInformation: With
> materializationsEnabled=false, limit=-1, sql=select "store_state",
> "brand_name", "A" from (
> select sum("store_sales")-sum("store_cost") as a, "store_state",
> "brand_name"
> from "foodmart"
> group by "store_state", "brand_name" ) subq
> order by "A" limit 5
> at
> app//org.apache.calcite.util.TestUtil.rethrow(TestUtil.java:389)
> at
> app//org.apache.calcite.test.CalciteAssert.assertQuery(CalciteAssert.java:598)
> ... 6 more
> {noformat}
>
> The test is all failing after
> [https://github.com/apache/calcite/commit/55034513b463c938035e5d2436949bbf734b84b6],
> I'm not sure whether it's related.
> See following jobs:
> * [https://github.com/apache/calcite/actions/runs/6886169664/job/18731435605]
> * [https://github.com/apache/calcite/actions/runs/6885301555/job/18729238762]
> * [https://github.com/apache/calcite/actions/runs/6871630651/job/18688793776]
> * [https://github.com/apache/calcite/actions/runs/6860287671/job/18653876601]
--
This message
[jira] [Commented] (CALCITE-6123) DruidAdapterIT#testInterleaveBetweenAggregateAndGroupOrderByOnMetrics fails
[
https://issues.apache.org/jira/browse/CALCITE-6123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17793780#comment-17793780
]
Stamatis Zampetakis commented on CALCITE-6123:
--
[~jiajunbernoulli] I suspect that it has to do with how text execution
framework (Junit) defines execution order. Although, I haven't confirmed I
suspect that in our setting test order is defined by the [Random|
https://github.com/junit-team/junit5/blob/9115e233b8d589f1082179f2de17a4698a081cc5/junit-jupiter-api/src/main/java/org/junit/jupiter/api/MethodOrderer.java#L264]
strategy which uses {{System.nanoTime}} as a seed. Every time we run the tests
we will have a different seed for random so I guess test order is sensitive to
when the tests are run.
> DruidAdapterIT#testInterleaveBetweenAggregateAndGroupOrderByOnMetrics fails
> ---
>
> Key: CALCITE-6123
> URL: https://issues.apache.org/jira/browse/CALCITE-6123
> Project: Calcite
> Issue Type: Bug
> Components: tests
>Affects Versions: 1.36.0
>Reporter: Benchao Li
>Assignee: Stamatis Zampetakis
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.37.0
>
> Attachments: image-2023-11-19-15-17-53-699.png
>
>
> The test that is failing is
> testInterleaveBetweenAggregateAndGroupOrderByOnMetrics and the error is shown
> below:
> {noformat}
> FAILURE 0.6sec, org.apache.calcite.test.DruidAdapterIT >
> testInterleaveBetweenAggregateAndGroupOrderByOnMetrics()
> java.lang.AssertionError:
> Expected: "store_state=CA; brand_name=King; A=21.4632\nstore_state=OR;
> brand_name=Symphony; A=32.176\nstore_state=CA; brand_name=Toretti;
> A=32.2465\nstore_state=WA; brand_name=King; A=34.6104\nstore_state=OR;
> brand_name=Toretti; A=36.3"
> but: was "store_state=OR; brand_name=ADJ; A=83.8764\nstore_state=WA;
> brand_name=Akron; A=85.8402\nstore_state=OR; brand_name=American;
> A=86.7898\nstore_state=WA; brand_name=ADJ; A=97.6488\nstore_state=CA;
> brand_name=ADJ; A=98.0076"
> at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:18)
> at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:6)
> at
> org.apache.calcite.test.CalciteAssert.lambda$checkResult$6(CalciteAssert.java:453)
> at
> org.apache.calcite.test.CalciteAssert.assertQuery(CalciteAssert.java:582)
> at
> org.apache.calcite.test.CalciteAssert$AssertQuery.lambda$returns$1(CalciteAssert.java:1495)
> at
> org.apache.calcite.test.CalciteAssert$AssertQuery.withConnection(CalciteAssert.java:1434)
> at
> org.apache.calcite.test.CalciteAssert$AssertQuery.returns(CalciteAssert.java:1493)
> at
> org.apache.calcite.test.CalciteAssert$AssertQuery.returns(CalciteAssert.java:1483)
> at
> org.apache.calcite.test.CalciteAssert$AssertQuery.returnsOrdered(CalciteAssert.java:1509)
> at
> org.apache.calcite.test.DruidAdapterIT.testInterleaveBetweenAggregateAndGroupOrderByOnMetrics(DruidAdapterIT.java:2336)
> Suppressed: org.apache.calcite.util.TestUtil$ExtraInformation: With
> materializationsEnabled=false, limit=-1, sql=select "store_state",
> "brand_name", "A" from (
> select sum("store_sales")-sum("store_cost") as a, "store_state",
> "brand_name"
> from "foodmart"
> group by "store_state", "brand_name" ) subq
> order by "A" limit 5
> at
> app//org.apache.calcite.util.TestUtil.rethrow(TestUtil.java:389)
> at
> app//org.apache.calcite.test.CalciteAssert.assertQuery(CalciteAssert.java:598)
> ... 6 more
> {noformat}
>
> The test is all failing after
> [https://github.com/apache/calcite/commit/55034513b463c938035e5d2436949bbf734b84b6],
> I'm not sure whether it's related.
> See following jobs:
> * [https://github.com/apache/calcite/actions/runs/6886169664/job/18731435605]
> * [https://github.com/apache/calcite/actions/runs/6885301555/job/18729238762]
> * [https://github.com/apache/calcite/actions/runs/6871630651/job/18688793776]
> * [https://github.com/apache/calcite/actions/runs/6860287671/job/18653876601]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (CALCITE-6123) DruidAdapterIT#testInterleaveBetweenAggregateAndGroupOrderByOnMetrics fails
[
https://issues.apache.org/jira/browse/CALCITE-6123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stamatis Zampetakis resolved CALCITE-6123.
--
Fix Version/s: 1.37.0
Resolution: Fixed
Fixed in
https://github.com/zabetak/calcite-druid-dataset/commit/f763c73901085885b93c00c39ecba37b3e3bb31a.
Thanks everyone who helped troubleshoot this issue.
Hopefully, disabling the Druid query cache should be enough to stabilize the
Druid tests. If the test fails again in the CI then we can reopen the ticket.
> DruidAdapterIT#testInterleaveBetweenAggregateAndGroupOrderByOnMetrics fails
> ---
>
> Key: CALCITE-6123
> URL: https://issues.apache.org/jira/browse/CALCITE-6123
> Project: Calcite
> Issue Type: Bug
> Components: tests
>Affects Versions: 1.36.0
>Reporter: Benchao Li
>Assignee: Stamatis Zampetakis
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.37.0
>
> Attachments: image-2023-11-19-15-17-53-699.png
>
>
> The test that is failing is
> testInterleaveBetweenAggregateAndGroupOrderByOnMetrics and the error is shown
> below:
> {noformat}
> FAILURE 0.6sec, org.apache.calcite.test.DruidAdapterIT >
> testInterleaveBetweenAggregateAndGroupOrderByOnMetrics()
> java.lang.AssertionError:
> Expected: "store_state=CA; brand_name=King; A=21.4632\nstore_state=OR;
> brand_name=Symphony; A=32.176\nstore_state=CA; brand_name=Toretti;
> A=32.2465\nstore_state=WA; brand_name=King; A=34.6104\nstore_state=OR;
> brand_name=Toretti; A=36.3"
> but: was "store_state=OR; brand_name=ADJ; A=83.8764\nstore_state=WA;
> brand_name=Akron; A=85.8402\nstore_state=OR; brand_name=American;
> A=86.7898\nstore_state=WA; brand_name=ADJ; A=97.6488\nstore_state=CA;
> brand_name=ADJ; A=98.0076"
> at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:18)
> at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:6)
> at
> org.apache.calcite.test.CalciteAssert.lambda$checkResult$6(CalciteAssert.java:453)
> at
> org.apache.calcite.test.CalciteAssert.assertQuery(CalciteAssert.java:582)
> at
> org.apache.calcite.test.CalciteAssert$AssertQuery.lambda$returns$1(CalciteAssert.java:1495)
> at
> org.apache.calcite.test.CalciteAssert$AssertQuery.withConnection(CalciteAssert.java:1434)
> at
> org.apache.calcite.test.CalciteAssert$AssertQuery.returns(CalciteAssert.java:1493)
> at
> org.apache.calcite.test.CalciteAssert$AssertQuery.returns(CalciteAssert.java:1483)
> at
> org.apache.calcite.test.CalciteAssert$AssertQuery.returnsOrdered(CalciteAssert.java:1509)
> at
> org.apache.calcite.test.DruidAdapterIT.testInterleaveBetweenAggregateAndGroupOrderByOnMetrics(DruidAdapterIT.java:2336)
> Suppressed: org.apache.calcite.util.TestUtil$ExtraInformation: With
> materializationsEnabled=false, limit=-1, sql=select "store_state",
> "brand_name", "A" from (
> select sum("store_sales")-sum("store_cost") as a, "store_state",
> "brand_name"
> from "foodmart"
> group by "store_state", "brand_name" ) subq
> order by "A" limit 5
> at
> app//org.apache.calcite.util.TestUtil.rethrow(TestUtil.java:389)
> at
> app//org.apache.calcite.test.CalciteAssert.assertQuery(CalciteAssert.java:598)
> ... 6 more
> {noformat}
>
> The test is all failing after
> [https://github.com/apache/calcite/commit/55034513b463c938035e5d2436949bbf734b84b6],
> I'm not sure whether it's related.
> See following jobs:
> * [https://github.com/apache/calcite/actions/runs/6886169664/job/18731435605]
> * [https://github.com/apache/calcite/actions/runs/6885301555/job/18729238762]
> * [https://github.com/apache/calcite/actions/runs/6871630651/job/18688793776]
> * [https://github.com/apache/calcite/actions/runs/6860287671/job/18653876601]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6123) DruidAdapterIT#testInterleaveBetweenAggregateAndGroupOrderByOnMetrics fails
[
https://issues.apache.org/jira/browse/CALCITE-6123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stamatis Zampetakis updated CALCITE-6123:
-
Summary:
DruidAdapterIT#testInterleaveBetweenAggregateAndGroupOrderByOnMetrics fails
(was: DruidAdapter2IT is failing )
> DruidAdapterIT#testInterleaveBetweenAggregateAndGroupOrderByOnMetrics fails
> ---
>
> Key: CALCITE-6123
> URL: https://issues.apache.org/jira/browse/CALCITE-6123
> Project: Calcite
> Issue Type: Bug
> Components: tests
>Affects Versions: 1.36.0
>Reporter: Benchao Li
>Assignee: Stamatis Zampetakis
>Priority: Major
> Labels: pull-request-available
> Attachments: image-2023-11-19-15-17-53-699.png
>
>
> The test that is failing is
> testInterleaveBetweenAggregateAndGroupOrderByOnMetrics and the error is shown
> below:
> {noformat}
> FAILURE 0.6sec, org.apache.calcite.test.DruidAdapterIT >
> testInterleaveBetweenAggregateAndGroupOrderByOnMetrics()
> java.lang.AssertionError:
> Expected: "store_state=CA; brand_name=King; A=21.4632\nstore_state=OR;
> brand_name=Symphony; A=32.176\nstore_state=CA; brand_name=Toretti;
> A=32.2465\nstore_state=WA; brand_name=King; A=34.6104\nstore_state=OR;
> brand_name=Toretti; A=36.3"
> but: was "store_state=OR; brand_name=ADJ; A=83.8764\nstore_state=WA;
> brand_name=Akron; A=85.8402\nstore_state=OR; brand_name=American;
> A=86.7898\nstore_state=WA; brand_name=ADJ; A=97.6488\nstore_state=CA;
> brand_name=ADJ; A=98.0076"
> at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:18)
> at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:6)
> at
> org.apache.calcite.test.CalciteAssert.lambda$checkResult$6(CalciteAssert.java:453)
> at
> org.apache.calcite.test.CalciteAssert.assertQuery(CalciteAssert.java:582)
> at
> org.apache.calcite.test.CalciteAssert$AssertQuery.lambda$returns$1(CalciteAssert.java:1495)
> at
> org.apache.calcite.test.CalciteAssert$AssertQuery.withConnection(CalciteAssert.java:1434)
> at
> org.apache.calcite.test.CalciteAssert$AssertQuery.returns(CalciteAssert.java:1493)
> at
> org.apache.calcite.test.CalciteAssert$AssertQuery.returns(CalciteAssert.java:1483)
> at
> org.apache.calcite.test.CalciteAssert$AssertQuery.returnsOrdered(CalciteAssert.java:1509)
> at
> org.apache.calcite.test.DruidAdapterIT.testInterleaveBetweenAggregateAndGroupOrderByOnMetrics(DruidAdapterIT.java:2336)
> Suppressed: org.apache.calcite.util.TestUtil$ExtraInformation: With
> materializationsEnabled=false, limit=-1, sql=select "store_state",
> "brand_name", "A" from (
> select sum("store_sales")-sum("store_cost") as a, "store_state",
> "brand_name"
> from "foodmart"
> group by "store_state", "brand_name" ) subq
> order by "A" limit 5
> at
> app//org.apache.calcite.util.TestUtil.rethrow(TestUtil.java:389)
> at
> app//org.apache.calcite.test.CalciteAssert.assertQuery(CalciteAssert.java:598)
> ... 6 more
> {noformat}
>
> The test is all failing after
> [https://github.com/apache/calcite/commit/55034513b463c938035e5d2436949bbf734b84b6],
> I'm not sure whether it's related.
> See following jobs:
> * [https://github.com/apache/calcite/actions/runs/6886169664/job/18731435605]
> * [https://github.com/apache/calcite/actions/runs/6885301555/job/18729238762]
> * [https://github.com/apache/calcite/actions/runs/6871630651/job/18688793776]
> * [https://github.com/apache/calcite/actions/runs/6860287671/job/18653876601]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6123) DruidAdapter2IT is failing
[
https://issues.apache.org/jira/browse/CALCITE-6123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stamatis Zampetakis updated CALCITE-6123:
-
Description:
The test that is failing is
testInterleaveBetweenAggregateAndGroupOrderByOnMetrics and the error is shown
below:
{noformat}
FAILURE 0.6sec, org.apache.calcite.test.DruidAdapterIT >
testInterleaveBetweenAggregateAndGroupOrderByOnMetrics()
java.lang.AssertionError:
Expected: "store_state=CA; brand_name=King; A=21.4632\nstore_state=OR;
brand_name=Symphony; A=32.176\nstore_state=CA; brand_name=Toretti;
A=32.2465\nstore_state=WA; brand_name=King; A=34.6104\nstore_state=OR;
brand_name=Toretti; A=36.3"
but: was "store_state=OR; brand_name=ADJ; A=83.8764\nstore_state=WA;
brand_name=Akron; A=85.8402\nstore_state=OR; brand_name=American;
A=86.7898\nstore_state=WA; brand_name=ADJ; A=97.6488\nstore_state=CA;
brand_name=ADJ; A=98.0076"
at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:18)
at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:6)
at
org.apache.calcite.test.CalciteAssert.lambda$checkResult$6(CalciteAssert.java:453)
at
org.apache.calcite.test.CalciteAssert.assertQuery(CalciteAssert.java:582)
at
org.apache.calcite.test.CalciteAssert$AssertQuery.lambda$returns$1(CalciteAssert.java:1495)
at
org.apache.calcite.test.CalciteAssert$AssertQuery.withConnection(CalciteAssert.java:1434)
at
org.apache.calcite.test.CalciteAssert$AssertQuery.returns(CalciteAssert.java:1493)
at
org.apache.calcite.test.CalciteAssert$AssertQuery.returns(CalciteAssert.java:1483)
at
org.apache.calcite.test.CalciteAssert$AssertQuery.returnsOrdered(CalciteAssert.java:1509)
at
org.apache.calcite.test.DruidAdapterIT.testInterleaveBetweenAggregateAndGroupOrderByOnMetrics(DruidAdapterIT.java:2336)
Suppressed: org.apache.calcite.util.TestUtil$ExtraInformation: With
materializationsEnabled=false, limit=-1, sql=select "store_state",
"brand_name", "A" from (
select sum("store_sales")-sum("store_cost") as a, "store_state",
"brand_name"
from "foodmart"
group by "store_state", "brand_name" ) subq
order by "A" limit 5
at app//org.apache.calcite.util.TestUtil.rethrow(TestUtil.java:389)
at
app//org.apache.calcite.test.CalciteAssert.assertQuery(CalciteAssert.java:598)
... 6 more
{noformat}
The test is all failing after
[https://github.com/apache/calcite/commit/55034513b463c938035e5d2436949bbf734b84b6],
I'm not sure whether it's related.
See following jobs:
* [https://github.com/apache/calcite/actions/runs/6886169664/job/18731435605]
* [https://github.com/apache/calcite/actions/runs/6885301555/job/18729238762]
* [https://github.com/apache/calcite/actions/runs/6871630651/job/18688793776]
* [https://github.com/apache/calcite/actions/runs/6860287671/job/18653876601]
was:
The test is all failing after
[https://github.com/apache/calcite/commit/55034513b463c938035e5d2436949bbf734b84b6],
I'm not sure whether it's related.
See following jobs:
* [https://github.com/apache/calcite/actions/runs/6886169664/job/18731435605]
* [https://github.com/apache/calcite/actions/runs/6885301555/job/18729238762]
* [https://github.com/apache/calcite/actions/runs/6871630651/job/18688793776]
* [https://github.com/apache/calcite/actions/runs/6860287671/job/18653876601]
> DruidAdapter2IT is failing
> ---
>
> Key: CALCITE-6123
> URL: https://issues.apache.org/jira/browse/CALCITE-6123
> Project: Calcite
> Issue Type: Bug
> Components: tests
>Affects Versions: 1.36.0
>Reporter: Benchao Li
>Assignee: Stamatis Zampetakis
>Priority: Major
> Labels: pull-request-available
> Attachments: image-2023-11-19-15-17-53-699.png
>
>
> The test that is failing is
> testInterleaveBetweenAggregateAndGroupOrderByOnMetrics and the error is shown
> below:
> {noformat}
> FAILURE 0.6sec, org.apache.calcite.test.DruidAdapterIT >
> testInterleaveBetweenAggregateAndGroupOrderByOnMetrics()
> java.lang.AssertionError:
> Expected: "store_state=CA; brand_name=King; A=21.4632\nstore_state=OR;
> brand_name=Symphony; A=32.176\nstore_state=CA; brand_name=Toretti;
> A=32.2465\nstore_state=WA; brand_name=King; A=34.6104\nstore_state=OR;
> brand_name=Toretti; A=36.3"
> but: was "store_state=OR; brand_name=ADJ; A=83.8764\nstore_state=WA;
> brand_name=Akron; A=85.8402\nstore_state=OR; brand_name=American;
> A=86.7898\nstore_state=WA; brand_name=ADJ; A=97.6488\nstore_state=CA;
> brand_name=ADJ; A=98.0076"
> at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:18)
> at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:6)
> at
>
[jira] [Commented] (CALCITE-6123) DruidAdapter2IT is failing
[
https://issues.apache.org/jira/browse/CALCITE-6123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17793674#comment-17793674
]
Stamatis Zampetakis commented on CALCITE-6123:
--
I can reproduce the problem consistently by performing the following steps:
* Initialize Druid and index the foodmart dataset as per instructions in
[calcite-druid-dataset|https://github.com/zabetak/calcite-druid-dataset/].
* Open [Druid's SQL query
client|http://localhost:/unified-console.html#query]
* Run the following foodmart queries in the order they appear below.
+Q1+
{code:sql}
select "store_state", "brand_name", "A"
from (
select "store_state", "brand_name", sum("store_sales") + sum("store_cost") as
A
from "foodmart"
group by "store_state", "brand_name")
order by "brand_name", "store_state"
limit 5
{code}
+RQ1+
{noformat}
"store_state","brand_name","A"
"CA","ADJ","222.1524"
"OR","ADJ","186.603597"
"WA","ADJ","216.9912"
"CA","Akron","250.349"
"OR","Akron","278.6972"
{noformat}
+Q2+
{code:sql}
select "store_state", "brand_name", "A"
from (
select "store_state", "brand_name", sum("store_sales") - sum("store_cost") as
A
from "foodmart"
group by "store_state", "brand_name")
order by "A"
limit 5
{code}
+RAQ2: results of Q2, when the latter is executed after Q1+
{noformat}
"store_state","brand_name","A"
"OR","ADJ","83.8764"
"WA","Akron","85.840198"
"OR","American","86.789799"
"WA","ADJ","97.6488"
"CA","ADJ","98.007597"
{noformat}
+RBQ2: results of Q2, when the latter is executed before Q1+
{noformat}
"store_state","brand_name","A"
"CA","King","21.4632008"
"OR","Symphony","32.1760016"
"CA","Toretti","32.246499"
"WA","King","34.6104006"
"OR","Toretti","36.3"
{noformat}
The results in RAQ2 are wrong and this result set occurs only if Q1 has run
before.
The queries above were taken from the [DruidAdapterIT
class|https://github.com/apache/calcite/blob/d3ab0bc8e4d4c9ebc0fc4e33ce478d276f5d11e4/druid/src/test/java/org/apache/calcite/test/DruidAdapterIT.java]
and in particular from the following methods:
* Q1, testInterleaveBetweenAggregateAndGroupOrderByOnDimension
* Q2, testInterleaveBetweenAggregateAndGroupOrderByOnMetrics
The problem can be reproduced also via Calcite by running the respective tests
in sequence:
{noformat}
./gradlew :druid:test --tests
DruidAdapterIT.testInterleaveBetweenAggregateAndGroupOrderByOnDimension
-Dcalcite.test.druid
./gradlew :druid:test --tests
DruidAdapterIT.testInterleaveBetweenAggregateAndGroupOrderByOnMetrics
-Dcalcite.test.druid
FAILURE 2.0sec, org.apache.calcite.test.DruidAdapterIT >
testInterleaveBetweenAggregateAndGroupOrderByOnMetrics()
java.lang.AssertionError:
Expected: "store_state=CA; brand_name=King; A=21.4632\nstore_state=OR;
brand_name=Symphony; A=32.176\nstore_state=CA; brand_name=Toretti;
A=32.2465\nstore_state=WA; brand_name=King; A=34.6104\nstore_state=OR;
brand_name=Toretti; A=36.3"
but: was "store_state=OR; brand_name=ADJ; A=83.8764\nstore_state=WA;
brand_name=Akron; A=85.8402\nstore_state=OR; brand_name=American;
A=86.7898\nstore_state=WA; brand_name=ADJ; A=97.6488\nstore_state=CA;
brand_name=ADJ; A=98.0076"
at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:18)
at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:6)
at
org.apache.calcite.test.CalciteAssert.lambda$checkResult$6(CalciteAssert.java:453)
at
org.apache.calcite.test.CalciteAssert.assertQuery(CalciteAssert.java:582)
at
org.apache.calcite.test.CalciteAssert$AssertQuery.lambda$returns$1(CalciteAssert.java:1495)
at
org.apache.calcite.test.CalciteAssert$AssertQuery.withConnection(CalciteAssert.java:1434)
at
org.apache.calcite.test.CalciteAssert$AssertQuery.returns(CalciteAssert.java:1493)
at
org.apache.calcite.test.CalciteAssert$AssertQuery.returns(CalciteAssert.java:1483)
at
org.apache.calcite.test.CalciteAssert$AssertQuery.returnsOrdered(CalciteAssert.java:1509)
at
org.apache.calcite.test.DruidAdapterIT.testInterleaveBetweenAggregateAndGroupOrderByOnMetrics(DruidAdapterIT.java:2336)
Suppressed: org.apache.calcite.util.TestUtil$ExtraInformation: With
materializationsEnabled=false, limit=-1, sql=select "store_state",
"brand_name", "A" from (
select sum("store_sales")-sum("store_cost") as a, "store_state",
"brand_name"
from "foodmart"
group by "store_state", "brand_name" ) subq
order by "A" limit 5
at org.apache.calcite.util.TestUtil.rethrow(TestUtil.java:389)
at
org.apache.calcite.test.CalciteAssert.assertQuery(CalciteAssert.java:598)
{noformat}
Druid has various level of caches for speeding up queries and some are on by
default. It turns out that the problem observed here can be avoided by
disabling the [query cache on the Historical
[jira] [Assigned] (CALCITE-6123) DruidAdapter2IT is failing
[ https://issues.apache.org/jira/browse/CALCITE-6123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stamatis Zampetakis reassigned CALCITE-6123: Assignee: Stamatis Zampetakis > DruidAdapter2IT is failing > --- > > Key: CALCITE-6123 > URL: https://issues.apache.org/jira/browse/CALCITE-6123 > Project: Calcite > Issue Type: Bug > Components: tests >Affects Versions: 1.36.0 >Reporter: Benchao Li >Assignee: Stamatis Zampetakis >Priority: Major > Labels: pull-request-available > Attachments: image-2023-11-19-15-17-53-699.png > > > The test is all failing after > [https://github.com/apache/calcite/commit/55034513b463c938035e5d2436949bbf734b84b6], > I'm not sure whether it's related. > See following jobs: > * [https://github.com/apache/calcite/actions/runs/6886169664/job/18731435605] > * [https://github.com/apache/calcite/actions/runs/6885301555/job/18729238762] > * [https://github.com/apache/calcite/actions/runs/6871630651/job/18688793776] > * [https://github.com/apache/calcite/actions/runs/6860287671/job/18653876601] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CALCITE-6123) DruidAdapter2IT is failing
[ https://issues.apache.org/jira/browse/CALCITE-6123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17792766#comment-17792766 ] Stamatis Zampetakis commented on CALCITE-6123: -- I don't think it is a JDK problem so bumping version will not help. I think its a caching issue at the Druid level and most likely the intermittent nature is affected by the order that the tests are run. It seems that it is reproducible locally so I will try to check a bit what's happening today. > DruidAdapter2IT is failing > --- > > Key: CALCITE-6123 > URL: https://issues.apache.org/jira/browse/CALCITE-6123 > Project: Calcite > Issue Type: Bug > Components: tests >Affects Versions: 1.36.0 >Reporter: Benchao Li >Priority: Major > Labels: pull-request-available > Attachments: image-2023-11-19-15-17-53-699.png > > > The test is all failing after > [https://github.com/apache/calcite/commit/55034513b463c938035e5d2436949bbf734b84b6], > I'm not sure whether it's related. > See following jobs: > * [https://github.com/apache/calcite/actions/runs/6886169664/job/18731435605] > * [https://github.com/apache/calcite/actions/runs/6885301555/job/18729238762] > * [https://github.com/apache/calcite/actions/runs/6871630651/job/18688793776] > * [https://github.com/apache/calcite/actions/runs/6860287671/job/18653876601] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CALCITE-6148) Missing ASF header from some files in source distribution
Stamatis Zampetakis created CALCITE-6148:
Summary: Missing ASF header from some files in source distribution
Key: CALCITE-6148
URL: https://issues.apache.org/jira/browse/CALCITE-6148
Project: Calcite
Issue Type: Bug
Components: avatica
Affects Versions: avatica-1.24.0
Reporter: Stamatis Zampetakis
The [ASF release
policy|https://www.apache.org/legal/src-headers.html#asf-source-header-and-copyright-notice-policy]
requires all files (with few exception) in a distribution to have an ASF
header.
During the release of Apache Calcite Avatica 1.24.0 I noticed that some files
in the source distribution do not contain an ASF header.
{code:bash}
grep -RiL "Licensed to the Apache Software Foundation (ASF)" | grep -v
"LICENSE" | grep -v "NOTICE" | grep -v "README"
{code}
{noformat}
core/src/main/resources/META-INF/services/java.sql.Driver
.gitattributes
metrics-dropwizardmetrics/src/main/resources/META-INF/services/org.apache.calcite.avatica.metrics.MetricsSystemFactory
site/favicon.ico
site/img/logo.png
site/img/feather.png
site/Gemfile.lock
site/_layouts/external.html
site/_layouts/docs.html
site/_layouts/default.html
site/_layouts/news_item.html
site/_layouts/news.html
site/_layouts/page.html
site/_sass/_style.scss
site/_sass/_pygments.scss
site/_sass/_normalize.scss
site/_sass/_gridism.scss
site/_sass/_mixins.scss
site/_sass/_font-awesome.scss
site/css/screen.scss
site/.gitignore
site/_includes/news_contents_mobile.html
site/_includes/footer.html
site/_includes/docs_contents.html
site/_includes/anchor_links.html
site/_includes/docs_contents_mobile.html
site/_includes/docs_ul.html
site/_includes/section_nav.html
site/_includes/primary-nav-items.html
site/_includes/docs_option.html
site/_includes/header.html
site/_includes/news_contents.html
site/_includes/top.html
.ratignore
noop-driver/src/main/resources/META-INF/services/java.sql.Driver
.gitignore
{noformat}
Most of the files listed above should not have an ASF header, and its normal
that they don't but we may have to enrich the LICENSE file to clarify the
licensing of some files such as .html in the site directory.
Moreover for files under META-INF/services we can check if it is possible to
add the ASF header.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6099) Missing LICENSE entry for _pygments.scss
[ https://issues.apache.org/jira/browse/CALCITE-6099?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stamatis Zampetakis updated CALCITE-6099: - Affects Version/s: avatica-1.24.0 > Missing LICENSE entry for _pygments.scss > > > Key: CALCITE-6099 > URL: https://issues.apache.org/jira/browse/CALCITE-6099 > Project: Calcite > Issue Type: Bug >Affects Versions: avatica-1.24.0, 1.36.0 >Reporter: Stamatis Zampetakis >Priority: Major > > The > [_pygment.scss|https://github.com/apache/calcite/blob/4c9011c388f826c36463ae7da875ddb525104376/site/_sass/_pygments.scss] > file is present both in git and source distribution but there is no info > about its LICENSE. > I don't know the exact provenance of the file but I found a lot of > similarities with: > [desert.css|https://github.com/StylishThemes/Syntax-Themes/blob/bfeb1da4fbbb895b9c247e0f289b0e945243e94d/pygments/css-other/desert.css]. > If that's the true origin of the file then we should examine the respective > [LICENSE|https://github.com/StylishThemes/Syntax-Themes/blob/bfeb1da4fbbb895b9c247e0f289b0e945243e94d/LICENSE] > and if necessary include it. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-6097) cobyism/gridism CSS dependency is mispelled in LICENSE
[ https://issues.apache.org/jira/browse/CALCITE-6097?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stamatis Zampetakis updated CALCITE-6097: - Affects Version/s: avatica-1.24.0 > cobyism/gridism CSS dependency is mispelled in LICENSE > -- > > Key: CALCITE-6097 > URL: https://issues.apache.org/jira/browse/CALCITE-6097 > Project: Calcite > Issue Type: Bug >Affects Versions: avatica-1.24.0, 1.36.0 >Reporter: Stamatis Zampetakis >Assignee: Stamatis Zampetakis >Priority: Major > Labels: pull-request-available > > The website uses the > [gridism.css|https://github.com/apache/calcite/blob/4c9011c388f826c36463ae7da875ddb525104376/site/_sass/_gridism.scss] > style for presentation purposes. The file is present in git and also in the > source distribution of Calcite so it should have a proper reference in the > [LICENSE|https://github.com/apache/calcite/blob/4c9011c388f826c36463ae7da875ddb525104376/LICENSE#L186] > file. > There is an entry in the LICENSE file but it is mispelled: gridsim vs gridism -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-6096) Remove obsolete html5shiv and respond entries from LICENSE
[ https://issues.apache.org/jira/browse/CALCITE-6096?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stamatis Zampetakis updated CALCITE-6096: - Affects Version/s: avatica-1.24.0 > Remove obsolete html5shiv and respond entries from LICENSE > -- > > Key: CALCITE-6096 > URL: https://issues.apache.org/jira/browse/CALCITE-6096 > Project: Calcite > Issue Type: Task > Components: build >Affects Versions: avatica-1.24.0, 1.36.0 >Reporter: Stamatis Zampetakis >Assignee: Stamatis Zampetakis >Priority: Major > Labels: pull-request-available > > The [LICENSE > file|https://github.com/apache/calcite/blob/4c9011c388f826c36463ae7da875ddb525104376/LICENSE#L184C3-L184C26] > includes the following entries: > * cobyism:html5shiv:3.7.2 > * respond:respond:1.4.2 > implying that we are bundling the respective dependencies in the project. > These dependencies correspond to minified javascript files that were removed > completely from the project [some time > ago|https://github.com/apache/calcite/commit/7f5e9b8b7e6b4afd8e4f21524aa3c4ce8b7ddb61]. > The references are obsolete and must be removed. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CALCITE-6099) Missing LICENSE entry for _pygments.scss
[
https://issues.apache.org/jira/browse/CALCITE-6099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17784221#comment-17784221
]
Stamatis Zampetakis commented on CALCITE-6099:
--
As Julian explained in CALCITE-6098, the \{{_pygment.scss}} file came from
Jekyll so we have to check in the [Jekyll
repo|https://github.com/jekyll/jekyll/tree/3f3a283018a976da11a0bfcc13a20d43d37ee29f/docs/_sass]
to see whats the appropriate LICENSE to add.
> Missing LICENSE entry for _pygments.scss
>
>
> Key: CALCITE-6099
> URL: https://issues.apache.org/jira/browse/CALCITE-6099
> Project: Calcite
> Issue Type: Bug
>Affects Versions: 1.36.0
>Reporter: Stamatis Zampetakis
>Priority: Major
>
> The
> [_pygment.scss|https://github.com/apache/calcite/blob/4c9011c388f826c36463ae7da875ddb525104376/site/_sass/_pygments.scss]
> file is present both in git and source distribution but there is no info
> about its LICENSE.
> I don't know the exact provenance of the file but I found a lot of
> similarities with:
> [desert.css|https://github.com/StylishThemes/Syntax-Themes/blob/bfeb1da4fbbb895b9c247e0f289b0e945243e94d/pygments/css-other/desert.css].
> If that's the true origin of the file then we should examine the respective
> [LICENSE|https://github.com/StylishThemes/Syntax-Themes/blob/bfeb1da4fbbb895b9c247e0f289b0e945243e94d/LICENSE]
> and if necessary include it.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-6098) Remove mentions of Jekyll from LICENSE and NOTICE files
[
https://issues.apache.org/jira/browse/CALCITE-6098?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17784220#comment-17784220
]
Stamatis Zampetakis commented on CALCITE-6098:
--
I didn't have the full context thanks for sharing Julian. I wasn't exactly sure
what were the generated files that the NOTICE was referring to. Now, I see that
all the .scss files that we have in Calcite are indeed also present in the
[Jekyll
repo|https://github.com/jekyll/jekyll/tree/3f3a283018a976da11a0bfcc13a20d43d37ee29f/docs/_sass].
I will try to see what's the appropriate LICENSE for those since it seems that
Jekyll also took them from somewhere else (at least some of them).
> Remove mentions of Jekyll from LICENSE and NOTICE files
> ---
>
> Key: CALCITE-6098
> URL: https://issues.apache.org/jira/browse/CALCITE-6098
> Project: Calcite
> Issue Type: Task
>Affects Versions: 1.36.0
>Reporter: Stamatis Zampetakis
>Assignee: Stamatis Zampetakis
>Priority: Major
> Labels: pull-request-available
>
> The NOTICE file contains the following statement:
> {noformat}
> The web site includes files generated by Jekyll.{noformat}
>
> However, there is nothing in the [LICENSE of Jekyll
> |https://github.com/jekyll/jekyll/blob/3f3a283018a976da11a0bfcc13a20d43d37ee29f/LICENSE]
> that requires such attribution.
> According to the instructions of composing the [NOTICE
> file|https://infra.apache.org/licensing-howto.html#mod-notice] for ASF
> projects we shouldn't add anything in there that is not *legally* required.
> Moreover the generated files are not necessary licensed under the same
> LICENSE with the generator.
> JavaCC, ANTLR, and lots of other source generators use a variety of licenses
> but the generated output is not licensed under the same terms. For instance,
> Calcite uses JavaCC, which is licensed under
> [BSD-3|https://github.com/javacc/javacc/blob/master/LICENSE] but both the
> grammar as well as the generated .java files are AL2.
> As long as we are not packaging bits of Jekyll in Calcite there is no need to
> add explicit mentions in LICENSE or NOTICE files.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CALCITE-6099) Missing LICENSE entry for _pygments.scss
Stamatis Zampetakis created CALCITE-6099: Summary: Missing LICENSE entry for _pygments.scss Key: CALCITE-6099 URL: https://issues.apache.org/jira/browse/CALCITE-6099 Project: Calcite Issue Type: Bug Affects Versions: 1.36.0 Reporter: Stamatis Zampetakis The [_pygment.scss|https://github.com/apache/calcite/blob/4c9011c388f826c36463ae7da875ddb525104376/site/_sass/_pygments.scss] file is present both in git and source distribution but there is no info about its LICENSE. I don't know the exact provenance of the file but I found a lot of similarities with: [desert.css|https://github.com/StylishThemes/Syntax-Themes/blob/bfeb1da4fbbb895b9c247e0f289b0e945243e94d/pygments/css-other/desert.css]. If that's the true origin of the file then we should examine the respective [LICENSE|https://github.com/StylishThemes/Syntax-Themes/blob/bfeb1da4fbbb895b9c247e0f289b0e945243e94d/LICENSE] and if necessary include it. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CALCITE-6099) Missing LICENSE entry for _pygments.scss
[ https://issues.apache.org/jira/browse/CALCITE-6099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17784055#comment-17784055 ] Stamatis Zampetakis commented on CALCITE-6099: -- If the pygments license turn out to be incompatible we should exclude it from the source distribution. > Missing LICENSE entry for _pygments.scss > > > Key: CALCITE-6099 > URL: https://issues.apache.org/jira/browse/CALCITE-6099 > Project: Calcite > Issue Type: Bug >Affects Versions: 1.36.0 >Reporter: Stamatis Zampetakis >Priority: Major > > The > [_pygment.scss|https://github.com/apache/calcite/blob/4c9011c388f826c36463ae7da875ddb525104376/site/_sass/_pygments.scss] > file is present both in git and source distribution but there is no info > about its LICENSE. > I don't know the exact provenance of the file but I found a lot of > similarities with: > [desert.css|https://github.com/StylishThemes/Syntax-Themes/blob/bfeb1da4fbbb895b9c247e0f289b0e945243e94d/pygments/css-other/desert.css]. > If that's the true origin of the file then we should examine the respective > [LICENSE|https://github.com/StylishThemes/Syntax-Themes/blob/bfeb1da4fbbb895b9c247e0f289b0e945243e94d/LICENSE] > and if necessary include it. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CALCITE-6098) Remove mentions of Jekyll from LICENSE and NOTICE files
Stamatis Zampetakis created CALCITE-6098:
Summary: Remove mentions of Jekyll from LICENSE and NOTICE files
Key: CALCITE-6098
URL: https://issues.apache.org/jira/browse/CALCITE-6098
Project: Calcite
Issue Type: Task
Affects Versions: 1.36.0
Reporter: Stamatis Zampetakis
Assignee: Stamatis Zampetakis
The NOTICE file contains the following statement:
{noformat}
The web site includes files generated by Jekyll.{noformat}
However, there is nothing in the [LICENSE of Jekyll
|https://github.com/jekyll/jekyll/blob/3f3a283018a976da11a0bfcc13a20d43d37ee29f/LICENSE]
that requires such attribution.
According to the instructions of composing the [NOTICE
file|https://infra.apache.org/licensing-howto.html#mod-notice] for ASF projects
we shouldn't add anything in there that is not *legally* required.
Moreover the generated files are not necessary licensed under the same LICENSE
with the generator.
JavaCC, ANTLR, and lots of other source generators use a variety of licenses
but the generated output is not licensed under the same terms. For instance,
Calcite uses JavaCC, which is licensed under
[BSD-3|https://github.com/javacc/javacc/blob/master/LICENSE] but both the
grammar as well as the generated .java files are AL2.
As long as we are not packaging bits of Jekyll in Calcite there is no need to
add explicit mentions in LICENSE or NOTICE files.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CALCITE-6097) cobyism/gridism CSS dependency is mispelled in LICENSE
Stamatis Zampetakis created CALCITE-6097: Summary: cobyism/gridism CSS dependency is mispelled in LICENSE Key: CALCITE-6097 URL: https://issues.apache.org/jira/browse/CALCITE-6097 Project: Calcite Issue Type: Bug Affects Versions: 1.36.0 Reporter: Stamatis Zampetakis Assignee: Stamatis Zampetakis The website uses the [gridism.css|https://github.com/apache/calcite/blob/4c9011c388f826c36463ae7da875ddb525104376/site/_sass/_gridism.scss] style for presentation purposes. The file is present in git and also in the source distribution of Calcite so it should have a proper reference in the [LICENSE|https://github.com/apache/calcite/blob/4c9011c388f826c36463ae7da875ddb525104376/LICENSE#L186] file. There is an entry in the LICENSE file but it is mispelled: gridsim vs gridism -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CALCITE-6096) Remove obsolete html5shiv and respond entries from LICENSE
Stamatis Zampetakis created CALCITE-6096: Summary: Remove obsolete html5shiv and respond entries from LICENSE Key: CALCITE-6096 URL: https://issues.apache.org/jira/browse/CALCITE-6096 Project: Calcite Issue Type: Task Components: build Affects Versions: 1.36.0 Reporter: Stamatis Zampetakis Assignee: Stamatis Zampetakis The [LICENSE file|https://github.com/apache/calcite/blob/4c9011c388f826c36463ae7da875ddb525104376/LICENSE#L184C3-L184C26] includes the following entries: * cobyism:html5shiv:3.7.2 * respond:respond:1.4.2 implying that we are bundling the respective dependencies in the project. These dependencies correspond to minified javascript files that were removed completely from the project [some time ago|https://github.com/apache/calcite/commit/7f5e9b8b7e6b4afd8e4f21524aa3c4ce8b7ddb61]. The references are obsolete and must be removed. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CALCITE-6080) The simplified form after applying AggregateReduceFunctionsRule is giving wrong results for STDDEV, Covariance with double and decimal types.
[
https://issues.apache.org/jira/browse/CALCITE-6080?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17782259#comment-17782259
]
Stamatis Zampetakis commented on CALCITE-6080:
--
STDDEV_POP is defined based on other primitive functions so from my perspective
the expanded and not expanded alternative should both return the same result no
matter which runtime is used. If the results are not the same then it looks
more like a runtime problem rather than a rule problem.
> The simplified form after applying AggregateReduceFunctionsRule is giving
> wrong results for STDDEV, Covariance with double and decimal types.
> -
>
> Key: CALCITE-6080
> URL: https://issues.apache.org/jira/browse/CALCITE-6080
> Project: Calcite
> Issue Type: Bug
>Reporter: Dayakar M
>Assignee: Dayakar M
>Priority: Major
>
> The simplified form after applying AggregateReduceFunctionsRule is giving
> wrong results for STDDEV, Covariance with double and decimal types.
> For example, after applying AggregateReduceFunctionsRule
> {noformat}
> STDDEV_POP(x) -> SQRT((SUM(x * x) - SUM(x) * SUM(x) / COUNT(x)) / COUNT(x))
> {noformat}
> for x as double/decimal, it is giving wrong result which can be easily
> reproducible with below simple java code
>
> {code:java}
> double input1 = 23.79d;
> double o1 = input1 * input1;
> System.out.println("ip*ip=" + o1);
> double sum = o1 + o1 + o1;
> System.out.println("Sum(ip*ip)="+sum); double sum1 = input1 + input1 +
> input1;
> System.out.println("Sum(ip)="+sum1);
> double sum2 = sum1 * sum1;
> System.out.println("Sum(ip)*Sum(ip)="+ sum2);
> double fin = sum2/3d;
> System.out.println("Sum(ip)*Sum(ip)/3="+fin);
> double fin1 = sum - fin;
> System.out.println("Sum(ip*ip)-Sum(ip)*Sum(ip)/3=" + fin1);
> System.out.println("SQRT((Sum(ip*ip)-Sum(ip)*Sum(ip)/3)/3)=" +
> Math.sqrt(fin1/3));{code}
> The output is
> {code:java}
> ip*ip=565.96409
> Sum(ip*ip)=1697.89228
> Sum(ip)=71.37
> Sum(ip)*Sum(ip)=5093.6769
> Sum(ip)*Sum(ip)/3=1697.89232
> Sum(ip*ip)-Sum(ip)*Sum(ip)/3=-4.547473508864641E-13
> SQRT((Sum(ip*ip)-Sum(ip)*Sum(ip)/3)/3)=NaN {code}
> The final output should be *0.0* but here it is coming as {*}NaN{*}.
> So for double and decimal type data we should not simplify STDDEV, Covariance
> functions as it leads to wrong results.
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-6080) The simplified form after applying AggregateReduceFunctionsRule is giving wrong results for STDDEV, Covariance with double and decimal types.
[
https://issues.apache.org/jira/browse/CALCITE-6080?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17781353#comment-17781353
]
Stamatis Zampetakis commented on CALCITE-6080:
--
Speaking of runtime you can also check what Calcite runtime does at the moment
regarding STDDEV_POP etc., by adding tests in [agg.iq
file|https://github.com/apache/calcite/blob/782d327d24c04e2161102b22f8880204462befd4/core/src/test/resources/sql/agg.iq#L185].
> The simplified form after applying AggregateReduceFunctionsRule is giving
> wrong results for STDDEV, Covariance with double and decimal types.
> -
>
> Key: CALCITE-6080
> URL: https://issues.apache.org/jira/browse/CALCITE-6080
> Project: Calcite
> Issue Type: Bug
>Reporter: Dayakar M
>Assignee: Dayakar M
>Priority: Major
>
> The simplified form after applying AggregateReduceFunctionsRule is giving
> wrong results for STDDEV, Covariance with double and decimal types.
> For example, after applying AggregateReduceFunctionsRule
> {noformat}
> STDDEV_POP(x) -> SQRT((SUM(x * x) - SUM(x) * SUM(x) / COUNT(x)) / COUNT(x))
> {noformat}
> for x as double/decimal, it is giving wrong result which can be easily
> reproducible with below simple java code
>
> {code:java}
> double input1 = 23.79d;
> double o1 = input1 * input1;
> System.out.println("ip*ip=" + o1);
> double sum = o1 + o1 + o1;
> System.out.println("Sum(ip*ip)="+sum); double sum1 = input1 + input1 +
> input1;
> System.out.println("Sum(ip)="+sum1);
> double sum2 = sum1 * sum1;
> System.out.println("Sum(ip)*Sum(ip)="+ sum2);
> double fin = sum2/3d;
> System.out.println("Sum(ip)*Sum(ip)/3="+fin);
> double fin1 = sum - fin;
> System.out.println("Sum(ip*ip)-Sum(ip)*Sum(ip)/3=" + fin1);
> System.out.println("SQRT((Sum(ip*ip)-Sum(ip)*Sum(ip)/3)/3)=" +
> Math.sqrt(fin1/3));{code}
> The output is
> {code:java}
> ip*ip=565.96409
> Sum(ip*ip)=1697.89228
> Sum(ip)=71.37
> Sum(ip)*Sum(ip)=5093.6769
> Sum(ip)*Sum(ip)/3=1697.89232
> Sum(ip*ip)-Sum(ip)*Sum(ip)/3=-4.547473508864641E-13
> SQRT((Sum(ip*ip)-Sum(ip)*Sum(ip)/3)/3)=NaN {code}
> The final output should be *0.0* but here it is coming as {*}NaN{*}.
> So for double and decimal type data we should not simplify STDDEV, Covariance
> functions as it leads to wrong results.
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-6080) The simplified form after applying AggregateReduceFunctionsRule is giving wrong results for STDDEV, Covariance with double and decimal types.
[
https://issues.apache.org/jira/browse/CALCITE-6080?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17781349#comment-17781349
]
Stamatis Zampetakis commented on CALCITE-6080:
--
The following equivalence is the definition of STDEV_POX(x) present in SQL
standard.
{noformat}
STDDEV_POP(x) -> SQRT((SUM(x * x) - SUM(x) * SUM(x) / COUNT(x)) / COUNT(x))
{noformat}
We cannot really say that the simplification is wrong because this is the
actual definition of the function.
The Java code in the description implies that there is some kind of problem in
the runtime (not in the rule) but the way it is right now it is hard to follow.
To showcase the problem it would be better to populate a table with columns of
different data types and and then show the result of the following queries in
various DBMS:
{code:sql}
SELECT STDDEV_POC(x) FROM ...
SELECT SQRT((SUM(x * x) - SUM(x) * SUM(x) / COUNT(x)) / COUNT(x)) FROM ...
{code}
I would expect that the results would vary from system to system since all this
strongly depend on how arithmetic operations and types are handled.
The double data type by definition is an approximate numeric so I cannot
really say if the result should be 0.0 or NaN or something else.
Moreover, the SQL standard defines that the result of VAR_POP is an
implementation defined approximate numeric so in turn SQRT(VAR_POP(X)) is as
well an approximate numeric. A specific database vendor can define what is
going to be the result in every case.
> The simplified form after applying AggregateReduceFunctionsRule is giving
> wrong results for STDDEV, Covariance with double and decimal types.
> -
>
> Key: CALCITE-6080
> URL: https://issues.apache.org/jira/browse/CALCITE-6080
> Project: Calcite
> Issue Type: Bug
>Reporter: Dayakar M
>Assignee: Dayakar M
>Priority: Major
>
> The simplified form after applying AggregateReduceFunctionsRule is giving
> wrong results for STDDEV, Covariance with double and decimal types.
> For example, after applying AggregateReduceFunctionsRule
> {noformat}
> STDDEV_POP(x) -> SQRT((SUM(x * x) - SUM(x) * SUM(x) / COUNT(x)) / COUNT(x))
> {noformat}
> for x as double/decimal, it is giving wrong result which can be easily
> reproducible with below simple java code
>
> {code:java}
> double input1 = 23.79d;
> double o1 = input1 * input1;
> System.out.println("ip*ip=" + o1);
> double sum = o1 + o1 + o1;
> System.out.println("Sum(ip*ip)="+sum); double sum1 = input1 + input1 +
> input1;
> System.out.println("Sum(ip)="+sum1);
> double sum2 = sum1 * sum1;
> System.out.println("Sum(ip)*Sum(ip)="+ sum2);
> double fin = sum2/3d;
> System.out.println("Sum(ip)*Sum(ip)/3="+fin);
> double fin1 = sum - fin;
> System.out.println("Sum(ip*ip)-Sum(ip)*Sum(ip)/3=" + fin1);
> System.out.println("SQRT((Sum(ip*ip)-Sum(ip)*Sum(ip)/3)/3)=" +
> Math.sqrt(fin1/3));{code}
> The output is
> {code:java}
> ip*ip=565.96409
> Sum(ip*ip)=1697.89228
> Sum(ip)=71.37
> Sum(ip)*Sum(ip)=5093.6769
> Sum(ip)*Sum(ip)/3=1697.89232
> Sum(ip*ip)-Sum(ip)*Sum(ip)/3=-4.547473508864641E-13
> SQRT((Sum(ip*ip)-Sum(ip)*Sum(ip)/3)/3)=NaN {code}
> The final output should be *0.0* but here it is coming as {*}NaN{*}.
> So for double and decimal type data we should not simplify STDDEV, Covariance
> functions as it leads to wrong results.
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-6078) Explicit cast to DECIMAL types do not check for overflow
[ https://issues.apache.org/jira/browse/CALCITE-6078?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17781304#comment-17781304 ] Stamatis Zampetakis commented on CALCITE-6078: -- OK I changed the relation with CALCITE-5860 for now. Note that CALCITE-5860 is also about the runtime behavior of casts and it specifically targets to renable all decimal related tests in SqlOperatorTests. > Explicit cast to DECIMAL types do not check for overflow > > > Key: CALCITE-6078 > URL: https://issues.apache.org/jira/browse/CALCITE-6078 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.35.0 >Reporter: Mihai Budiu >Priority: Minor > > This is a follow-up from [CALCITE-5990] > That issue dealt with integers and floating point. > This issue is about casts to DECIMAL in which the cast value exceeds the > scale of the target result. Apparently Calcite does not handle such casts > properly. There are multiple disabled SqlOperatorTests for this condition. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CALCITE-6078) Explicit cast to DECIMAL types do not check for overflow
[ https://issues.apache.org/jira/browse/CALCITE-6078?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17780983#comment-17780983 ] Stamatis Zampetakis commented on CALCITE-6078: -- [~mbudiu] Is this a duplicate of CALCITE-5860? > Explicit cast to DECIMAL types do not check for overflow > > > Key: CALCITE-6078 > URL: https://issues.apache.org/jira/browse/CALCITE-6078 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.35.0 >Reporter: Mihai Budiu >Priority: Minor > > This is a follow-up from [CALCITE-5990] > That issue dealt with integers and floating point. > This issue is about casts to DECIMAL in which the cast value exceeds the > scale of the target result. Apparently Calcite does not handle such casts > properly. There are multiple disabled SqlOperatorTests for this condition. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CALCITE-5860) Decimal type conversion missing scale
[
https://issues.apache.org/jira/browse/CALCITE-5860?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17780336#comment-17780336
]
Stamatis Zampetakis commented on CALCITE-5860:
--
I removed the fixVersion for now. When someone starts working on it again we
can decide in which version to put it.
> Decimal type conversion missing scale
> -
>
> Key: CALCITE-5860
> URL: https://issues.apache.org/jira/browse/CALCITE-5860
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.34.0
>Reporter: Guoliang Sun
>Assignee: pengfei.zhan
>Priority: Major
> Labels: pull-request-available
>
> Take the following SQL as an example
> {code:sql}
> SELECT CAST(((2.0) / SQRT(3.0)) AS DECIMAL(18, 0)) * SQRT(3.0) {code}
> The result of the SQL calculation should be {*}SQRT(3.0){*}.However, the
> actual result is {*}2.0{*}, which is not meet expectations.
>
> The following is the code generated by Janino
> {code:java}
> public Object[] apply(Object root0) {
> final java.math.BigDecimal literal_value = new java.math.BigDecimal(
> "2.0");
> final java.math.BigDecimal literal_value0 = new java.math.BigDecimal(
> "3.0");
> final java.math.BigDecimal literal_value1 = new java.math.BigDecimal(
> "0.5");
> final double method_name_call_value =
> org.apache.calcite.runtime.SqlFunctions.power(literal_value0, literal_value1);
> final java.math.BigDecimal cast_value = new java.math.BigDecimal(
> literal_value.doubleValue() / method_name_call_value);
> return new Object[] {
> cast_value == null ? 0.0D : cast_value.doubleValue() *
> method_name_call_value};
> } {code}
> We can see *((2.0) / SQRT(3.0)) AS DECIMAL(18, 0)* lost the scale.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-5860) Decimal type conversion missing scale
[
https://issues.apache.org/jira/browse/CALCITE-5860?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stamatis Zampetakis updated CALCITE-5860:
-
Fix Version/s: (was: 1.36.0)
> Decimal type conversion missing scale
> -
>
> Key: CALCITE-5860
> URL: https://issues.apache.org/jira/browse/CALCITE-5860
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.34.0
>Reporter: Guoliang Sun
>Assignee: pengfei.zhan
>Priority: Major
> Labels: pull-request-available
>
> Take the following SQL as an example
> {code:sql}
> SELECT CAST(((2.0) / SQRT(3.0)) AS DECIMAL(18, 0)) * SQRT(3.0) {code}
> The result of the SQL calculation should be {*}SQRT(3.0){*}.However, the
> actual result is {*}2.0{*}, which is not meet expectations.
>
> The following is the code generated by Janino
> {code:java}
> public Object[] apply(Object root0) {
> final java.math.BigDecimal literal_value = new java.math.BigDecimal(
> "2.0");
> final java.math.BigDecimal literal_value0 = new java.math.BigDecimal(
> "3.0");
> final java.math.BigDecimal literal_value1 = new java.math.BigDecimal(
> "0.5");
> final double method_name_call_value =
> org.apache.calcite.runtime.SqlFunctions.power(literal_value0, literal_value1);
> final java.math.BigDecimal cast_value = new java.math.BigDecimal(
> literal_value.doubleValue() / method_name_call_value);
> return new Object[] {
> cast_value == null ? 0.0D : cast_value.doubleValue() *
> method_name_call_value};
> } {code}
> We can see *((2.0) / SQRT(3.0)) AS DECIMAL(18, 0)* lost the scale.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (CALCITE-6011) Add the planner rule that pushes the Filter past a Window
[
https://issues.apache.org/jira/browse/CALCITE-6011?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stamatis Zampetakis resolved CALCITE-6011.
--
Resolution: Fixed
Fixed in
[bdafeec27c529d0089434a4d8b0fc7a1e49efcd1|https://github.com/apache/calcite/commit/bdafeec27c529d0089434a4d8b0fc7a1e49efcd1].
Thanks for the PR [~shenlang]!
> Add the planner rule that pushes the Filter past a Window
> -
>
> Key: CALCITE-6011
> URL: https://issues.apache.org/jira/browse/CALCITE-6011
> Project: Calcite
> Issue Type: New Feature
> Components: core
>Reporter: LakeShen
>Assignee: LakeShen
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.36.0
>
>
> The Filter condition could be pushed past the Window when condition used
> columns is window partition columns.
> For example:
> {code:java}
> SELECT
> *
> FROM
> (
> SELECT
> custkey,
> orderkey,
> rank() OVER (
> PARTITION BY custkey
> ORDER BY
> orderdate ASC
> )
> FROM
> orders
> )
> WHERE
> custkey = 0
> AND orderkey > 0 {code}
> The plan tree:
> {code:java}
> LogicalProject(custkey=[0], orderkey=[$1], EXPR$2=[$2])
> LogicalFilter(condition=[AND(=($0, 0), >($1, 0))])
> LogicalProject(custkey=[$1], orderkey=[$0], EXPR$2=[$3])
> LogicalWindow(window#0=[window(partition {1} order by [2] aggs
> [RANK()])])
> LogicalProject(ORDERKEY=[$0], CUSTKEY=[$1], ORDERDATE=[$4])
> LogicalTableScan(table=[[tpch, ORDERS]]) {code}
> Because the window partition columns is custkey,so the condition `custkey = 0
> ` could be pushed down the LogicalWindow.
> After that,the plan is :
> {code:java}
>
> LogicalProject(custkey=[0], orderkey=[$1], EXPR$2=[$2])
> LogicalFilter(condition=[>($1, 0)])
> LogicalProject(custkey=[$1], orderkey=[$0], EXPR$2=[$3])
> LogicalWindow(window#0=[window(partition {1} order by [2] aggs
> [RANK()])])
> LogicalFilter(condition=[=($1, 0)])
> LogicalProject(ORDERKEY=[$0], CUSTKEY=[$1], ORDERDATE=[$4])
> LogicalTableScan(table=[[tpch, ORDERS]])
> {code}
>
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-6075) Site: Cloning source code from GitHub using git protocol fails
[ https://issues.apache.org/jira/browse/CALCITE-6075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17780282#comment-17780282 ] Stamatis Zampetakis commented on CALCITE-6075: -- Merged addendum for howto.md in [ef82a6cc6bc565f6dc596c1d2aca7221fd6cdc49|https://github.com/apache/calcite/commit/ef82a6cc6bc565f6dc596c1d2aca7221fd6cdc49]. Thanks for the follow-up [~caicancai]. I don't think we need to do something for the references of "git:" in build.gradle.kts since they refer to protocols used by gitbox (not github). > Site: Cloning source code from GitHub using git protocol fails > --- > > Key: CALCITE-6075 > URL: https://issues.apache.org/jira/browse/CALCITE-6075 > Project: Calcite > Issue Type: Improvement > Components: site >Affects Versions: 1.35.0 >Reporter: 蔡灿材 >Assignee: 蔡灿材 >Priority: Minor > Labels: pull-request-available > Fix For: 1.36.0 > > Attachments: 2023-10-26 16-28-15屏幕截图.png > > > git clone git://github.com/apache/calcite.git does not have this writing > method. It should be [https://github.com/apache/calcite.git] or > g...@github.com:apache/calcite.git > GitHub removed the unecrypted git protocol a while ago: > [https://github.blog/changelog/2022-03-15-removed-unencrypted-git-protocol-and-certain-ssh-keys/] > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (CALCITE-6075) Site: Cloning source code from GitHub using git protocol fails
[ https://issues.apache.org/jira/browse/CALCITE-6075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17779833#comment-17779833 ] Stamatis Zampetakis edited comment on CALCITE-6075 at 10/27/23 9:18 AM: Fixed in [https://github.com/apache/calcite/commit/8821eaf94b08dd5c55074b900201da7c386c1635]. Thanks [~caicancai] for the contribution and [~taoran] for the review! was (Author: zabetak): Fixed in [https://github.com/apache/calcite/commit/8821eaf94b08dd5c55074b900201da7c386c1635.] Thanks [~caicancai] for the contribution and [~taoran] for the review! > Site: Cloning source code from GitHub using git protocol fails > --- > > Key: CALCITE-6075 > URL: https://issues.apache.org/jira/browse/CALCITE-6075 > Project: Calcite > Issue Type: Improvement > Components: site >Affects Versions: 1.35.0 >Reporter: 蔡灿材 >Assignee: 蔡灿材 >Priority: Minor > Labels: pull-request-available > Fix For: 1.36.0 > > Attachments: 2023-10-26 16-28-15屏幕截图.png > > > git clone git://github.com/apache/calcite.git does not have this writing > method. It should be [https://github.com/apache/calcite.git] or > g...@github.com:apache/calcite.git > GitHub removed the unecrypted git protocol a while ago: > [https://github.blog/changelog/2022-03-15-removed-unencrypted-git-protocol-and-certain-ssh-keys/] > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (CALCITE-6075) Site: Cloning source code from GitHub using git protocol fails
[ https://issues.apache.org/jira/browse/CALCITE-6075?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stamatis Zampetakis reassigned CALCITE-6075: Assignee: 蔡灿材 > Site: Cloning source code from GitHub using git protocol fails > --- > > Key: CALCITE-6075 > URL: https://issues.apache.org/jira/browse/CALCITE-6075 > Project: Calcite > Issue Type: Improvement > Components: site >Affects Versions: 1.35.0 >Reporter: 蔡灿材 >Assignee: 蔡灿材 >Priority: Minor > Labels: pull-request-available > Fix For: 1.36.0 > > Attachments: 2023-10-26 16-28-15屏幕截图.png > > > git clone git://github.com/apache/calcite.git does not have this writing > method. It should be [https://github.com/apache/calcite.git] or > g...@github.com:apache/calcite.git > GitHub removed the unecrypted git protocol a while ago: > [https://github.blog/changelog/2022-03-15-removed-unencrypted-git-protocol-and-certain-ssh-keys/] > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CALCITE-6075) Site: Cloning source code from GitHub using git protocol fails
[ https://issues.apache.org/jira/browse/CALCITE-6075?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stamatis Zampetakis resolved CALCITE-6075. -- Fix Version/s: 1.36.0 (was: 1.35.0) Resolution: Fixed Fixed in [https://github.com/apache/calcite/commit/8821eaf94b08dd5c55074b900201da7c386c1635.] Thanks [~caicancai] for the contribution and [~taoran] for the review! > Site: Cloning source code from GitHub using git protocol fails > --- > > Key: CALCITE-6075 > URL: https://issues.apache.org/jira/browse/CALCITE-6075 > Project: Calcite > Issue Type: Improvement > Components: site >Affects Versions: 1.35.0 >Reporter: 蔡灿材 >Priority: Minor > Labels: pull-request-available > Fix For: 1.36.0 > > Attachments: 2023-10-26 16-28-15屏幕截图.png > > > git clone git://github.com/apache/calcite.git does not have this writing > method. It should be [https://github.com/apache/calcite.git] or > g...@github.com:apache/calcite.git > GitHub removed the unecrypted git protocol a while ago: > [https://github.blog/changelog/2022-03-15-removed-unencrypted-git-protocol-and-certain-ssh-keys/] > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-6075) Site: Cloning source code from GitHub using git protocol fails
[ https://issues.apache.org/jira/browse/CALCITE-6075?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stamatis Zampetakis updated CALCITE-6075: - Description: git clone git://github.com/apache/calcite.git does not have this writing method. It should be [https://github.com/apache/calcite.git] or g...@github.com:apache/calcite.git GitHub removed the unecrypted git protocol a while ago: [https://github.blog/changelog/2022-03-15-removed-unencrypted-git-protocol-and-certain-ssh-keys/] was: git clone git://github.com/apache/calcite.git does not have this writing method. It should be https://github.com/apache/calcite.git or g...@github.com:apache/calcite.git > Site: Cloning source code from GitHub using git protocol fails > --- > > Key: CALCITE-6075 > URL: https://issues.apache.org/jira/browse/CALCITE-6075 > Project: Calcite > Issue Type: Improvement > Components: site >Affects Versions: 1.35.0 >Reporter: 蔡灿材 >Priority: Minor > Labels: pull-request-available > Fix For: 1.35.0 > > Attachments: 2023-10-26 16-28-15屏幕截图.png > > > git clone git://github.com/apache/calcite.git does not have this writing > method. It should be [https://github.com/apache/calcite.git] or > g...@github.com:apache/calcite.git > GitHub removed the unecrypted git protocol a while ago: > [https://github.blog/changelog/2022-03-15-removed-unencrypted-git-protocol-and-certain-ssh-keys/] > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-6075) Site: Cloning source code from GitHub using git protocol fails
[ https://issues.apache.org/jira/browse/CALCITE-6075?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stamatis Zampetakis updated CALCITE-6075: - Summary: Site: Cloning source code from GitHub using git protocol fails (was: The git link to download the source code is incorrect) > Site: Cloning source code from GitHub using git protocol fails > --- > > Key: CALCITE-6075 > URL: https://issues.apache.org/jira/browse/CALCITE-6075 > Project: Calcite > Issue Type: Improvement > Components: site >Affects Versions: 1.35.0 >Reporter: 蔡灿材 >Priority: Minor > Labels: pull-request-available > Fix For: 1.35.0 > > Attachments: 2023-10-26 16-28-15屏幕截图.png > > > > git clone git://github.com/apache/calcite.git does not have this writing > method. It should be https://github.com/apache/calcite.git or > g...@github.com:apache/calcite.git -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CALCITE-6053) Upgrade Calcite to Avatica 1.24.0
[ https://issues.apache.org/jira/browse/CALCITE-6053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17776556#comment-17776556 ] Stamatis Zampetakis commented on CALCITE-6053: -- When the upgrade happens there are going to be some test failures in SqlOperatorTest (CALCITE-5923) highlighting the part of the code that needs to be updated. We left some comments to aid the cleanup. > Upgrade Calcite to Avatica 1.24.0 > - > > Key: CALCITE-6053 > URL: https://issues.apache.org/jira/browse/CALCITE-6053 > Project: Calcite > Issue Type: Task >Reporter: Stamatis Zampetakis >Priority: Major > > Upgrade Calcite to Avatica 1.24.0 when it becomes available. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CALCITE-5923) SqlOperatorTest using safeParameters are not using overridable fixture
[ https://issues.apache.org/jira/browse/CALCITE-5923?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stamatis Zampetakis resolved CALCITE-5923. -- Resolution: Fixed Fixed in [https://github.com/apache/calcite/commit/f996bc9993546019d0fd475b2daa99ac8b1b9259.] Thanks for the PR [~Runking] ! Once we upgrade Avatica to 1.24.0 (CALCITE-6053) some test cases will fail (intentionally) and we will need to perform the necessary cleanup. > SqlOperatorTest using safeParameters are not using overridable fixture > -- > > Key: CALCITE-5923 > URL: https://issues.apache.org/jira/browse/CALCITE-5923 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.35.0 >Reporter: Runkang He >Assignee: Runkang He >Priority: Minor > Labels: pull-request-available > Fix For: 1.36.0 > > > There are some test cases in `SqlOperatorTest` directly use the > `SqlOperatorFixtureImpl.DEFAULT` to get the `SqlOperatorFixture`, including > `SqlOperatorTest.testCast` and many other test cases related with `CAST` > operator. This causes that the result check is missing when execute > `CalciteSqlOperatorTest`, which should has result check. > This violates the design principle introduced by CALCITE-4885, which we > should alway use `SqlOperatorTest.fixture()` to get the `SqlOperatorFixture`. > This principle allows us to override`fixture()` method in subclasses to run > tests in a different environment. > So I think we should fix these related test cases to keep consistent with the > principle. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-5923) SqlOperatorTest using safeParameters are not using overridable fixture
[ https://issues.apache.org/jira/browse/CALCITE-5923?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stamatis Zampetakis updated CALCITE-5923: - Summary: SqlOperatorTest using safeParameters are not using overridable fixture (was: Some test cases in `SqlOperatorTest` violates the test fixture's design principle) > SqlOperatorTest using safeParameters are not using overridable fixture > -- > > Key: CALCITE-5923 > URL: https://issues.apache.org/jira/browse/CALCITE-5923 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.35.0 >Reporter: Runkang He >Assignee: Runkang He >Priority: Minor > Labels: pull-request-available > Fix For: 1.36.0 > > > There are some test cases in `SqlOperatorTest` directly use the > `SqlOperatorFixtureImpl.DEFAULT` to get the `SqlOperatorFixture`, including > `SqlOperatorTest.testCast` and many other test cases related with `CAST` > operator. This causes that the result check is missing when execute > `CalciteSqlOperatorTest`, which should has result check. > This violates the design principle introduced by CALCITE-4885, which we > should alway use `SqlOperatorTest.fixture()` to get the `SqlOperatorFixture`. > This principle allows us to override`fixture()` method in subclasses to run > tests in a different environment. > So I think we should fix these related test cases to keep consistent with the > principle. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CALCITE-6053) Upgrade Calcite to Avatica 1.24.0
Stamatis Zampetakis created CALCITE-6053: Summary: Upgrade Calcite to Avatica 1.24.0 Key: CALCITE-6053 URL: https://issues.apache.org/jira/browse/CALCITE-6053 Project: Calcite Issue Type: Task Reporter: Stamatis Zampetakis Upgrade Calcite to Avatica 1.24.0 when it becomes available. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CALCITE-6048) 'CIRCULAR REFERENCE' exception is throwed in ServerTest#testTruncateTable method
[
https://issues.apache.org/jira/browse/CALCITE-6048?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17774456#comment-17774456
]
Stamatis Zampetakis commented on CALCITE-6048:
--
This is a potential duplicate of CALCITE-5868 and CALCITE-4824.
There have been multi-threading issues in the server module for a long time now:
https://lists.apache.org/thread/7wo73pwz7fk6xq610s3bt2gz1xowyqxx
> 'CIRCULAR REFERENCE' exception is throwed in ServerTest#testTruncateTable
> method
>
>
> Key: CALCITE-6048
> URL: https://issues.apache.org/jira/browse/CALCITE-6048
> Project: Calcite
> Issue Type: Bug
>Reporter: LakeShen
>Priority: Major
> Attachments: image-2023-10-12-19-24-44-297.png
>
>
> When I submit my pr,and there is a pipeline job's exception,the exception
> stack is :
> {code:java}
> java.sql.SQLException: Error while executing SQL "create table t (i 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:164)
> at
> org.apache.calcite.avatica.AvaticaStatement.execute(AvaticaStatement.java:218)
> at
> org.apache.calcite.test.ServerTest.testTruncateTable(ServerTest.java:283)
> Next exception 1: [CIRCULAR REFERENCE SQLException]
> Next exception 2: 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:565)
> at
> org.apache.calcite.util.ReflectUtil$2.invoke(ReflectUtil.java:529)
> at
> org.apache.calcite.server.DdlExecutorImpl.executeDdl(DdlExecutorImpl.java:41)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl.executeDdl(CalcitePrepareImpl.java:372)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl.prepare2_(CalcitePrepareImpl.java:653)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl.prepare_(CalcitePrepareImpl.java:519)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl.prepareSql(CalcitePrepareImpl.java:487)
> at
> org.apache.calcite.jdbc.CalciteConnectionImpl.parseQuery(CalciteConnectionImpl.java:236)
> at
> org.apache.calcite.jdbc.CalciteMetaImpl.prepareAndExecute(CalciteMetaImpl.java:702)
> at
> org.apache.calcite.avatica.AvaticaConnection.prepareAndExecuteInternal(AvaticaConnection.java:677)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:157)
> ... 2 more
> Caused by: [CIRCULAR REFERENCE IllegalArgumentException] {code}
> The complete exception could see:
> !image-2023-10-12-19-24-44-297.png|width=1222,height=559!
> This looks like a multithreading Bug, but I'm not sure.
> The pipeline job
> link:https://ci-builds.apache.org/blue/organizations/jenkins/Calcite%2FCalcite-sonar/detail/PR-3465/1/pipeline/
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-129) Support recursive WITH queries
[ https://issues.apache.org/jira/browse/CALCITE-129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17773608#comment-17773608 ] Stamatis Zampetakis commented on CALCITE-129: - [~hanu.ncr] Sure feel free to pick this up. When there is no assignee you can take it on without asking ;) The WITH [RECURSIVE] syntax is part of SQL standard so it is a good idea to stick with it. I don't know what else is mandated by the standard but since you are going to work on it makes sense to have a look and try to stay close to it. Good luck and looking forward for this contribution. > Support recursive WITH queries > -- > > Key: CALCITE-129 > URL: https://issues.apache.org/jira/browse/CALCITE-129 > Project: Calcite > Issue Type: Improvement >Reporter: GitHub Import >Priority: Major > Labels: github-import > > Building on https://github.com/julianhyde/optiq/issues/128, enable the > RECURSIVE keyword. > This feature allows relations to be computed iteratively. Whereas > ([#128|https://github.com/JulianHyde/optiq/issues/128] | > [FLINK-128|https://issues.apache.org/jira/browse/OPTIQ-128]) was mainly a > parser/validator change, this feature requires significant changes to the > planner and runtime. > Imported from GitHub > Url: https://github.com/julianhyde/optiq/issues/129 > Created by: [julianhyde|https://github.com/julianhyde] > Labels: enhancement, > Created at: Tue Feb 11 20:29:35 CET 2014 > State: open -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CALCITE-5957) Valid DATE '1945-2-2' is not accepted due to regression
[ https://issues.apache.org/jira/browse/CALCITE-5957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17771389#comment-17771389 ] Stamatis Zampetakis commented on CALCITE-5957: -- Based on the current discussion under https://lists.apache.org/thread/fvh4nfbm9mvt9dfpo6o8nq37q6mmgqh0 there is no strong desire to restore the old behavior so let's leave this ticket open for now and consider that the expected and correct behavior from now on is the one introduced by CALCITE-5678. > Valid DATE '1945-2-2' is not accepted due to regression > --- > > Key: CALCITE-5957 > URL: https://issues.apache.org/jira/browse/CALCITE-5957 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.35.0 >Reporter: Runkang He >Assignee: Runkang He >Priority: Blocker > Labels: pull-request-available > Fix For: avatica-1.24.0 > > Attachments: image-2023-08-27-19-09-33-284.png > > Time Spent: 0.5h > Remaining Estimate: 0h > > DATE '1945-2-2' is a valid date. In CALCITE-5923 when we turn on the result > check of `testCastStringToDateTime`, we find that Calcite accepted DATE > '1945-2-2' before CALCITE-5678 but not afterwards, so this is a regression > that we need to fix. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CALCITE-6029) SqlOperatorTest cannot test operators that require the Babel parser
[
https://issues.apache.org/jira/browse/CALCITE-6029?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17769953#comment-17769953
]
Stamatis Zampetakis commented on CALCITE-6029:
--
Left some comments under the PR. Overall, I am not sure if it is desired to
have non-standard (Babel) operators be part of the SqlOperatorTest that is
meant to be extended and used in downstream projects. Also it may lead to
duplication as we have other specialized tests for Babel (i.e., BabelTest,
BabelParserTest).
> SqlOperatorTest cannot test operators that require the Babel parser
> ---
>
> Key: CALCITE-6029
> URL: https://issues.apache.org/jira/browse/CALCITE-6029
> Project: Calcite
> Issue Type: Bug
> Components: babel, core
>Affects Versions: 1.35.0
>Reporter: Mihai Budiu
>Priority: Minor
> Labels: pull-request-available
>
> In SqlOperatorTest one can write code like this:
> {code:java}
> @Test void testDatePart() {
> final SqlOperatorFixture f = fixture().withLibrary(SqlLibrary.POSTGRESQL)
> .withParserConfig(p ->
> p.withParserFactory(SqlBabelParserImpl.FACTORY));
> {code}
> This almost works, but the SqlOperatorTest.check function makes a connection
> ignores the parserFactory, so parsing will fail:
> {code:java}
> @Override public void check(SqlTestFactory factory, String query,
> SqlTester.TypeChecker typeChecker,
> SqlTester.ParameterChecker parameterChecker,
> SqlTester.ResultChecker resultChecker) {
> super.check(factory, query, typeChecker, parameterChecker,
> resultChecker);
> final RelDataTypeSystem typeSystem =
> factory.typeSystemTransform.apply(RelDataTypeSystem.DEFAULT);
> final ConnectionFactory connectionFactory =
> factory.connectionFactory
> .with(CalciteConnectionProperty.TYPE_SYSTEM, uri(FIELD)); ///
> NO PARSER_FACTORY HERE
> {code}
> I am trying to fix this by adding a PARSER_FACTORY argument to the
> connection, but then I get a class loader error from
> AvaticaUtils.instantiatePlugin, which, in this case, cannot find the
> SqlBabelParserImpl#FACTORY in the classpath.
> I would appreciate some help solving this last bit.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-6020) SqlToRelConverter should not replace windowed SUM with equivalent expression using SUM0
[
https://issues.apache.org/jira/browse/CALCITE-6020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17769545#comment-17769545
]
Stamatis Zampetakis commented on CALCITE-6020:
--
The code would be more modular if the SqlToRelConverter didn't perform directly
optimizations/simplifications since that gives more flexibility to the users. I
like the approach of having this in other places such as rules (e.g.,
[AggregateReduceFunctionsRule|https://github.com/apache/calcite/blob/aef9bdb5c091e4df84eeb47a9aa70770dd3d3fb8/core/src/main/java/org/apache/calcite/rel/rules/AggregateReduceFunctionsRule.java]),
convertlets (e.g.,
[SqlRexConvertletTable|https://github.com/apache/calcite/blob/aef9bdb5c091e4df84eeb47a9aa70770dd3d3fb8/core/src/main/java/org/apache/calcite/sql2rel/SqlRexConvertletTable.java]),
etc. Maybe we could extract this reduction to another place as well.
SUM vs SUM0 has been a debatable topic lately so I am in favor of options that
make this decision configurable/modular.
> SqlToRelConverter should not replace windowed SUM with equivalent expression
> using SUM0
> ---
>
> Key: CALCITE-6020
> URL: https://issues.apache.org/jira/browse/CALCITE-6020
> Project: Calcite
> Issue Type: Improvement
>Reporter: Zoltan Haindrich
>Assignee: Zoltan Haindrich
>Priority: Major
> Labels: pull-request-available
>
> {{SqlToRelConverter}} replaces {{SUM}} with {{SUM0}} around
> [here|https://github.com/apache/calcite/blob/e1991e08a225ef08c2402ab35c310d88fff3c222/core/src/main/java/org/apache/calcite/sql2rel/SqlToRelConverter.java#L5885]
> This might have been needed at some point in the past - but I think it will
> be better to leave it as {{SUM}} - as in case there is no {{SUM0}} in the
> system that will be replaced with a {{COALESCE(SUM(...) , 0 )}} to provide it
> - as see
> [here|https://github.com/apache/calcite/blob/e1991e08a225ef08c2402ab35c310d88fff3c222/core/src/test/java/org/apache/calcite/rel/rel2sql/RelToSqlConverterTest.java#L1288]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-5957) Valid DATE '1945-2-2' is not accepted due to regression
[ https://issues.apache.org/jira/browse/CALCITE-5957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17768285#comment-17768285 ] Stamatis Zampetakis commented on CALCITE-5957: -- This is a tricky situation cause if we admit that CALCITE-5678 aims to enforce SQL standard compatibility then there is nothing to do here. If we decide to enforce strict pattern with no optional zeros that's fine with me. However, we need to converge soon cause this is blocking various other tickets and potentially a subsequent release. > Valid DATE '1945-2-2' is not accepted due to regression > --- > > Key: CALCITE-5957 > URL: https://issues.apache.org/jira/browse/CALCITE-5957 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.35.0 >Reporter: Runkang He >Priority: Blocker > Fix For: avatica-1.24.0 > > Attachments: image-2023-08-27-19-09-33-284.png > > Time Spent: 10m > Remaining Estimate: 0h > > DATE '1945-2-2' is a valid date. In CALCITE-5923 when we turn on the result > check of `testCastStringToDateTime`, we find that Calcite accepted DATE > '1945-2-2' before CALCITE-5678 but not afterwards, so this is a regression > that we need to fix. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CALCITE-5957) Valid DATE '1945-2-2' is not accepted due to regression
[ https://issues.apache.org/jira/browse/CALCITE-5957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17767195#comment-17767195 ] Stamatis Zampetakis commented on CALCITE-5957: -- As far as I see the consensus is to make leading zeros everywhere (including the year field) optional so '900-01-01' should be accepted as a valid date. From my perspective that's the only thing missing for merging this PR. [~zstan] Are you planning to update the PR or you prefer someone else to take over? Since '2023-01-01 22:00:00.123.123' is not a regression of CALCITE-5678, I am fine postponing the validity decision in another ticket. From my experience users are not very happy when parsers become stricter. I know of many users would be pretty happy to have 2023-01-01 22:00:00.123 extracted out of '2023-01-01 22:00:00.123.123' instead of a getting a null or an error. > Valid DATE '1945-2-2' is not accepted due to regression > --- > > Key: CALCITE-5957 > URL: https://issues.apache.org/jira/browse/CALCITE-5957 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.35.0 >Reporter: Runkang He >Priority: Blocker > Fix For: avatica-1.24.0 > > Attachments: image-2023-08-27-19-09-33-284.png > > Time Spent: 10m > Remaining Estimate: 0h > > DATE '1945-2-2' is a valid date. In CALCITE-5923 when we turn on the result > check of `testCastStringToDateTime`, we find that Calcite accepted DATE > '1945-2-2' before CALCITE-5678 but not afterwards, so this is a regression > that we need to fix. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CALCITE-5957) Valid DATE '1945-2-2' is not accepted due to regression
[ https://issues.apache.org/jira/browse/CALCITE-5957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17766725#comment-17766725 ] Stamatis Zampetakis commented on CALCITE-5957: -- The SQL standard 2011 Section 5.3 (Syntax Rules) defines the following: 31) Within a , the shall contain four digits. The and other datetime components, with the exception of , shall each contain two digits. 32) Within the definition of a , the s are constrained by the natural rules for dates and times according to the Gregorian calendar. However, we already started deviating from the strict standard definition so I am not sure why we should allow single digit integers for everything (months, days, hours, minutes, seconds) but not for years; this seems inconsistent. Personally, I prefer the strict format but this is completely subjective and people have different opinions on the topic so I am willing to follow the majority. Nevertheless, we should clarify if the date "900-01-01" was valid before the changes in CALCITE-5678 or not. [~zstan] Also please comment about "2023-01-01 22:00:00.123.123". Was it valid before CALCITE-5678? Should we accept it now? > Valid DATE '1945-2-2' is not accepted due to regression > --- > > Key: CALCITE-5957 > URL: https://issues.apache.org/jira/browse/CALCITE-5957 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.35.0 >Reporter: Runkang He >Assignee: Evgeny Stanilovsky >Priority: Blocker > Labels: pull-request-available > Fix For: avatica-1.24.0 > > Attachments: image-2023-08-27-19-09-33-284.png > > Time Spent: 10m > Remaining Estimate: 0h > > DATE '1945-2-2' is a valid date. In CALCITE-5923 when we turn on the result > check of `testCastStringToDateTime`, we find that Calcite accepted DATE > '1945-2-2' before CALCITE-5678 but not afterwards, so this is a regression > that we need to fix. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CALCITE-5860) Decimal type conversion missing scale
[
https://issues.apache.org/jira/browse/CALCITE-5860?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17764208#comment-17764208
]
Stamatis Zampetakis commented on CALCITE-5860:
--
[~pfzhan] Based on the discussion in CALCITE-5901 and [the respective
thread|https://lists.apache.org/thread/2xqsl61w4r98jjqhjbnc0ybx4f4v1b0s] in the
dev list it seems valid to have scale > precision so the respective changes
should be reverted from the PR. Let's not bother with such cases as part of
this change.
> Decimal type conversion missing scale
> -
>
> Key: CALCITE-5860
> URL: https://issues.apache.org/jira/browse/CALCITE-5860
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.34.0
>Reporter: Guoliang Sun
>Assignee: pengfei.zhan
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.36.0
>
>
> Take the following SQL as an example
> {code:sql}
> SELECT CAST(((2.0) / SQRT(3.0)) AS DECIMAL(18, 0)) * SQRT(3.0) {code}
> The result of the SQL calculation should be {*}SQRT(3.0){*}.However, the
> actual result is {*}2.0{*}, which is not meet expectations.
>
> The following is the code generated by Janino
> {code:java}
> public Object[] apply(Object root0) {
> final java.math.BigDecimal literal_value = new java.math.BigDecimal(
> "2.0");
> final java.math.BigDecimal literal_value0 = new java.math.BigDecimal(
> "3.0");
> final java.math.BigDecimal literal_value1 = new java.math.BigDecimal(
> "0.5");
> final double method_name_call_value =
> org.apache.calcite.runtime.SqlFunctions.power(literal_value0, literal_value1);
> final java.math.BigDecimal cast_value = new java.math.BigDecimal(
> literal_value.doubleValue() / method_name_call_value);
> return new Object[] {
> cast_value == null ? 0.0D : cast_value.doubleValue() *
> method_name_call_value};
> } {code}
> We can see *((2.0) / SQRT(3.0)) AS DECIMAL(18, 0)* lost the scale.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-5957) Valid DATE '1945-2-2' is not accepted due to regression
[ https://issues.apache.org/jira/browse/CALCITE-5957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17764190#comment-17764190 ] Stamatis Zampetakis commented on CALCITE-5957: -- Are the following literals valid dates/timestamps or not? * "900-01-01 00:00:00" Fails in the current PR * "2023-01-01 22:00:00.123.123" Passes in the current PR Were they valid/invalid before CALCITE-5678? > Valid DATE '1945-2-2' is not accepted due to regression > --- > > Key: CALCITE-5957 > URL: https://issues.apache.org/jira/browse/CALCITE-5957 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.35.0 >Reporter: Runkang He >Assignee: Evgeny Stanilovsky >Priority: Blocker > Labels: pull-request-available > Fix For: avatica-1.24.0 > > Attachments: image-2023-08-27-19-09-33-284.png > > Time Spent: 10m > Remaining Estimate: 0h > > DATE '1945-2-2' is a valid date. In CALCITE-5923 when we turn on the result > check of `testCastStringToDateTime`, we find that Calcite accepted DATE > '1945-2-2' before CALCITE-5678 but not afterwards, so this is a regression > that we need to fix. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-5957) Valid DATE '1945-2-2' is not accepted due to regression
[ https://issues.apache.org/jira/browse/CALCITE-5957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stamatis Zampetakis updated CALCITE-5957: - Fix Version/s: avatica-1.24.0 > Valid DATE '1945-2-2' is not accepted due to regression > --- > > Key: CALCITE-5957 > URL: https://issues.apache.org/jira/browse/CALCITE-5957 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.35.0 >Reporter: Runkang He >Assignee: Evgeny Stanilovsky >Priority: Blocker > Labels: pull-request-available > Fix For: avatica-1.24.0 > > Attachments: image-2023-08-27-19-09-33-284.png > > Time Spent: 10m > Remaining Estimate: 0h > > DATE '1945-2-2' is a valid date. In CALCITE-5923 when we turn on the result > check of `testCastStringToDateTime`, we find that Calcite accepted DATE > '1945-2-2' before CALCITE-5678 but not afterwards, so this is a regression > that we need to fix. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-5957) Valid DATE '1945-2-2' is not accepted due to regression
[ https://issues.apache.org/jira/browse/CALCITE-5957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stamatis Zampetakis updated CALCITE-5957: - Priority: Blocker (was: Major) > Valid DATE '1945-2-2' is not accepted due to regression > --- > > Key: CALCITE-5957 > URL: https://issues.apache.org/jira/browse/CALCITE-5957 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.35.0 >Reporter: Runkang He >Assignee: Evgeny Stanilovsky >Priority: Blocker > Labels: pull-request-available > Attachments: image-2023-08-27-19-09-33-284.png > > Time Spent: 10m > Remaining Estimate: 0h > > DATE '1945-2-2' is a valid date. In CALCITE-5923 when we turn on the result > check of `testCastStringToDateTime`, we find that Calcite accepted DATE > '1945-2-2' before CALCITE-5678 but not afterwards, so this is a regression > that we need to fix. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CALCITE-5860) Decimal type conversion missing scale
[
https://issues.apache.org/jira/browse/CALCITE-5860?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17762063#comment-17762063
]
Stamatis Zampetakis commented on CALCITE-5860:
--
Hey [~pfzhan], I left some additional comments in the PR roughly 2 weeks ago.
Did you have a chance to look into them?
> Decimal type conversion missing scale
> -
>
> Key: CALCITE-5860
> URL: https://issues.apache.org/jira/browse/CALCITE-5860
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.34.0
>Reporter: Guoliang Sun
>Assignee: pengfei.zhan
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.36.0
>
>
> Take the following SQL as an example
> {code:sql}
> SELECT CAST(((2.0) / SQRT(3.0)) AS DECIMAL(18, 0)) * SQRT(3.0) {code}
> The result of the SQL calculation should be {*}SQRT(3.0){*}.However, the
> actual result is {*}2.0{*}, which is not meet expectations.
>
> The following is the code generated by Janino
> {code:java}
> public Object[] apply(Object root0) {
> final java.math.BigDecimal literal_value = new java.math.BigDecimal(
> "2.0");
> final java.math.BigDecimal literal_value0 = new java.math.BigDecimal(
> "3.0");
> final java.math.BigDecimal literal_value1 = new java.math.BigDecimal(
> "0.5");
> final double method_name_call_value =
> org.apache.calcite.runtime.SqlFunctions.power(literal_value0, literal_value1);
> final java.math.BigDecimal cast_value = new java.math.BigDecimal(
> literal_value.doubleValue() / method_name_call_value);
> return new Object[] {
> cast_value == null ? 0.0D : cast_value.doubleValue() *
> method_name_call_value};
> } {code}
> We can see *((2.0) / SQRT(3.0)) AS DECIMAL(18, 0)* lost the scale.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (CALCITE-5615) Run SQL Logic Test suite using Calcite's HSQLDB JDBC adapter
[
https://issues.apache.org/jira/browse/CALCITE-5615?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stamatis Zampetakis resolved CALCITE-5615.
--
Resolution: Fixed
Fixed in
https://github.com/apache/calcite/commit/996692e36a0d1bdff2b3fd1e08fa99fcc755f2ab.
Thanks for huge amount of work that you put into this ticket [~mbudiu] and
[~julianhyde] and of course for building up the
https://github.com/hydromatic/sql-logic-test repo!
> Run SQL Logic Test suite using Calcite's HSQLDB JDBC adapter
>
>
> Key: CALCITE-5615
> URL: https://issues.apache.org/jira/browse/CALCITE-5615
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.34.0, 1.35.0
>Reporter: Mihai Budiu
>Assignee: Mihai Budiu
>Priority: Minor
> Labels: pull-request-available
> Fix For: 1.36.0
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> Add support for running [Sql Logic Test
> suite|https://github.com/hydromatic/sql-logic-test] using Calcite's HSQLDB
> JDBC adapter. This essentially improves test coverage for the JDBC adapter
> with HSQLDB in particular.
> Running the whole suite is pretty slow (more than 6h) so by default we run
> only one test file (namely
> [select1.test|https://github.com/hydromatic/sql-logic-test/blob/0a809c530457bf0e56d637ef19fcaabd2964fd67/src/main/resources/test/select1.test]).
> The rest of the tests can be run manually by removing the {{@Disabled}}
> annotation.
> Adding more test files and making this part of regular CI runs will be done
> in follow-up tickets.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-5615) Run SQL Logic Test suite using Calcite's HSQLDB JDBC adapter
[
https://issues.apache.org/jira/browse/CALCITE-5615?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stamatis Zampetakis updated CALCITE-5615:
-
Description:
Add support for running [Sql Logic Test
suite|https://github.com/hydromatic/sql-logic-test] using Calcite's HSQLDB JDBC
adapter. This essentially improves test coverage for the JDBC adapter with
HSQLDB in particular.
Running the whole suite is pretty slow (more than 6h) so by default we run only
one test file (namely
[select1.test|https://github.com/hydromatic/sql-logic-test/blob/0a809c530457bf0e56d637ef19fcaabd2964fd67/src/main/resources/test/select1.test]).
The rest of the tests can be run manually by removing the {{@Disabled}}
annotation.
Adding more test files and making this part of regular CI runs will be done in
follow-up tickets.
was:
Sqllogictest is a program designed to verify that an SQL database engine
computes correct results by comparing the results to identical queries from
other SQL database engines.
https://www.sqlite.org/sqllogictest/doc/trunk/about.wiki
The nice thing about SLT is that it contains more than 7 million tests. The
tests only cover the core of SQL, ideally the portable part across all engines.
They only test integers, doubles, and strings. So they could probably be part
of the Calcite slow tests.
The tests should be structured so that any query execution engine can be used.
I plan to contribute such an implementation if people think it is useful, but I
haven't yet worked out all the details.
> Run SQL Logic Test suite using Calcite's HSQLDB JDBC adapter
>
>
> Key: CALCITE-5615
> URL: https://issues.apache.org/jira/browse/CALCITE-5615
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.34.0, 1.35.0
>Reporter: Mihai Budiu
>Assignee: Mihai Budiu
>Priority: Minor
> Labels: pull-request-available
> Fix For: 1.36.0
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> Add support for running [Sql Logic Test
> suite|https://github.com/hydromatic/sql-logic-test] using Calcite's HSQLDB
> JDBC adapter. This essentially improves test coverage for the JDBC adapter
> with HSQLDB in particular.
> Running the whole suite is pretty slow (more than 6h) so by default we run
> only one test file (namely
> [select1.test|https://github.com/hydromatic/sql-logic-test/blob/0a809c530457bf0e56d637ef19fcaabd2964fd67/src/main/resources/test/select1.test]).
> The rest of the tests can be run manually by removing the {{@Disabled}}
> annotation.
> Adding more test files and making this part of regular CI runs will be done
> in follow-up tickets.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-5615) Run SQL Logic Test suite using Calcite's HSQLDB JDBC adapter
[ https://issues.apache.org/jira/browse/CALCITE-5615?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stamatis Zampetakis updated CALCITE-5615: - Summary: Run SQL Logic Test suite using Calcite's HSQLDB JDBC adapter (was: Run SQLLogicTests using Calcite) > Run SQL Logic Test suite using Calcite's HSQLDB JDBC adapter > > > Key: CALCITE-5615 > URL: https://issues.apache.org/jira/browse/CALCITE-5615 > Project: Calcite > Issue Type: Improvement > Components: core >Affects Versions: 1.34.0, 1.35.0 >Reporter: Mihai Budiu >Assignee: Mihai Budiu >Priority: Minor > Labels: pull-request-available > Fix For: 1.36.0 > > Time Spent: 1h 20m > Remaining Estimate: 0h > > Sqllogictest is a program designed to verify that an SQL database engine > computes correct results by comparing the results to identical queries from > other SQL database engines. > https://www.sqlite.org/sqllogictest/doc/trunk/about.wiki > The nice thing about SLT is that it contains more than 7 million tests. The > tests only cover the core of SQL, ideally the portable part across all > engines. They only test integers, doubles, and strings. So they could > probably be part of the Calcite slow tests. > The tests should be structured so that any query execution engine can be used. > I plan to contribute such an implementation if people think it is useful, but > I haven't yet worked out all the details. -- This message was sent by Atlassian Jira (v8.20.10#820010)
