Re: Filterable table
Thanks, Albert ~ The ProjectableFilterableTable is indeed a little redundant, because we already have ProjectableTable and FilterableTable, I think we can do some refactoring to reduce such mixed in interfaces. BTW, what do you mean by aggregate push down ? I can not figure out in which case you need such feature, can you share to us your use cases ? Best, Danny Chan 在 2019年8月12日 +0800 PM12:20，Albert ，写道： > talking about this class reminds me of my own usage of > ProjectableFilterable. it works. > but this feels like a very bad design, what if I want to push down > Aggregation ? AggregatableProjectableFilterable? > > I don't know the intention of the initial design, but this just doesn't > feel right. > > On Mon, Aug 12, 2019 at 9:35 AM Danny Chan wrote: > > > There is a ProjectableFilterableTable[1] that can be both used for filter > > and projects push down, have a try :) > > > > [1] > > https://github.com/apache/calcite/blob/996cdd0249a4e5086fadc27a15ccc23eb9defd8e/core/src/main/java/org/apache/calcite/schema/ProjectableFilterableTable.java#L36 > > > > Best, > > Danny Chan > > 在 2019年8月12日 +0800 AM7:55，Lekshmi ，写道： > > > Hi Danny Chan, > > > Thank you so much for responding to my email. Can we use, Translatable > > > table instead of Filterable table? which is more efficient? Usecase that > > if > > > need to write a Project push down (Push down Project fields into table > > scan > > > then do Filtering) and Filter push down? > > > Or Filterable table is enough to use Project push down as well? > > > Thanks and Regards > > > > > > Lekshmi B.G > > > Email: lekshmib...@gmail.com > > > > > > > > > > > > > > > On Fri, Aug 9, 2019 at 11:15 AM Danny Chan wrote: > > > > > > > Hi, Lekshmi ~ > > > > > > > > > > > > The FilterableTable can be scanned with a list of filter expression, > > that > > > > means the filter conditions above the project + scan can be > > > > pushed directly into the table scan[1][2], which is more efficient. > > Here is > > > > a CsvFilterableTable example [3]. > > > > > > > > [1] > > > > > > https://github.com/apache/calcite/blob/602b2a10e3f81888c0759ca69f7415497124ef82/core/src/main/java/org/apache/calcite/rel/rules/FilterTableScanRule.java#L130 > > > > [2] > > > > > > https://github.com/apache/calcite/blob/602b2a10e3f81888c0759ca69f7415497124ef82/core/src/main/java/org/apache/calcite/rel/rules/ProjectTableScanRule.java#L128 > > > > [3] > > > > > > https://github.com/apache/calcite/blob/602b2a10e3f81888c0759ca69f7415497124ef82/example/csv/src/main/java/org/apache/calcite/adapter/csv/CsvFilterableTable.java#L65 > > > > > > > > Best, > > > > Danny Chan > > > > 在 2019年8月8日 +0800 PM10:56，dev@calcite.apache.org，写道： > > > > > > > > > > Filterable > > > > > > > > > -- > ~~~ > no mistakes > ~~
Re: Filterable table
talking about this class reminds me of my own usage of ProjectableFilterable. it works. but this feels like a very bad design, what if I want to push down Aggregation ? AggregatableProjectableFilterable? I don't know the intention of the initial design, but this just doesn't feel right. On Mon, Aug 12, 2019 at 9:35 AM Danny Chan wrote: > There is a ProjectableFilterableTable[1] that can be both used for filter > and projects push down, have a try :) > > [1] > https://github.com/apache/calcite/blob/996cdd0249a4e5086fadc27a15ccc23eb9defd8e/core/src/main/java/org/apache/calcite/schema/ProjectableFilterableTable.java#L36 > > Best, > Danny Chan > 在 2019年8月12日 +0800 AM7:55，Lekshmi ，写道： > > Hi Danny Chan, > > Thank you so much for responding to my email. Can we use, Translatable > > table instead of Filterable table? which is more efficient? Usecase that > if > > need to write a Project push down (Push down Project fields into table > scan > > then do Filtering) and Filter push down? > > Or Filterable table is enough to use Project push down as well? > > Thanks and Regards > > > > Lekshmi B.G > > Email: lekshmib...@gmail.com > > > > > > > > > > On Fri, Aug 9, 2019 at 11:15 AM Danny Chan wrote: > > > > > Hi, Lekshmi ~ > > > > > > > > > The FilterableTable can be scanned with a list of filter expression, > that > > > means the filter conditions above the project + scan can be > > > pushed directly into the table scan[1][2], which is more efficient. > Here is > > > a CsvFilterableTable example [3]. > > > > > > [1] > > > > https://github.com/apache/calcite/blob/602b2a10e3f81888c0759ca69f7415497124ef82/core/src/main/java/org/apache/calcite/rel/rules/FilterTableScanRule.java#L130 > > > [2] > > > > https://github.com/apache/calcite/blob/602b2a10e3f81888c0759ca69f7415497124ef82/core/src/main/java/org/apache/calcite/rel/rules/ProjectTableScanRule.java#L128 > > > [3] > > > > https://github.com/apache/calcite/blob/602b2a10e3f81888c0759ca69f7415497124ef82/example/csv/src/main/java/org/apache/calcite/adapter/csv/CsvFilterableTable.java#L65 > > > > > > Best, > > > Danny Chan > > > 在 2019年8月8日 +0800 PM10:56，dev@calcite.apache.org，写道： > > > > > > > > Filterable > > > > -- ~~~ no mistakes ~~
[jira] [Created] (CALCITE-3241) Calcite this is a very strange mistake
;ianghaibin created CALCITE-3241:
Summary: Calcite this is a very strange mistake
Key: CALCITE-3241
URL: https://issues.apache.org/jira/browse/CALCITE-3241
Project: Calcite
Issue Type: Bug
Reporter: ;ianghaibin
0: jdbc:calcite:model=/root/calcite/apache-ca> select sum("xxx") as a from
"xxx";
java.lang.NumberFormatException: For input string: "13485468068"
at
ru.yandex.clickhouse.response.ByteFragmentUtils.parseInt(ByteFragmentUtils.java:61)
at
ru.yandex.clickhouse.response.ClickHouseResultSet.getInt(ClickHouseResultSet.java:342)
at
org.apache.commons.dbcp2.DelegatingResultSet.getInt(DelegatingResultSet.java:623)
at
org.apache.commons.dbcp2.DelegatingResultSet.getInt(DelegatingResultSet.java:623)
at Baz$1$1.apply(Unknown Source)
at
org.apache.calcite.runtime.ResultSetEnumerable$ResultSetEnumerator.current(ResultSetEnumerable.java:365)
at org.apache.calcite.linq4j.Linq4j$EnumeratorIterator.next(Linq4j.java:683)
at org.apache.calcite.avatica.util.IteratorCursor.next(IteratorCursor.java:46)
at org.apache.calcite.avatica.AvaticaResultSet.next(AvaticaResultSet.java:217)
at sqlline.BufferedRows.nextList(BufferedRows.java:110)
at sqlline.BufferedRows.(BufferedRows.java:52)
at sqlline.SqlLine.print(SqlLine.java:1640)
at sqlline.Commands.executeSingleQuery(Commands.java:1017)
at sqlline.Commands.execute(Commands.java:957)
at sqlline.Commands.sql(Commands.java:921)
at sqlline.SqlLine.dispatch(SqlLine.java:717)
at sqlline.SqlLine.begin(SqlLine.java:536)
at sqlline.SqlLine.start(SqlLine.java:266)
at sqlline.SqlLine.main(SqlLine.java:205)
The data I got is integer, and I am getting an error.
However, this is not an error.
select "xx","xx",sum("xx") as xx from "xx" group by "xx","xxx" limit 1;
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
Re: Contributor in JIRA
Welcome, Uma ! Best, Danny Chan 在 2019年8月10日 +0800 AM1:17，Umesh S ，写道： > Hi, > > Please add me as contributor in JIRA. My username is uma.thakur > > - > Thanks > Uma
Re: Filterable table
There is a ProjectableFilterableTable[1] that can be both used for filter and projects push down, have a try :) [1] https://github.com/apache/calcite/blob/996cdd0249a4e5086fadc27a15ccc23eb9defd8e/core/src/main/java/org/apache/calcite/schema/ProjectableFilterableTable.java#L36 Best, Danny Chan 在 2019年8月12日 +0800 AM7:55，Lekshmi ，写道： > Hi Danny Chan, > Thank you so much for responding to my email. Can we use, Translatable > table instead of Filterable table? which is more efficient? Usecase that if > need to write a Project push down (Push down Project fields into table scan > then do Filtering) and Filter push down? > Or Filterable table is enough to use Project push down as well? > Thanks and Regards > > Lekshmi B.G > Email: lekshmib...@gmail.com > > > > > On Fri, Aug 9, 2019 at 11:15 AM Danny Chan wrote: > > > Hi, Lekshmi ~ > > > > > > The FilterableTable can be scanned with a list of filter expression, that > > means the filter conditions above the project + scan can be > > pushed directly into the table scan[1][2], which is more efficient. Here is > > a CsvFilterableTable example [3]. > > > > [1] > > https://github.com/apache/calcite/blob/602b2a10e3f81888c0759ca69f7415497124ef82/core/src/main/java/org/apache/calcite/rel/rules/FilterTableScanRule.java#L130 > > [2] > > https://github.com/apache/calcite/blob/602b2a10e3f81888c0759ca69f7415497124ef82/core/src/main/java/org/apache/calcite/rel/rules/ProjectTableScanRule.java#L128 > > [3] > > https://github.com/apache/calcite/blob/602b2a10e3f81888c0759ca69f7415497124ef82/example/csv/src/main/java/org/apache/calcite/adapter/csv/CsvFilterableTable.java#L65 > > > > Best, > > Danny Chan > > 在 2019年8月8日 +0800 PM10:56，dev@calcite.apache.org，写道： > > > > > > Filterable > >
Re: Filterable table
Hi Danny Chan, Thank you so much for responding to my email. Can we use, Translatable table instead of Filterable table? which is more efficient? Usecase that if need to write a Project push down (Push down Project fields into table scan then do Filtering) and Filter push down? Or Filterable table is enough to use Project push down as well? Thanks and Regards Lekshmi B.G Email: lekshmib...@gmail.com On Fri, Aug 9, 2019 at 11:15 AM Danny Chan wrote: > Hi, Lekshmi ~ > > > The FilterableTable can be scanned with a list of filter expression, that > means the filter conditions above the project + scan can be > pushed directly into the table scan[1][2], which is more efficient. Here is > a CsvFilterableTable example [3]. > > [1] > https://github.com/apache/calcite/blob/602b2a10e3f81888c0759ca69f7415497124ef82/core/src/main/java/org/apache/calcite/rel/rules/FilterTableScanRule.java#L130 > [2] > https://github.com/apache/calcite/blob/602b2a10e3f81888c0759ca69f7415497124ef82/core/src/main/java/org/apache/calcite/rel/rules/ProjectTableScanRule.java#L128 > [3] > https://github.com/apache/calcite/blob/602b2a10e3f81888c0759ca69f7415497124ef82/example/csv/src/main/java/org/apache/calcite/adapter/csv/CsvFilterableTable.java#L65 > > Best, > Danny Chan > 在 2019年8月8日 +0800 PM10:56，dev@calcite.apache.org，写道： > > > > Filterable >
[jira] [Created] (CALCITE-3240) Javadoc gives internal error "com.sun.tools.javac.code.ClassFinder$BadClassFile: bad class file: linq4j/target/classes/org/apache/calcite/linq4j/Ord$2.class [ERROR] u
Julian Hyde created CALCITE-3240:
Summary: Javadoc gives internal error
"com.sun.tools.javac.code.ClassFinder$BadClassFile: bad class file:
linq4j/target/classes/org/apache/calcite/linq4j/Ord$2.class [ERROR]
undeclared type variable: E"
Key: CALCITE-3240
URL: https://issues.apache.org/jira/browse/CALCITE-3240
Project: Calcite
Issue Type: Bug
Reporter: Julian Hyde
Javadoc gives an internal error on JDK 9 (version 9.0.4) and JDK 10 (version
10.0.2):
{noformat}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-javadoc-plugin:3.0.1:test-javadoc (default-cli)
on project calcite-linq4j: An error has occurred in Test Javadoc report
generation:
[ERROR] Exit code: 1 - javadoc: error - An internal exception has occurred.
[ERROR] (com.sun.tools.javac.code.ClassFinder$BadClassFile: bad class
file:
/home/jhyde/open1/calcite.2/linq4j/target/classes/org/apache/calcite/linq4j/Ord$2.class
[ERROR] undeclared type variable: E
[ERROR] Please remove or make sure it appears in the correct subdirectory of
the classpath.)
[ERROR] Please file a bug against the javadoc tool via the Java bug reporting
page
[ERROR] (http://bugreport.java.com) after checking the Bug Database
(http://bugs.java.com)
[ERROR] for duplicates. Include error messages and the following diagnostic in
your report. Thank you.
[ERROR] com.sun.tools.javac.code.ClassFinder$BadClassFile: bad class file:
/home/jhyde/open1/calcite.2/linq4j/target/classes/org/apache/calcite/linq4j/Ord$2.class
[ERROR] undeclared type variable: E
[ERROR] Please remove or make sure it appears in the correct subdirectory of
the classpath.
[ERROR] at
jdk.compiler/com.sun.tools.javac.jvm.ClassReader.badClassFile(ClassReader.java:281)
[ERROR] at
jdk.compiler/com.sun.tools.javac.jvm.ClassReader.findTypeVar(ClassReader.java:966)
[ERROR] at
jdk.compiler/com.sun.tools.javac.jvm.ClassReader.readEnclosingMethodAttr(ClassReader.java:1463)
[ERROR] at
jdk.compiler/com.sun.tools.javac.jvm.ClassReader$10.read(ClassReader.java:1173)
[ERROR] at
jdk.compiler/com.sun.tools.javac.jvm.ClassReader.readAttrs(ClassReader.java:1549)
[ERROR] at
jdk.compiler/com.sun.tools.javac.jvm.ClassReader.readClassAttrs(ClassReader.java:1563)
[ERROR] at
jdk.compiler/com.sun.tools.javac.jvm.ClassReader.readClass(ClassReader.java:2625)
[ERROR] at
jdk.compiler/com.sun.tools.javac.jvm.ClassReader.readClassBuffer(ClassReader.java:2718)
[ERROR] at
jdk.compiler/com.sun.tools.javac.jvm.ClassReader.readClassFile(ClassReader.java:2731)
[ERROR] at
jdk.compiler/com.sun.tools.javac.code.ClassFinder.fillIn(ClassFinder.java:352)
[ERROR] at
jdk.compiler/com.sun.tools.javac.code.ClassFinder.complete(ClassFinder.java:284)
[ERROR] at
jdk.compiler/com.sun.tools.javac.code.Symbol.complete(Symbol.java:633)
[ERROR] at
jdk.compiler/com.sun.tools.javac.code.Symbol$ClassSymbol.complete(Symbol.java:1308)
[ERROR] at
jdk.compiler/com.sun.tools.javac.code.Symbol$ClassSymbol.flags(Symbol.java:1242)
[ERROR] at
jdk.compiler/com.sun.tools.javac.code.Symbol$TypeSymbol.getEnclosedElements(Symbol.java:800)
[ERROR] at
jdk.javadoc/jdk.javadoc.internal.doclets.toolkit.util.Utils.getItems0(Utils.java:2404)
[ERROR] at
jdk.javadoc/jdk.javadoc.internal.doclets.toolkit.util.Utils.getItems0(Utils.java:2399)
[ERROR] at
jdk.javadoc/jdk.javadoc.internal.doclets.toolkit.util.Utils.recursiveGetItems(Utils.java:2387)
[ERROR] at
jdk.javadoc/jdk.javadoc.internal.doclets.toolkit.util.Utils$17.visitPackage(Utils.java:2372)
[ERROR] at
jdk.javadoc/jdk.javadoc.internal.doclets.toolkit.util.Utils$17.visitPackage(Utils.java:2368)
[ERROR] at
jdk.compiler/com.sun.tools.javac.code.Symbol$PackageSymbol.accept(Symbol.java:1160)
[ERROR] at
java.compiler@10.0.2/javax.lang.model.util.AbstractElementVisitor6.visit(AbstractElementVisitor6.java:106)
[ERROR] at
jdk.javadoc/jdk.javadoc.internal.doclets.toolkit.util.Utils.getItems(Utils.java:2381)
[ERROR] at
jdk.javadoc/jdk.javadoc.internal.doclets.toolkit.util.Utils.getClasses(Utils.java:2121)
[ERROR] at
jdk.javadoc/jdk.javadoc.internal.doclets.toolkit.util.Utils.getAllClasses(Utils.java:2294)
[ERROR] at
jdk.javadoc/jdk.javadoc.internal.doclets.toolkit.AbstractDoclet.generateClassFiles(AbstractDoclet.java:277)
[ERROR] at
jdk.javadoc/jdk.javadoc.internal.doclets.toolkit.AbstractDoclet.startGeneration(AbstractDoclet.java:211)
[ERROR] at
jdk.javadoc/jdk.javadoc.internal.doclets.toolkit.AbstractDoclet.run(AbstractDoclet.java:117)
[ERROR] at
jdk.javadoc/jdk.javadoc.doclet.StandardDoclet.run(StandardDoclet.java:72)
[ERROR] at
jdk.javadoc/jdk.javadoc.internal.tool.Start.parseAndExecute(Start.java:581)
[ERROR] at
Re: Assigning jira issue
Thanks a lot ~ Francis Francis Chuang 于2019年8月9日周五 上午11:13写道： > Hi Xing Jin, > > I've added you to the contributor role. > > Francis > > On 9/08/2019 12:52 pm, XING JIN wrote: > > Hi Francis, > > I have the same request with Sahith. > > Could you please add me to the contributor list as well ? > > My user name is -- jin xing > > Thanks a lot ! > > > > Francis Chuang 于2019年8月9日周五 上午5:58写道： > > > >> Hey Sahith, > >> > >> I've added you to the contributor role and assigned the issue to you. > >> > >> Francis > >> > >> On 8/08/2019 11:54 pm, sahith.re...@gmail.com wrote: > >>> Hello, > >>> > >>> I created issue CALCITE-3237, > >> https://issues.apache.org/jira/browse/CALCITE-3237, and I submitted a > PR > >> for it as well. Can this issue be assigned to me? My jira username is > >> snallapa. Thank you! > >>> > >>> Thanks, > >>> > >>> Sahith > >>> > >> > > >
[jira] [Created] (CALCITE-3239) Calc#accept(RexShuttle shuttle) does not update rowType
jin xing created CALCITE-3239:
-
Summary: Calc#accept(RexShuttle shuttle) does not update rowType
Key: CALCITE-3239
URL: https://issues.apache.org/jira/browse/CALCITE-3239
Project: Calcite
Issue Type: Bug
Components: core
Reporter: jin xing
In current code, {{Calc#accept(RexShuttle shuttle)}} keep the original
{{rowType}}, even when the expression list is modified by the shuttle.
https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/rel/core/Calc.java#L175
It might be wrong and a new {{rowType}} should be derived.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
