Re: Question about Interpreter and Corelations
Hi Zoltan,
+1 on what Julian said.
Interpreter is not 100% accurate in this case since as you probably
realized this part of the code generates and compiles code.
Other than that I confirm that the Interpreter is not able to handle
correlations at the moment.
Best,
Stamatis
On Thu, Nov 7, 2019 at 11:08 PM Julian Hyde wrote:
> I don’t recall what the interpreter is currently capable of, but you
> should log a bug.
>
> I wonder whether if you could get the query to work in the interpreter if
> you decorrelated the query first.
>
> Julian
>
> > On Nov 7, 2019, at 11:16, Zoltan Farkas
> wrote:
> >
> > for a test query with the following plan:
> >
> > LogicalProject(name=[$1], friends=[$4])
> > LogicalCorrelate(correlation=[$cor0], joinType=[inner],
> requiredColumns=[{0}])
> >LogicalTableScan(table=[[characters]])
> >Collect(field=[EXPR$0])
> > LogicalProject(name=[$2])
> >LogicalJoin(condition=[=($0, $1)], joinType=[inner])
> > LogicalProject(characterId2=[$1])
> >LogicalFilter(condition=[=($0, $cor0.characterId)])
> > LogicalTableScan(table=[[friendships]])
> > LogicalProject(characterId=[$0], name=[$1])
> >LogicalTableScan(table=[[characters]])
> >
> > I get :
> >
> > java.lang.nsupportedOperationException
> >at
> o.a.c.i.JaninoRexCompiler.lambda$compile$0(JaninoRexCompiler.java:94)[calcite-core-1.21.0.jar:1.21.0]
> >at
> o.a.c.a.e.RexToLixTranslator.translate0(RexToLixTranslator.java:714)[^]
> >at ^.translate(^:199)[^]
> >at ^.translate0(^:684)[^]
> >at ^.translate(^:199)[^]
> >at ^.translate(^:194)[^]
> >...
> >
> > when trying to use the Interpreter.
> >
> > Is this a current limitation?
> >
> > the query is :
> >
> > select name,
> > ARRAY(select c2.name from friendships f, characters c2
> > where f.characterId1 = c.characterId and
> f.characterId2 = c2.characterId) as friends
> > from characters c
> >
> > let me know
> >
> > thank you
> >
> > —Z
>
[jira] [Created] (CALCITE-3483) Make RexLiteral member fields accessible by sub-class
Haisheng Yuan created CALCITE-3483:
--
Summary: Make RexLiteral member fields accessible by sub-class
Key: CALCITE-3483
URL: https://issues.apache.org/jira/browse/CALCITE-3483
Project: Calcite
Issue Type: Improvement
Components: core
Reporter: Haisheng Yuan
RexLiteral may be sub-classed and some methods may be overrode. e.g.
{{printAsJava}}. But currently, RexLiteral fields are private, sub-classes
can't access these fields, which makes methods like {{printAsJava}} unable to
be overrode. We recommend make RexLiteral member fields protected, so that we
can sub-class it, and customize the behavior of methods such as
{{printAsJava}}. Does it make sense?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
Re: [ANNOUNCE] Danny Chan joins Calcite PMC
Congratulations Danny! Well deserved! Best, Jincheng Enrico Olivelli 于2019年11月5日周二 下午2:31写道： > Congrat Danny ! > > Enrico > > Il giorno dom 3 nov 2019 alle ore 20:29 Julian Feinauer < > j.feina...@pragmaticminds.de> ha scritto: > > > Congratulations Danny! Very well deserved! > > > > Julian > > > > Am 01.11.19, 20:49 schrieb "Muhammad Gelbana" : > > > > Congratulations! > > > > Thanks, > > Gelbana > > > > > > On Fri, Nov 1, 2019 at 9:07 AM Stamatis Zampetakis < > zabe...@gmail.com> > > wrote: > > > > > Congratulations Danny! > > > > > > You are doing an amazing job. The project and the community is > > becoming > > > better every day and your help is much appreciated. > > > > > > Keep up the momentum! > > > > > > Best, > > > Stamatis > > > > > > On Thu, Oct 31, 2019 at 4:41 AM Kurt Young > wrote: > > > > > > > Congratulations Danny! > > > > > > > > Best, > > > > Kurt > > > > > > > > > > > > On Thu, Oct 31, 2019 at 11:18 AM Danny Chan < > yuzhao@gmail.com> > > > wrote: > > > > > > > > > Thank you so much colleagues, it’s my honor to work with you! > > > > > > > > > > I have always felt respected and the harmony of the community, > > hope to > > > > > contribute more and I would give help as best as I can, thanks > ! > > > > > > > > > > Best, > > > > > Danny Chan > > > > > 在 2019年10月31日 +0800 AM5:22，Francis Chuang < > > francischu...@apache.org > > > >，写道： > > > > > > I'm pleased to announce that Danny has accepted an invitation > > to > > > > > > join the Calcite PMC. Danny has been a consistent and helpful > > > > > > figure in the Calcite community for which we are very > > grateful. We > > > > > > look forward to the continued contributions and support. > > > > > > > > > > > > Please join me in congratulating Danny! > > > > > > > > > > > > - Francis (on behalf of the Calcite PMC) > > > > > > > > > > > > > > > > > > >
Re: Question about Interpreter and Corelations
I don’t recall what the interpreter is currently capable of, but you should log
a bug.
I wonder whether if you could get the query to work in the interpreter if you
decorrelated the query first.
Julian
> On Nov 7, 2019, at 11:16, Zoltan Farkas wrote:
>
> for a test query with the following plan:
>
> LogicalProject(name=[$1], friends=[$4])
> LogicalCorrelate(correlation=[$cor0], joinType=[inner],
> requiredColumns=[{0}])
>LogicalTableScan(table=[[characters]])
>Collect(field=[EXPR$0])
> LogicalProject(name=[$2])
>LogicalJoin(condition=[=($0, $1)], joinType=[inner])
> LogicalProject(characterId2=[$1])
>LogicalFilter(condition=[=($0, $cor0.characterId)])
> LogicalTableScan(table=[[friendships]])
> LogicalProject(characterId=[$0], name=[$1])
>LogicalTableScan(table=[[characters]])
>
> I get :
>
> java.lang.nsupportedOperationException
>at
> o.a.c.i.JaninoRexCompiler.lambda$compile$0(JaninoRexCompiler.java:94)[calcite-core-1.21.0.jar:1.21.0]
>at o.a.c.a.e.RexToLixTranslator.translate0(RexToLixTranslator.java:714)[^]
>at ^.translate(^:199)[^]
>at ^.translate0(^:684)[^]
>at ^.translate(^:199)[^]
>at ^.translate(^:194)[^]
>...
>
> when trying to use the Interpreter.
>
> Is this a current limitation?
>
> the query is :
>
> select name,
> ARRAY(select c2.name from friendships f, characters c2
> where f.characterId1 = c.characterId and
> f.characterId2 = c2.characterId) as friends
> from characters c
>
> let me know
>
> thank you
>
> —Z
Question about Interpreter and Corelations
for a test query with the following plan:
LogicalProject(name=[$1], friends=[$4])
LogicalCorrelate(correlation=[$cor0], joinType=[inner], requiredColumns=[{0}])
LogicalTableScan(table=[[characters]])
Collect(field=[EXPR$0])
LogicalProject(name=[$2])
LogicalJoin(condition=[=($0, $1)], joinType=[inner])
LogicalProject(characterId2=[$1])
LogicalFilter(condition=[=($0, $cor0.characterId)])
LogicalTableScan(table=[[friendships]])
LogicalProject(characterId=[$0], name=[$1])
LogicalTableScan(table=[[characters]])
I get :
java.lang.nsupportedOperationException
at
o.a.c.i.JaninoRexCompiler.lambda$compile$0(JaninoRexCompiler.java:94)[calcite-core-1.21.0.jar:1.21.0]
at
o.a.c.a.e.RexToLixTranslator.translate0(RexToLixTranslator.java:714)[^]
at ^.translate(^:199)[^]
at ^.translate0(^:684)[^]
at ^.translate(^:199)[^]
at ^.translate(^:194)[^]
...
when trying to use the Interpreter.
Is this a current limitation?
the query is :
select name,
ARRAY(select c2.name from friendships f, characters c2
where f.characterId1 = c.characterId and
f.characterId2 = c2.characterId) as friends
from characters c
let me know
thank you
—Z
Re: [DISCUSS] Towards Avatica 1.16.0
>I think it's also possible to get CALCITE-3158 (replace Maven with Gradle) I think this is more or less ready to go. The commits should probably be squashed, and I can do that if no-one else plans to review the change. There's "remove protobuf-generated files" change. Is it truly needed to store protobuf-generated files in the Git sources? PS. Apache JMeter has recently performed a release with Gradle. Here's what the release manager says re Ant -> Gradle: https://lists.apache.org/thread.html/c08780952b7fbd71eccff717cb494562723e11dc99ea1b4bb39af461@%3Cdev.jmeter.apache.org%3E Vladimir
[jira] [Created] (CALCITE-3482) Equality of nested ROWs returns false for identical literal value
Ruben Q L created CALCITE-3482:
--
Summary: Equality of nested ROWs returns false for identical
literal value
Key: CALCITE-3482
URL: https://issues.apache.org/jira/browse/CALCITE-3482
Project: Calcite
Issue Type: Bug
Affects Versions: 1.21.0
Reporter: Ruben Q L
Assignee: Ruben Q L
Fix For: 1.22.0
Similar to CALCITE-3021.
Problem can be reproduced via:
{code}
select * from
(values
(1, ROW(1,1)),
(2, ROW(2,2)),
(3, ROW(1,1)),
(4, ROW(2,2))) as t(id,struct)
where t.struct = ROW(2,2);
{code}
which returns no results, instead of the expected (I have run the same query in
PostgreSQL, and it returns this result):
{code}
+++
| ID | STRUCT |
+++
| 2 | {2, 2} |
| 4 | {2, 2} |
+++
{code}
The issue is that the comparison is done via SqlFuynctions#eq(Object b0, Object
b1)
{code}
public static boolean eq(Object b0, Object b1) {
return b0.equals(b1);
}
{code}
And in this case we have two different Object[], with the same content, so the
should be identified as equals. Probably the simples solution would be
overloading the eq method:
{code}
public static boolean eq(Object[] b0, Object[] b1) {
return Arrays.deepEquals(b0, b1);
}
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (CALCITE-3481) Support convert TableFunctionScan to SqlNode
Wang Yanlin created CALCITE-3481:
Summary: Support convert TableFunctionScan to SqlNode
Key: CALCITE-3481
URL: https://issues.apache.org/jira/browse/CALCITE-3481
Project: Calcite
Issue Type: Improvement
Reporter: Wang Yanlin
Currently, converting *TableFunctionScan* to sql is not supported, doing this
will cause exception.
Add the following test case in *RelToSqlConverterTest* to reproduce.
{code:java}
@Test public void testTableFunctionScan() {
final String query = "SELECT *\n"
+ "FROM TABLE(DEDUP(CURSOR(select \"product_id\", \"product_name\"\n"
+ "from \"product\"), CURSOR(select \"employee_id\", \"full_name\"\n"
+ "from \"employee\"), 'NAME'))";
final String expected = "SELECT *\n"
+ "FROM TABLE(DEDUP(CURSOR ((SELECT \"product_id\", \"product_name\"\n"
+ "FROM \"foodmart\".\"product\")), CURSOR ((SELECT \"employee_id\",
\"full_name\"\n"
+ "FROM \"foodmart\".\"employee\")), 'NAME'))";
sql(query).ok(expected);
}
{code}
The stack trace of exception is
{noformat}
java.lang.RuntimeException: While invoking method 'public
org.apache.calcite.rel.rel2sql.SqlImplementor$Result
org.apache.calcite.rel.rel2sql.RelToSqlConverter.visit(org.apache.calcite.rel.core.Project)'
at org.apache.calcite.util.ReflectUtil$2.invoke(ReflectUtil.java:527)
at
org.apache.calcite.rel.rel2sql.RelToSqlConverter.dispatch(RelToSqlConverter.java:122)
at
org.apache.calcite.rel.rel2sql.RelToSqlConverter.visitChild(RelToSqlConverter.java:128)
at
org.apache.calcite.rel.rel2sql.RelToSqlConverterTest.toSql(RelToSqlConverterTest.java:187)
at
org.apache.calcite.rel.rel2sql.RelToSqlConverterTest.access$100(RelToSqlConverterTest.java:92)
at
org.apache.calcite.rel.rel2sql.RelToSqlConverterTest$Sql.exec(RelToSqlConverterTest.java:4331)
at
org.apache.calcite.rel.rel2sql.RelToSqlConverterTest$Sql.ok(RelToSqlConverterTest.java:4306)
at
org.apache.calcite.rel.rel2sql.RelToSqlConverterTest.testTableFunctionScan(RelToSqlConverterTest.java:4126)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
at
com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
at
com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:47)
at
com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242)
at
com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70)
Caused by: java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.apache.calcite.util.ReflectUtil$2.invoke(ReflectUtil.java:524)
... 29 more
Caused by: java.lang.RuntimeException: While invoking method 'public
org.apache.calcite.rel.rel2sql.SqlImplementor$Result
org.apache.calcite.rel.rel2sql.RelToSqlConverter.visit(org.apache.calcite.rel.RelNode)'
at org.apache.calcite.util.ReflectUtil$2.invoke(ReflectUtil.java:527)
at
org.apache.calcite.rel.rel2sql.RelToSqlConverter.dispatch(RelToSqlConverter.java:122)
at
