[jira] [Commented] (CALCITE-3310) Approximate and exact aggregate calls are recognized as the same during sql-to-rel conversion
[
https://issues.apache.org/jira/browse/CALCITE-3310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16919340#comment-16919340
]
Chris Baynes commented on CALCITE-3310:
---
I may be wrong here but I seem to remember that the approximate flag is kept on
the RelNode, it's just not printed in the plan.
> Approximate and exact aggregate calls are recognized as the same during
> sql-to-rel conversion
> -
>
> Key: CALCITE-3310
> URL: https://issues.apache.org/jira/browse/CALCITE-3310
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.20.0
>Reporter: Danny Chan
>Assignee: Danny Chan
>Priority: Major
> Fix For: 1.21.0
>
>
> For sql:
> {code:sql}
> SELECT empno, count(distinct ename)
> approx_count_distinct(ename)
> FROM emp
> GROUP BY empno
> {code}
> After sql-to-rel conversion, the plan is:
> {code:sql}
> LogicalProject(EMPNO=[$0], EXPR$1=[$1], EXPR$2=[$1])
> LogicalAggregate(group=[{0}], EXPR$1=[COUNT(DISTINCT $1)])
> LogicalProject(EMPNO=[$0], ENAME=[$1])
> LogicalTableScan(table=[[CATALOG, SALES, EMP]])
> {code}
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (CALCITE-3241) Calcite this is a very strange mistake
[
https://issues.apache.org/jira/browse/CALCITE-3241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16905076#comment-16905076
]
Chris Baynes commented on CALCITE-3241:
---
It looks like you are trying to sum a column that has a String type in
Clickhouse. If that's the case, then this isn't going to work.
What are the column types you're interacting with here?
> 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
>Priority: Major
>
> 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)
[jira] [Commented] (CALCITE-2157) ClickHouse dialect implementation
[ https://issues.apache.org/jira/browse/CALCITE-2157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16887758#comment-16887758 ] Chris Baynes commented on CALCITE-2157: --- Have just rebased this PR and made a couple of improvements. [~julianhyde] wdyt about merging this without the vm tests? I think this code makes Calcite better than without it - currently users of ClickHouse would see almost all queries fail if they just use the default dialect. With this PR lots of the features become available. > ClickHouse dialect implementation > - > > Key: CALCITE-2157 > URL: https://issues.apache.org/jira/browse/CALCITE-2157 > Project: Calcite > Issue Type: New Feature > Components: jdbc-adapter >Reporter: Chris Baynes >Priority: Major > Labels: pull-request-available > Time Spent: 10m > Remaining Estimate: 0h > > ClickHouse is a really fast columnar DBMS for OLAP: > [https://clickhouse.yandex/.|https://clickhouse.yandex/] > It has a jdbc adapter and uses mostly standard sql, though there are > differences (e.g. join syntax, datatypes, function name case-sensitivity). -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (CALCITE-2305) Invalid casting for some postgres types
[
https://issues.apache.org/jira/browse/CALCITE-2305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16471698#comment-16471698
]
Chris Baynes commented on CALCITE-2305:
---
That's a fair point, I've added some comments.
> Invalid casting for some postgres types
> ---
>
> Key: CALCITE-2305
> URL: https://issues.apache.org/jira/browse/CALCITE-2305
> Project: Calcite
> Issue Type: Bug
> Components: jdbc-adapter
>Affects Versions: 1.16.0
>Reporter: Chris Baynes
>Assignee: Julian Hyde
>Priority: Major
>
> The types `TINYINT` and `DOUBLE` do not exist in Postgres, so attempting to
> cast to them throws a runtime exception, e.g.
>
> {code:java}
> // query
> select CAST("store_id" as TINYINT) from "foodmart"."expense_fact"
> // exception
> java.lang.RuntimeException: exception while executing [select CAST("store_id"
> as TINYINT) from "foodmart"."expense_fact"]
> at org.apache.calcite.test.JdbcAdapterTest.testCast(JdbcAdapterTest.java:478)
> Caused by: java.lang.RuntimeException: With materializationsEnabled=false,
> limit=0
> at org.apache.calcite.test.JdbcAdapterTest.testCast(JdbcAdapterTest.java:478)
> Caused by: java.sql.SQLException:
> Error while executing SQL "select CAST("store_id" as TINYINT) from
> "foodmart"."expense_fact"": while executing SQL [SELECT CAST("store_id" AS
> TINYINT)
> FROM "public"."expense_fact"]
> at org.apache.calcite.test.JdbcAdapterTest.testCast(JdbcAdapterTest.java:478)
> Caused by: java.lang.RuntimeException:
> while executing SQL [SELECT CAST("store_id" AS TINYINT)
> FROM "public"."expense_fact"]
> at org.apache.calcite.test.JdbcAdapterTest.testCast(JdbcAdapterTest.java:478)
> Caused by: org.postgresql.util.PSQLException:
> ERROR: type "tinyint" does not exist
> Position: 27
> at org.apache.calcite.test.JdbcAdapterTest.testCast(JdbcAdapterTest.java:478)
> {code}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2305) Invalid casting for some postgres types
[
https://issues.apache.org/jira/browse/CALCITE-2305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16468652#comment-16468652
]
Chris Baynes commented on CALCITE-2305:
---
PR for the fix is here: https://github.com/apache/calcite/pull/689
> Invalid casting for some postgres types
> ---
>
> Key: CALCITE-2305
> URL: https://issues.apache.org/jira/browse/CALCITE-2305
> Project: Calcite
> Issue Type: Bug
> Components: jdbc-adapter
>Affects Versions: 1.16.0
>Reporter: Chris Baynes
>Assignee: Julian Hyde
>Priority: Major
>
> The types `TINYINT` and `DOUBLE` do not exist in Postgres, so attempting to
> cast to them throws a runtime exception, e.g.
>
> {code:java}
> // query
> select CAST("store_id" as TINYINT) from "foodmart"."expense_fact"
> // exception
> java.lang.RuntimeException: exception while executing [select CAST("store_id"
> as TINYINT) from "foodmart"."expense_fact"]
> at org.apache.calcite.test.JdbcAdapterTest.testCast(JdbcAdapterTest.java:478)
> Caused by: java.lang.RuntimeException: With materializationsEnabled=false,
> limit=0
> at org.apache.calcite.test.JdbcAdapterTest.testCast(JdbcAdapterTest.java:478)
> Caused by: java.sql.SQLException:
> Error while executing SQL "select CAST("store_id" as TINYINT) from
> "foodmart"."expense_fact"": while executing SQL [SELECT CAST("store_id" AS
> TINYINT)
> FROM "public"."expense_fact"]
> at org.apache.calcite.test.JdbcAdapterTest.testCast(JdbcAdapterTest.java:478)
> Caused by: java.lang.RuntimeException:
> while executing SQL [SELECT CAST("store_id" AS TINYINT)
> FROM "public"."expense_fact"]
> at org.apache.calcite.test.JdbcAdapterTest.testCast(JdbcAdapterTest.java:478)
> Caused by: org.postgresql.util.PSQLException:
> ERROR: type "tinyint" does not exist
> Position: 27
> at org.apache.calcite.test.JdbcAdapterTest.testCast(JdbcAdapterTest.java:478)
> {code}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (CALCITE-2305) Invalid casting for some postgres types
Chris Baynes created CALCITE-2305:
-
Summary: Invalid casting for some postgres types
Key: CALCITE-2305
URL: https://issues.apache.org/jira/browse/CALCITE-2305
Project: Calcite
Issue Type: Bug
Components: jdbc-adapter
Affects Versions: 1.16.0
Reporter: Chris Baynes
Assignee: Julian Hyde
The types `TINYINT` and `DOUBLE` do not exist in Postgres, so attempting to
cast to them throws a runtime exception, e.g.
{code:java}
// query
select CAST("store_id" as TINYINT) from "foodmart"."expense_fact"
// exception
java.lang.RuntimeException: exception while executing [select CAST("store_id"
as TINYINT) from "foodmart"."expense_fact"]
at org.apache.calcite.test.JdbcAdapterTest.testCast(JdbcAdapterTest.java:478)
Caused by: java.lang.RuntimeException: With materializationsEnabled=false,
limit=0
at org.apache.calcite.test.JdbcAdapterTest.testCast(JdbcAdapterTest.java:478)
Caused by: java.sql.SQLException:
Error while executing SQL "select CAST("store_id" as TINYINT) from
"foodmart"."expense_fact"": while executing SQL [SELECT CAST("store_id" AS
TINYINT)
FROM "public"."expense_fact"]
at org.apache.calcite.test.JdbcAdapterTest.testCast(JdbcAdapterTest.java:478)
Caused by: java.lang.RuntimeException:
while executing SQL [SELECT CAST("store_id" AS TINYINT)
FROM "public"."expense_fact"]
at org.apache.calcite.test.JdbcAdapterTest.testCast(JdbcAdapterTest.java:478)
Caused by: org.postgresql.util.PSQLException:
ERROR: type "tinyint" does not exist
Position: 27
at org.apache.calcite.test.JdbcAdapterTest.testCast(JdbcAdapterTest.java:478)
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2157) ClickHouse dialect implementation
[ https://issues.apache.org/jira/browse/CALCITE-2157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16368179#comment-16368179 ] Chris Baynes commented on CALCITE-2157: --- I've had a look at getting this into the test dataset, but since the CH dialect is not supported by Mondrian it's going to need more work. Instead I'd be happy to just add tests in JdbcAdapterTest for now and run them against a local instance. > ClickHouse dialect implementation > - > > Key: CALCITE-2157 > URL: https://issues.apache.org/jira/browse/CALCITE-2157 > Project: Calcite > Issue Type: New Feature > Components: jdbc-adapter >Reporter: Chris Baynes >Assignee: Julian Hyde >Priority: Major > > ClickHouse is a really fast columnar DBMS for OLAP: > [https://clickhouse.yandex/.|https://clickhouse.yandex/] > It has a jdbc adapter and uses mostly standard sql, though there are > differences (e.g. join syntax, datatypes, function name case-sensitivity). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-2157) ClickHouse dialect implementation
[ https://issues.apache.org/jira/browse/CALCITE-2157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16351916#comment-16351916 ] Chris Baynes commented on CALCITE-2157: --- I think it would be great to get it into the test vm, and then I can add a few dialect specific tests to JdbcAdapterTest. Will take a look at it. > ClickHouse dialect implementation > - > > Key: CALCITE-2157 > URL: https://issues.apache.org/jira/browse/CALCITE-2157 > Project: Calcite > Issue Type: New Feature > Components: jdbc-adapter >Reporter: Chris Baynes >Assignee: Julian Hyde >Priority: Major > > ClickHouse is a really fast columnar DBMS for OLAP: > [https://clickhouse.yandex/.|https://clickhouse.yandex/] > It has a jdbc adapter and uses mostly standard sql, though there are > differences (e.g. join syntax, datatypes, function name case-sensitivity). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (CALCITE-2157) ClickHouse dialect implementation
[ https://issues.apache.org/jira/browse/CALCITE-2157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Baynes reassigned CALCITE-2157: - Assignee: Julian Hyde (was: Chris Baynes) > ClickHouse dialect implementation > - > > Key: CALCITE-2157 > URL: https://issues.apache.org/jira/browse/CALCITE-2157 > Project: Calcite > Issue Type: New Feature > Components: jdbc-adapter >Reporter: Chris Baynes >Assignee: Julian Hyde >Priority: Major > > ClickHouse is a really fast columnar DBMS for OLAP: > [https://clickhouse.yandex/.|https://clickhouse.yandex/] > It has a jdbc adapter and uses mostly standard sql, though there are > differences (e.g. join syntax, datatypes, function name case-sensitivity). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CALCITE-2157) ClickHouse dialect implementation
[ https://issues.apache.org/jira/browse/CALCITE-2157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Baynes updated CALCITE-2157: -- External issue URL: (was: https://github.com/apache/calcite/pull/618) > ClickHouse dialect implementation > - > > Key: CALCITE-2157 > URL: https://issues.apache.org/jira/browse/CALCITE-2157 > Project: Calcite > Issue Type: New Feature > Components: jdbc-adapter >Reporter: Chris Baynes >Assignee: Chris Baynes >Priority: Major > > ClickHouse is a really fast columnar DBMS for OLAP: > [https://clickhouse.yandex/.|https://clickhouse.yandex/] > It has a jdbc adapter and uses mostly standard sql, though there are > differences (e.g. join syntax, datatypes, function name case-sensitivity). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CALCITE-2157) ClickHouse dialect implementation
[ https://issues.apache.org/jira/browse/CALCITE-2157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Baynes updated CALCITE-2157: -- External issue URL: https://github.com/apache/calcite/pull/618 I have submitted a PR which provides a lot of the basic functionality. It currently does not yet support the ClickHouse join syntax. > ClickHouse dialect implementation > - > > Key: CALCITE-2157 > URL: https://issues.apache.org/jira/browse/CALCITE-2157 > Project: Calcite > Issue Type: New Feature > Components: jdbc-adapter >Reporter: Chris Baynes >Assignee: Chris Baynes >Priority: Major > > ClickHouse is a really fast columnar DBMS for OLAP: > [https://clickhouse.yandex/.|https://clickhouse.yandex/] > It has a jdbc adapter and uses mostly standard sql, though there are > differences (e.g. join syntax, datatypes, function name case-sensitivity). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CALCITE-2157) ClickHouse dialect implementation
Chris Baynes created CALCITE-2157: - Summary: ClickHouse dialect implementation Key: CALCITE-2157 URL: https://issues.apache.org/jira/browse/CALCITE-2157 Project: Calcite Issue Type: New Feature Components: jdbc-adapter Reporter: Chris Baynes Assignee: Chris Baynes ClickHouse is a really fast columnar DBMS for OLAP: [https://clickhouse.yandex/.|https://clickhouse.yandex/] It has a jdbc adapter and uses mostly standard sql, though there are differences (e.g. join syntax, datatypes, function name case-sensitivity). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-1798) In JDBC adapter, generate dialect-specific SQL for FLOOR operator
[
https://issues.apache.org/jira/browse/CALCITE-1798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16311137#comment-16311137
]
Chris Baynes commented on CALCITE-1798:
---
[~julianhyde] This was fixed in
[CALCITE-1826|https://issues.apache.org/jira/browse/CALCITE-1826]. I've closed
the PR now.
> In JDBC adapter, generate dialect-specific SQL for FLOOR operator
> -
>
> Key: CALCITE-1798
> URL: https://issues.apache.org/jira/browse/CALCITE-1798
> Project: Calcite
> Issue Type: Bug
> Components: jdbc-adapter
>Reporter: Chris Baynes
>Assignee: Julian Hyde
> Labels: dialect
> Fix For: 1.13.0
>
>
> The FLOOR operator (on dates) is currently broken for all jdbc dialects.
> The syntax allowed by the parser looks like: "FLOOR(datetime to timeUnit)".
> However no jdbc dialect (as far as I'm aware) actually name the function
> FLOOR:
> In postgres: DATE_TRUNC('year', my_datetime)
> In hsqldb: TRUNC ( my_datetime, '' )
> In oracle: TRUNC(my_datetime, 'YEAR')
> In mysql: There's no direct equivalent in mysql (though it could be emulated
> with some nasty timestamp diffing)
> The other issue is that the timeUnits are sometimes also named differently by
> each dialect (e.g. '' in hsqldb).
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CALCITE-1913) Include DB version in SqlDialect
[ https://issues.apache.org/jira/browse/CALCITE-1913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16169306#comment-16169306 ] Chris Baynes commented on CALCITE-1913: --- Yup, totally fine with removing Handler. The new way of doing things definitely still fits with the idea of what I wanted - to pull out dialect specific handling code. It's also nice that we can now deal with other dialect specifics; not just operator calls. > Include DB version in SqlDialect > > > Key: CALCITE-1913 > URL: https://issues.apache.org/jira/browse/CALCITE-1913 > Project: Calcite > Issue Type: Improvement > Components: core >Affects Versions: 1.13.0 >Reporter: Jess Balint >Assignee: Jess Balint >Priority: Minor > > It would be useful to have the DB version # in the SqlDialect for unparsing -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CALCITE-1328) RelBuilder not pushing down jdbc predicates
[
https://issues.apache.org/jira/browse/CALCITE-1328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16161248#comment-16161248
]
Chris Baynes commented on CALCITE-1328:
---
We have found a solution to this. The LogicalTables used should be converted to
their more efficient versions in the planner, but this doesn't seem to happen
when using the RelBuilder.
What we do now is to override the scan call on the tables in the
FrameworkConfig:
{code}
FrameworkConfig config = Frameworks.newConfigBuilder()
...
.context(Contexts.of(new
RelFactories.TableScanFactory {
@Override RelNode createScan(RelOptCluster
cluster, RelOptTable table) {
RelOptTable.ToRelContext context =
RelOptUtil.getContext(cluster);
return table.toRel(context);
}
}))
{code}
> RelBuilder not pushing down jdbc predicates
> ---
>
> Key: CALCITE-1328
> URL: https://issues.apache.org/jira/browse/CALCITE-1328
> Project: Calcite
> Issue Type: Bug
>Reporter: Chris Baynes
>Assignee: Julian Hyde
>
> Querying a jdbc datasource does not push down any predicates (filters,
> projects, or joins). This seems to be the case no matter whether the database
> is postgres or mysql.
> The lack of push down can be reproduced using the foodmart database and the
> following query:
> {code}
> RelNode root = builder
> .scan("agg_lc_06_sales_fact_1997")
> .filter(builder.call(SqlStdOperatorTable.EQUALS, builder.field(1, 0,
> "time_id"), builder.literal(400)))
> .project(builder.field(1, 0, "time_id"))
> .build();
> {code}
> The full planner trace is
> https://gist.github.com/chris-baynes/79bc39a7e40d3310ca0b9f0cdb34293f
> Here's the cheapest plan from the planner trace:
> {noformat}
> 1064 [main] DEBUG org.apache.calcite.plan.RelOptPlanner - Cheapest plan:
> EnumerableProject(time_id=[$0]): rowcount = 15.0, cumulative cost = {80.0
> rows, 165.0 cpu, 0.0 io}, id = 52
> EnumerableFilter(condition=[=($0, 400)]): rowcount = 15.0, cumulative cost
> = {65.0 rows, 150.0 cpu, 0.0 io}, id = 51
> EnumerableInterpreter: rowcount = 100.0, cumulative cost = {50.0 rows,
> 50.0 cpu, 0.0 io}, id = 50
> BindableTableScan(table=[[source1, agg_lc_06_sales_fact_1997]]):
> rowcount = 100.0, cumulative cost = {1.0 rows, 1.01 cpu, 0.0 io}, id = 41
> 1066 [main] DEBUG org.apache.calcite.plan.RelOptPlanner - Provenance:
> EnumerableProject#52
> direct
>
> rel#30:EnumerableProject.ENUMERABLE.[](input=rel#29:Subset#3.ENUMERABLE.[],time_id=$0)
> call#133 rule [EnumerableProjectRule]
>
> rel#25:LogicalProject.NONE.[](input=rel#24:Subset#3.NONE.[],time_id=$0)
> call#62 rule [FilterProjectTransposeRule]
>
> rel#8:LogicalFilter.NONE.[](input=rel#7:Subset#1.NONE.[],condition==($0, 400))
> no parent
>
> rel#6:LogicalProject.NONE.[](input=rel#5:Subset#0.NONE.[],time_id=$0)
> no parent
> EnumerableFilter#51
> direct
>
> rel#34:EnumerableFilter.ENUMERABLE.[](input=rel#33:Subset#0.ENUMERABLE.[],condition==($0,
> 400))
> call#110 rule [EnumerableFilterRule]
>
> rel#22:LogicalFilter.NONE.[](input=rel#5:Subset#0.NONE.[],condition==($0,
> 400))
> call#62 rule [FilterProjectTransposeRule]
> rel#8 (see above)
> rel#6 (see above)
> EnumerableInterpreter#50
> direct
>
> rel#45:EnumerableInterpreter.ENUMERABLE.[](input=rel#42:Subset#0.BINDABLE.[])
> call#255 rule [EnumerableInterpreterRule]
> rel#42:Subset#0.BINDABLE.[]
> subset rel#42:Subset#0.BINDABLE.[]
> rel#41:BindableTableScan.BINDABLE.[](table=[source1,
> agg_lc_06_sales_fact_1997])
> call#5 rule [BindableTableScanRule]
> rel#0:LogicalTableScan.NONE.[](table=[source1,
> agg_lc_06_sales_fact_1997])
> no parent
> rel#41 (see above)
> {noformat}
> I couldn't reproduce with a testcase in the JdbcAdapterTest. Filters and
> projects against the default hsqldb are always pushed down. I couldn't get
> the tests to use anything other than hsqldb though: using
> -Dcalcite.test.db=postgresql after creating a local foodmart db as the
> foodmart user always throws the exception:
> org.apache.calcite.sql.validate.SqlValidatorException: Table
> 'sales_fact_1997' not found - but the table is definitely there.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CALCITE-1940) Implement dialect specific support for sequences
[ https://issues.apache.org/jira/browse/CALCITE-1940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16157225#comment-16157225 ] Chris Baynes commented on CALCITE-1940: --- [~julianhyde] I think you mean [CALCITE-1913|https://issues.apache.org/jira/browse/CALCITE-1913] where there's a discussion about including the db version in the dialect. > Implement dialect specific support for sequences > > > Key: CALCITE-1940 > URL: https://issues.apache.org/jira/browse/CALCITE-1940 > Project: Calcite > Issue Type: Improvement >Reporter: Christian Beikov >Assignee: Julian Hyde > > The Calcite parser and validator already supports sequences but the push down > to the JDBC level is currently limited. SInce sequences are not supported on > all DBMS every sql dialect should have the possibility to render it's own way > of extracting sequence information or incrementing the value. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CALCITE-1866) dateTime FLOOR to HOUR cause MySQL connector throw SQLException
[ https://issues.apache.org/jira/browse/CALCITE-1866?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16150382#comment-16150382 ] Chris Baynes commented on CALCITE-1866: --- [~wkang] could you push your tests to the branch? I can have a go at getting them to run. > dateTime FLOOR to HOUR cause MySQL connector throw SQLException > --- > > Key: CALCITE-1866 > URL: https://issues.apache.org/jira/browse/CALCITE-1866 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.14.0 > Environment: MySQL 5.6.34 > mysql-connector-java.jar:5.1.39 > Calcite 1.14.0-SNAPSHOT >Reporter: Kang Wang >Assignee: Julian Hyde >Priority: Minor > Labels: easyfix > Fix For: 1.14.0 > > Original Estimate: 1h > Remaining Estimate: 1h > > I execute the sql "select FLOOR(trade_time TO HOUR) ..." > then I get the ResultSet, if time hour is less than 10, I get the following > exception: > -- > java.lang.RuntimeException: java.sql.SQLException: Bad format for Timestamp > '2017-06-30 7:00:00' in column 1. > at Baz$1$1.apply(Unknown Source) > at > org.apache.calcite.runtime.ResultSetEnumerable$ResultSetEnumerator.current(ResultSetEnumerable.java:187) > at > org.apache.calcite.linq4j.Linq4j$EnumeratorIterator.next(Linq4j.java:672) > at > org.apache.calcite.avatica.util.IteratorCursor.next(IteratorCursor.java:46) > at > org.apache.calcite.avatica.AvaticaResultSet.next(AvaticaResultSet.java:239) > at TestCalcite.test028_jdbc(TestCalcite.java:75) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at > org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50) > at > org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at > org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47) > at > org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325) > at > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78) > at > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268) > at org.junit.runners.ParentRunner.run(ParentRunner.java:363) > at org.junit.runners.Suite.runChild(Suite.java:128) > at org.junit.runners.Suite.runChild(Suite.java:27) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268) > at org.junit.runners.ParentRunner.run(ParentRunner.java:363) > at org.junit.runner.JUnitCore.run(JUnitCore.java:137) > at > com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68) > at > com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:51) > at > com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242) > at > com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70) > Caused by: java.sql.SQLException: Bad format for Timestamp '2017-06-30 > 7:00:00' in column 1. > at com.mysql.jdbc.ResultSetRow.getTimestampFast(ResultSetRow.java:1157) > at com.mysql.jdbc.ByteArrayRow.getTimestampFast(ByteArrayRow.java:130) > at > com.mysql.jdbc.ResultSetImpl.getTimestampInternal(ResultSetImpl.java:5946) > at com.mysql.jdbc.ResultSetImpl.getTimestamp(ResultSetImpl.java:5616) > at > org.apache.commons.dbcp.DelegatingResultSet.getTimestamp(DelegatingResultSet.java:250) > at > org.apache.commons.dbcp.DelegatingResultSet.getTimestamp(DelegatingResultSet.java:250) > ... 36 more -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CALCITE-1940) Implement dialect specific support for sequences
[
https://issues.apache.org/jira/browse/CALCITE-1940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16149174#comment-16149174
]
Chris Baynes commented on CALCITE-1940:
---
I tried this out with postgres and noticed a problem - postgres (unlike other
dbs) already returns a list of sequences in the jdbc metadata. So the table map
building fails because of duplicates. It probably makes sense to just always
skip {{SEQUENCE}} and {{TEMPORARY_SEQUENCE}} in the loop, and only get them
from the dialect sequence information.
I can't really comment right now on your dialect handling improvement, since
I'm still not sure why the dialect handling here needs something different than
what already exists. The dialect handlers are already able to push-down calls
to different dbs as long as the planner finds the right plan.
> Implement dialect specific support for sequences
>
>
> Key: CALCITE-1940
> URL: https://issues.apache.org/jira/browse/CALCITE-1940
> Project: Calcite
> Issue Type: Improvement
>Reporter: Christian Beikov
>Assignee: Julian Hyde
>
> The Calcite parser and validator already supports sequences but the push down
> to the JDBC level is currently limited. SInce sequences are not supported on
> all DBMS every sql dialect should have the possibility to render it's own way
> of extracting sequence information or incrementing the value.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CALCITE-1895) Substring operator broken for MSSQL
[
https://issues.apache.org/jira/browse/CALCITE-1895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16106543#comment-16106543
]
Chris Baynes commented on CALCITE-1895:
---
I've updated the PR with the {{throws_}} and {{IllegalArgumentException}} as
you suggested (I never liked the idea of catching the {{AssertionError}} but
didn't see a more appropriate exception at the time).
As for the test I don't see support for mssql in the calcite-test-dataset,
though I can run an instance on aws to try that locally.
If I write that test in {{JdbcAdapterTest}} will it be run against Mssql on
travis-ci? Is there a config of jdbc dbs that are tested against?
> Substring operator broken for MSSQL
> ---
>
> Key: CALCITE-1895
> URL: https://issues.apache.org/jira/browse/CALCITE-1895
> Project: Calcite
> Issue Type: Bug
> Components: jdbc-adapter
>Reporter: Chris Baynes
>Assignee: Julian Hyde
>
> The format mssql uses looks like:
> SUBSTRING(input, start, length)
> but the default is currently to unparse to SUBSTRING(input FROM start FOR
> length)
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CALCITE-1895) Substring operator broken for MSSQL
[ https://issues.apache.org/jira/browse/CALCITE-1895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16104682#comment-16104682 ] Chris Baynes commented on CALCITE-1895: --- I've created a PR for this: https://github.com/apache/calcite/pull/504 I added a notOk method to the RelToSqlConverterTest, as I wanted to be able to write negative tests. In this case Mssql only allows the 3 argument substring, so if the query uses the 2 argument version I want to check the dialect handler will throw an exception. > Substring operator broken for MSSQL > --- > > Key: CALCITE-1895 > URL: https://issues.apache.org/jira/browse/CALCITE-1895 > Project: Calcite > Issue Type: Bug > Components: jdbc-adapter >Reporter: Chris Baynes >Assignee: Julian Hyde > > The format mssql uses looks like: > SUBSTRING(input, start, length) > but the default is currently to unparse to SUBSTRING(input FROM start FOR > length) -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CALCITE-1841) Create handlers for Jdbc dialect specific generated sql
[ https://issues.apache.org/jira/browse/CALCITE-1841?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16099858#comment-16099858 ] Chris Baynes commented on CALCITE-1841: --- I've had a look through and those changes make sense to me. I like the move of the unparseCall directly onto the SqlDialect. Thanks for the review! > Create handlers for Jdbc dialect specific generated sql > --- > > Key: CALCITE-1841 > URL: https://issues.apache.org/jira/browse/CALCITE-1841 > Project: Calcite > Issue Type: Improvement > Components: jdbc-adapter >Reporter: Chris Baynes >Assignee: Julian Hyde > > Currently the only way to generate different sql for dialects is to switch on > the dialect in the unparse method. This is used quite heavily in e.g. > SqlFloorFunction, but there are also switches in: > * SUBSTRING() > * SqlDateLiteral quoting > * SqlTimestampLiteral quoting > * Dialects using different interval literals (e.g. Hsqldb uses & MM > rather than YEAR & MONTH) > * limit/offset construction > * mysql isnull function > * type differences (*) > It would be great to have dialect specific handlers to deal with these, > making testing & addition of new handlers (new dialects, or new overrides for > a given function) much easier in the future. > One suggested path to approach this: > https://issues.apache.org/jira/browse/CALCITE-1798?focusedCommentId=16031609=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16031609 > (*) There is a comment in SqlImplementor that reads "MySQL doesn't have a > VARCHAR type, only CHAR.". Not sure if this was for a very old version of > mysql, but it's certainly not true anymore. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CALCITE-1841) Create handlers for Jdbc dialect specific generated sql
[ https://issues.apache.org/jira/browse/CALCITE-1841?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16096122#comment-16096122 ] Chris Baynes commented on CALCITE-1841: --- Ok, so I've moved things into an unparse subpackage and created singleton instances of each of the handlers. I'm not sure about changing the hard-coded handlers to database products. Would you envision being able to dynamically add a handler to a dialect, or to be able to dynamically use a handler for a specific query use case? Either way I'm not really sure where that would hook in, perhaps a SqlCall could have a handler set on it? > Create handlers for Jdbc dialect specific generated sql > --- > > Key: CALCITE-1841 > URL: https://issues.apache.org/jira/browse/CALCITE-1841 > Project: Calcite > Issue Type: Improvement > Components: jdbc-adapter >Reporter: Chris Baynes >Assignee: Julian Hyde > > Currently the only way to generate different sql for dialects is to switch on > the dialect in the unparse method. This is used quite heavily in e.g. > SqlFloorFunction, but there are also switches in: > * SUBSTRING() > * SqlDateLiteral quoting > * SqlTimestampLiteral quoting > * Dialects using different interval literals (e.g. Hsqldb uses & MM > rather than YEAR & MONTH) > * limit/offset construction > * mysql isnull function > * type differences (*) > It would be great to have dialect specific handlers to deal with these, > making testing & addition of new handlers (new dialects, or new overrides for > a given function) much easier in the future. > One suggested path to approach this: > https://issues.apache.org/jira/browse/CALCITE-1798?focusedCommentId=16031609=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16031609 > (*) There is a comment in SqlImplementor that reads "MySQL doesn't have a > VARCHAR type, only CHAR.". Not sure if this was for a very old version of > mysql, but it's certainly not true anymore. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CALCITE-1841) Create handlers for Jdbc dialect specific generated sql
[ https://issues.apache.org/jira/browse/CALCITE-1841?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16093708#comment-16093708 ] Chris Baynes commented on CALCITE-1841: --- I've created a PR for this: https://github.com/apache/calcite/pull/501 During the refactoring I also noticed this issue: https://issues.apache.org/jira/browse/CALCITE-1895 > Create handlers for Jdbc dialect specific generated sql > --- > > Key: CALCITE-1841 > URL: https://issues.apache.org/jira/browse/CALCITE-1841 > Project: Calcite > Issue Type: Improvement > Components: jdbc-adapter >Reporter: Chris Baynes >Assignee: Julian Hyde > > Currently the only way to generate different sql for dialects is to switch on > the dialect in the unparse method. This is used quite heavily in e.g. > SqlFloorFunction, but there are also switches in: > * SUBSTRING() > * SqlDateLiteral quoting > * SqlTimestampLiteral quoting > * Dialects using different interval literals (e.g. Hsqldb uses & MM > rather than YEAR & MONTH) > * limit/offset construction > * mysql isnull function > * type differences (*) > It would be great to have dialect specific handlers to deal with these, > making testing & addition of new handlers (new dialects, or new overrides for > a given function) much easier in the future. > One suggested path to approach this: > https://issues.apache.org/jira/browse/CALCITE-1798?focusedCommentId=16031609=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16031609 > (*) There is a comment in SqlImplementor that reads "MySQL doesn't have a > VARCHAR type, only CHAR.". Not sure if this was for a very old version of > mysql, but it's certainly not true anymore. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (CALCITE-1895) Substring operator broken for MSSQL
Chris Baynes created CALCITE-1895: - Summary: Substring operator broken for MSSQL Key: CALCITE-1895 URL: https://issues.apache.org/jira/browse/CALCITE-1895 Project: Calcite Issue Type: Bug Components: jdbc-adapter Reporter: Chris Baynes Assignee: Julian Hyde The format mssql uses looks like: SUBSTRING(input, start, length) but the default is currently to unparse to SUBSTRING(input FROM start FOR length) -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CALCITE-1826) Jdbc dialect specific FLOOR fails when in GROUP BY
[ https://issues.apache.org/jira/browse/CALCITE-1826?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16074797#comment-16074797 ] Chris Baynes commented on CALCITE-1826: --- I've created a PR that fixes this: https://github.com/apache/calcite/pull/489 > Jdbc dialect specific FLOOR fails when in GROUP BY > -- > > Key: CALCITE-1826 > URL: https://issues.apache.org/jira/browse/CALCITE-1826 > Project: Calcite > Issue Type: Bug > Components: jdbc-adapter >Reporter: Chris Baynes >Assignee: Julian Hyde > > Currently the SqlFloorFunction sometimes modifies the operands in a SqlCall > (i.e. replaceTimeUnitOperand). This is fine if the floor is only used in a > project, but when used again in an aggregate this modification will change > the aggregate, which will break the unparsing of it there. > This can be reproduced by adding a "group by" to the > RelToSqlConverterTest#testFloor. > SqlBasicCall#clone is a shallow clone so cannot be used to fix the problem > (since the underlying operands are not cloned). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CALCITE-1841) Create handlers for Jdbc dialect specific generated sql
[ https://issues.apache.org/jira/browse/CALCITE-1841?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16073432#comment-16073432 ] Chris Baynes commented on CALCITE-1841: --- I completely agree that the dialect specific translations should be together in one place. But the transformation can even change the function name (floor -> date_trunc). If that's done before unparse it means the SqlFloorFunction unparse could no longer be used, and we'd have to construct some generic SqlCall in the transformation to bypass SqlFloorFunction. That's why I thought it would be nicer to have something like an "OracleSqlFloorFunction extends SqlFloorFunction". The dialect version specifics could also go in that class. Also perhaps the dialect specific function classes could go into their own package. Though I don't know how to plug those things together. Maybe that's too tightly coupling things. > Create handlers for Jdbc dialect specific generated sql > --- > > Key: CALCITE-1841 > URL: https://issues.apache.org/jira/browse/CALCITE-1841 > Project: Calcite > Issue Type: Improvement > Components: jdbc-adapter >Reporter: Chris Baynes >Assignee: Julian Hyde > > Currently the only way to generate different sql for dialects is to switch on > the dialect in the unparse method. This is used quite heavily in e.g. > SqlFloorFunction, but there are also switches in: > * SUBSTRING() > * SqlDateLiteral quoting > * SqlTimestampLiteral quoting > * Dialects using different interval literals (e.g. Hsqldb uses & MM > rather than YEAR & MONTH) > * limit/offset construction > * mysql isnull function > * type differences (*) > It would be great to have dialect specific handlers to deal with these, > making testing & addition of new handlers (new dialects, or new overrides for > a given function) much easier in the future. > One suggested path to approach this: > https://issues.apache.org/jira/browse/CALCITE-1798?focusedCommentId=16031609=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16031609 > (*) There is a comment in SqlImplementor that reads "MySQL doesn't have a > VARCHAR type, only CHAR.". Not sure if this was for a very old version of > mysql, but it's certainly not true anymore. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CALCITE-1866) dateTime FLOOR to HOUR cause MySQL connector throw SQLException
[ https://issues.apache.org/jira/browse/CALCITE-1866?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16070053#comment-16070053 ] Chris Baynes commented on CALCITE-1866: --- Can confirm that this fix makes sense. Hoping to get better test coverage for these types of things once there is a nice separation of the dialect unparsing like https://issues.apache.org/jira/browse/CALCITE-1841 > dateTime FLOOR to HOUR cause MySQL connector throw SQLException > --- > > Key: CALCITE-1866 > URL: https://issues.apache.org/jira/browse/CALCITE-1866 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.14.0 > Environment: MySQL 5.6.34 > mysql-connector-java.jar:5.1.39 > Calcite 1.14.0-SNAPSHOT >Reporter: Kang Wang >Assignee: Julian Hyde >Priority: Minor > Labels: easyfix > Fix For: next, 1.14.0 > > Original Estimate: 1h > Remaining Estimate: 1h > > I execute the sql "select FLOOR(trade_time TO HOUR) ..." > then I get the ResultSet, if time hour is less than 10, I get the following > exception: > -- > java.lang.RuntimeException: java.sql.SQLException: Bad format for Timestamp > '2017-06-30 7:00:00' in column 1. > at Baz$1$1.apply(Unknown Source) > at > org.apache.calcite.runtime.ResultSetEnumerable$ResultSetEnumerator.current(ResultSetEnumerable.java:187) > at > org.apache.calcite.linq4j.Linq4j$EnumeratorIterator.next(Linq4j.java:672) > at > org.apache.calcite.avatica.util.IteratorCursor.next(IteratorCursor.java:46) > at > org.apache.calcite.avatica.AvaticaResultSet.next(AvaticaResultSet.java:239) > at TestCalcite.test028_jdbc(TestCalcite.java:75) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at > org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50) > at > org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at > org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47) > at > org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325) > at > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78) > at > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268) > at org.junit.runners.ParentRunner.run(ParentRunner.java:363) > at org.junit.runners.Suite.runChild(Suite.java:128) > at org.junit.runners.Suite.runChild(Suite.java:27) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268) > at org.junit.runners.ParentRunner.run(ParentRunner.java:363) > at org.junit.runner.JUnitCore.run(JUnitCore.java:137) > at > com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68) > at > com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:51) > at > com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242) > at > com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70) > Caused by: java.sql.SQLException: Bad format for Timestamp '2017-06-30 > 7:00:00' in column 1. > at com.mysql.jdbc.ResultSetRow.getTimestampFast(ResultSetRow.java:1157) > at com.mysql.jdbc.ByteArrayRow.getTimestampFast(ByteArrayRow.java:130) > at > com.mysql.jdbc.ResultSetImpl.getTimestampInternal(ResultSetImpl.java:5946) > at com.mysql.jdbc.ResultSetImpl.getTimestamp(ResultSetImpl.java:5616) > at > org.apache.commons.dbcp.DelegatingResultSet.getTimestamp(DelegatingResultSet.java:250) > at > org.apache.commons.dbcp.DelegatingResultSet.getTimestamp(DelegatingResultSet.java:250) > ... 36 more
[jira] [Commented] (CALCITE-1841) Create handlers for Jdbc dialect specific generated sql
[
https://issues.apache.org/jira/browse/CALCITE-1841?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16050400#comment-16050400
]
Chris Baynes commented on CALCITE-1841:
---
bq. Why not do this before unparsing by transforming the SqlNode tree?
Since most of the dialect specific changes are related to the name of the
function or things like the order of parameters, I think it would be nice to
have handlers like OracleSqlFloorFunction & MysqlSqlFloorFunction. The easiest
way to hook those up afaik is for them to implement the unparse method.
Once inside the unparse method the SqlCall can of course be transformed, but
doing this outside of dialect specific code gets ugly since you have to use
specific strings which are of course not defined anywhere in calcite as enums
or in operator tables ("DATE_TRUNC", "", "MM", etc).
What implementation did you have in mind?
> Create handlers for Jdbc dialect specific generated sql
> ---
>
> Key: CALCITE-1841
> URL: https://issues.apache.org/jira/browse/CALCITE-1841
> Project: Calcite
> Issue Type: Improvement
> Components: jdbc-adapter
>Reporter: Chris Baynes
>Assignee: Julian Hyde
>
> Currently the only way to generate different sql for dialects is to switch on
> the dialect in the unparse method. This is used quite heavily in e.g.
> SqlFloorFunction, but there are also switches in:
> * SUBSTRING()
> * SqlDateLiteral quoting
> * SqlTimestampLiteral quoting
> * Dialects using different interval literals (e.g. Hsqldb uses & MM
> rather than YEAR & MONTH)
> * limit/offset construction
> * mysql isnull function
> * type differences (*)
> It would be great to have dialect specific handlers to deal with these,
> making testing & addition of new handlers (new dialects, or new overrides for
> a given function) much easier in the future.
> One suggested path to approach this:
> https://issues.apache.org/jira/browse/CALCITE-1798?focusedCommentId=16031609=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16031609
> (*) There is a comment in SqlImplementor that reads "MySQL doesn't have a
> VARCHAR type, only CHAR.". Not sure if this was for a very old version of
> mysql, but it's certainly not true anymore.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CALCITE-1840) Date floor is broken when used with reflective schema
[
https://issues.apache.org/jira/browse/CALCITE-1840?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16049735#comment-16049735
]
Chris Baynes commented on CALCITE-1840:
---
This is with the latest version from master
> Date floor is broken when used with reflective schema
> -
>
> Key: CALCITE-1840
> URL: https://issues.apache.org/jira/browse/CALCITE-1840
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Chris Baynes
>Assignee: Julian Hyde
>
> Using the everyTypes reflective schema the following query:
> {code:java}
> select floor("sqlDate" to month) from "s"."everyTypes"
> {code}
> fails with:
> {code}
> Caused by: java.lang.ClassCastException: java.lang.Long cannot be cast to
> java.sql.Date
> at
> org.apache.calcite.avatica.util.AbstractCursor$DateAccessor.getDate(AbstractCursor.java:1031)
> at
> org.apache.calcite.avatica.util.AbstractCursor$DateAccessor.getLong(AbstractCursor.java:1052)
> at
> org.apache.calcite.avatica.util.AbstractCursor$AccessorImpl.getInt(AbstractCursor.java:305)
> at
> org.apache.calcite.avatica.util.AbstractCursor$DateAccessor.getString(AbstractCursor.java:1044)
> at
> org.apache.calcite.avatica.AvaticaResultSet.getString(AvaticaResultSet.java:257)
> at
> org.apache.calcite.test.CalciteAssert$ResultSetFormatter.rowToString(CalciteAssert.java:1720)
> at
> org.apache.calcite.test.CalciteAssert$ResultSetFormatter.toStringList(CalciteAssert.java:1738)
> at
> org.apache.calcite.test.CalciteAssert.toStringList(CalciteAssert.java:611)
> at org.apache.calcite.test.CalciteAssert$9.apply(CalciteAssert.java:383)
> at org.apache.calcite.test.CalciteAssert$9.apply(CalciteAssert.java:375)
> at
> org.apache.calcite.test.CalciteAssert.assertQuery(CalciteAssert.java:533)
> at
> org.apache.calcite.test.CalciteAssert$AssertQuery.returns(CalciteAssert.java:1266)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (CALCITE-1841) Create handlers for Jdbc dialect specific generated sql
Chris Baynes created CALCITE-1841: - Summary: Create handlers for Jdbc dialect specific generated sql Key: CALCITE-1841 URL: https://issues.apache.org/jira/browse/CALCITE-1841 Project: Calcite Issue Type: Improvement Components: jdbc-adapter Reporter: Chris Baynes Assignee: Julian Hyde Currently the only way to generate different sql for dialects is to switch on the dialect in the unparse method. This is used quite heavily in e.g. SqlFloorFunction, but there are also switches in: * SUBSTRING() * SqlDateLiteral quoting * SqlTimestampLiteral quoting * Dialects using different interval literals (e.g. Hsqldb uses & MM rather than YEAR & MONTH) * limit/offset construction * mysql isnull function * type differences (*) It would be great to have dialect specific handlers to deal with these, making testing & addition of new handlers (new dialects, or new overrides for a given function) much easier in the future. One suggested path to approach this: https://issues.apache.org/jira/browse/CALCITE-1798?focusedCommentId=16031609=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16031609 (*) There is a comment in SqlImplementor that reads "MySQL doesn't have a VARCHAR type, only CHAR.". Not sure if this was for a very old version of mysql, but it's certainly not true anymore. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CALCITE-1840) Date floor is broken when used with reflective schema
[
https://issues.apache.org/jira/browse/CALCITE-1840?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16049134#comment-16049134
]
Chris Baynes commented on CALCITE-1840:
---
It's instructive to see how a more complex query fails (floor in group by, and
another field in the select):
{code}
select floor("sqlDate" to month), min("sqlTimestamp")
from "s"."everyTypes"
group by floor("sqlDate" to month)
{code}
now fails with:
{code}
Caused by: java.lang.ClassCastException: java.lang.Long cannot be cast to
java.sql.Date
at Baz$2.apply(Unknown Source)
at Baz$2.apply(Unknown Source)
at
org.apache.calcite.linq4j.EnumerableDefaults.groupBy_(EnumerableDefaults.java:828)
at
org.apache.calcite.linq4j.EnumerableDefaults.groupBy(EnumerableDefaults.java:761)
at
org.apache.calcite.linq4j.DefaultEnumerable.groupBy(DefaultEnumerable.java:302)
at Baz.bind(Unknown Source)
at
org.apache.calcite.jdbc.CalcitePrepare$CalciteSignature.enumerable(CalcitePrepare.java:335)
at
org.apache.calcite.jdbc.CalciteConnectionImpl.enumerable(CalciteConnectionImpl.java:294)
at
org.apache.calcite.jdbc.CalciteMetaImpl._createIterable(CalciteMetaImpl.java:559)
at
org.apache.calcite.jdbc.CalciteMetaImpl.createIterable(CalciteMetaImpl.java:550)
at
org.apache.calcite.avatica.AvaticaResultSet.execute(AvaticaResultSet.java:204)
at
org.apache.calcite.jdbc.CalciteResultSet.execute(CalciteResultSet.java:67)
at
org.apache.calcite.jdbc.CalciteResultSet.execute(CalciteResultSet.java:44)
at
org.apache.calcite.avatica.AvaticaConnection$1.execute(AvaticaConnection.java:630)
at
org.apache.calcite.jdbc.CalciteMetaImpl.prepareAndExecute(CalciteMetaImpl.java:607)
at
org.apache.calcite.avatica.AvaticaConnection.prepareAndExecuteInternal(AvaticaConnection.java:638)
at
org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:149)
{code}
The interesting part of the generated code is here:
{code:java}
public Object current() {
final org.apache.calcite.test.ReflectiveSchemaTest.EveryType current =
(org.apache.calcite.test.ReflectiveSchemaTest.EveryType)
inputEnumerator.current();
final java.sql.Date inp16_ = current.sqlDate;
return new Object[] {
inp16_ == null ? (Long) null :
Long.valueOf(org.apache.calcite.avatica.util.DateTimeUtils.unixDateFloor(org.apache.calcite.avatica.util.TimeUnitRange.MONTH,
org.apache.calcite.runtime.SqlFunctions.floor(org.apache.calcite.runtime.SqlFunctions.toIntOptional(inp16_).intValue(),
$L4J$C$Integer_valueOf_8640_intValue_))),
current.sqlTimestamp};
}
static final int $L4J$C$Integer_valueOf_8640_intValue_ =
Integer.valueOf(8640).intValue();
...
};
return child.groupBy(new org.apache.calcite.linq4j.function.Function1() {
public java.sql.Date apply(Object[] a0) {
return (java.sql.Date) a0[0];
}
public Object apply(Object a0) {
return apply(
(Object[]) a0);
}
}
{code}
The first problem is the casting of a Long to Date (in apply), but once that's
fixed there's another problem:
SqlFunctions.floor - inp16_ (the Date) is cast to an int (which already
converts from unix timestamp millis to days since epoch), and when floored with
the large 8640 (millis per day) will be zero.
I think the floor is just unnecessary here.
> Date floor is broken when used with reflective schema
> -
>
> Key: CALCITE-1840
> URL: https://issues.apache.org/jira/browse/CALCITE-1840
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Chris Baynes
>Assignee: Julian Hyde
>
> Using the everyTypes reflective schema the following query:
> {code:java}
> select floor("sqlDate" to month) from "s"."everyTypes"
> {code}
> fails with:
> {code}
> Caused by: java.lang.ClassCastException: java.lang.Long cannot be cast to
> java.sql.Date
> at
> org.apache.calcite.avatica.util.AbstractCursor$DateAccessor.getDate(AbstractCursor.java:1031)
> at
> org.apache.calcite.avatica.util.AbstractCursor$DateAccessor.getLong(AbstractCursor.java:1052)
> at
> org.apache.calcite.avatica.util.AbstractCursor$AccessorImpl.getInt(AbstractCursor.java:305)
> at
> org.apache.calcite.avatica.util.AbstractCursor$DateAccessor.getString(AbstractCursor.java:1044)
> at
> org.apache.calcite.avatica.AvaticaResultSet.getString(AvaticaResultSet.java:257)
> at
> org.apache.calcite.test.CalciteAssert$ResultSetFormatter.rowToString(CalciteAssert.java:1720)
> at
> org.apache.calcite.test.CalciteAssert$ResultSetFormatter.toStringList(CalciteAssert.java:1738)
> at
> org.apache.calcite.test.CalciteAssert.toStringList(CalciteAssert.java:611)
>
[jira] [Created] (CALCITE-1840) Date floor is broken when used with reflective schema
Chris Baynes created CALCITE-1840:
-
Summary: Date floor is broken when used with reflective schema
Key: CALCITE-1840
URL: https://issues.apache.org/jira/browse/CALCITE-1840
Project: Calcite
Issue Type: Bug
Components: core
Reporter: Chris Baynes
Assignee: Julian Hyde
Using the everyTypes reflective schema the following query:
{code:java}
select floor("sqlDate" to month) from "s"."everyTypes"
{code}
fails with:
{code}
Caused by: java.lang.ClassCastException: java.lang.Long cannot be cast to
java.sql.Date
at
org.apache.calcite.avatica.util.AbstractCursor$DateAccessor.getDate(AbstractCursor.java:1031)
at
org.apache.calcite.avatica.util.AbstractCursor$DateAccessor.getLong(AbstractCursor.java:1052)
at
org.apache.calcite.avatica.util.AbstractCursor$AccessorImpl.getInt(AbstractCursor.java:305)
at
org.apache.calcite.avatica.util.AbstractCursor$DateAccessor.getString(AbstractCursor.java:1044)
at
org.apache.calcite.avatica.AvaticaResultSet.getString(AvaticaResultSet.java:257)
at
org.apache.calcite.test.CalciteAssert$ResultSetFormatter.rowToString(CalciteAssert.java:1720)
at
org.apache.calcite.test.CalciteAssert$ResultSetFormatter.toStringList(CalciteAssert.java:1738)
at
org.apache.calcite.test.CalciteAssert.toStringList(CalciteAssert.java:611)
at org.apache.calcite.test.CalciteAssert$9.apply(CalciteAssert.java:383)
at org.apache.calcite.test.CalciteAssert$9.apply(CalciteAssert.java:375)
at
org.apache.calcite.test.CalciteAssert.assertQuery(CalciteAssert.java:533)
at
org.apache.calcite.test.CalciteAssert$AssertQuery.returns(CalciteAssert.java:1266)
{code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CALCITE-1798) In JDBC adapter, generate dialect-specific SQL for FLOOR operator
[
https://issues.apache.org/jira/browse/CALCITE-1798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16032794#comment-16032794
]
Chris Baynes commented on CALCITE-1798:
---
I'll log another JIRA case with the proposed mechanism.
Just have one other issue with the current implementation - I've just noticed
that the same node can be referenced by different parts of the query.
For example if I add a GROUP BY clause using the same FLOOR operator, the
setOperator call I've used will be applied to the SqlCall of the GROUP BY and
then the unparse method will break when it is called on it later on.
To fix that I'm using clone before setOperator, but needed to adjust the clone
method on SqlBasicCall to make sure it clones the operands too.
The PR is here: https://github.com/apache/calcite/pull/465
> In JDBC adapter, generate dialect-specific SQL for FLOOR operator
> -
>
> Key: CALCITE-1798
> URL: https://issues.apache.org/jira/browse/CALCITE-1798
> Project: Calcite
> Issue Type: Bug
> Components: jdbc-adapter
>Reporter: Chris Baynes
>Assignee: Julian Hyde
> Labels: dialect
> Fix For: 1.13.0
>
>
> The FLOOR operator (on dates) is currently broken for all jdbc dialects.
> The syntax allowed by the parser looks like: "FLOOR(datetime to timeUnit)".
> However no jdbc dialect (as far as I'm aware) actually name the function
> FLOOR:
> In postgres: DATE_TRUNC('year', my_datetime)
> In hsqldb: TRUNC ( my_datetime, '' )
> In oracle: TRUNC(my_datetime, 'YEAR')
> In mysql: There's no direct equivalent in mysql (though it could be emulated
> with some nasty timestamp diffing)
> The other issue is that the timeUnits are sometimes also named differently by
> each dialect (e.g. '' in hsqldb).
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (CALCITE-1798) In JDBC adapter, generate dialect-specific SQL for FLOOR operator
[
https://issues.apache.org/jira/browse/CALCITE-1798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16028329#comment-16028329
]
Chris Baynes commented on CALCITE-1798:
---
I've opened a new pull request here for the rest of the changes, with a couple
of fixes and tests: https://github.com/apache/calcite/pull/458
Again, I'm not totally happy with the structure - it would be nice to be able
to split the floor operator into one file for each dialect.
There will be more operators that require this kind of switching and having a
common place to override the operator unparsing per dialect would keep those
switches to a minimum.
> In JDBC adapter, generate dialect-specific SQL for FLOOR operator
> -
>
> Key: CALCITE-1798
> URL: https://issues.apache.org/jira/browse/CALCITE-1798
> Project: Calcite
> Issue Type: Bug
> Components: jdbc-adapter
>Reporter: Chris Baynes
>Assignee: Julian Hyde
> Labels: dialect
> Fix For: 1.13.0
>
>
> The FLOOR operator (on dates) is currently broken for all jdbc dialects.
> The syntax allowed by the parser looks like: "FLOOR(datetime to timeUnit)".
> However no jdbc dialect (as far as I'm aware) actually name the function
> FLOOR:
> In postgres: DATE_TRUNC('year', my_datetime)
> In hsqldb: TRUNC ( my_datetime, '' )
> In oracle: TRUNC(my_datetime, 'YEAR')
> In mysql: There's no direct equivalent in mysql (though it could be emulated
> with some nasty timestamp diffing)
> The other issue is that the timeUnits are sometimes also named differently by
> each dialect (e.g. '' in hsqldb).
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (CALCITE-1798) Jdbc dialect specific datetime floor operators
[
https://issues.apache.org/jira/browse/CALCITE-1798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16018852#comment-16018852
]
Chris Baynes commented on CALCITE-1798:
---
I've made a first pass at this: [https://github.com/apache/calcite/pull/453]
Have a couple of things I'd like to improve & get feedback on though:
1. The convertToHsqlDb method isn't at all specific to flooring, it could also
be used in other timestamp functions. Where would be a good place to create
hsql dialect specifics?
2. Would like to write some dialect specific tests to check the generated sql
output, perhaps a JdbcDialectTest class. Is this possible without having the
actual db available?
I'll fill out the switch with the other dialects as soon as there's agreement
that this looks like it's going in the right direction.
> Jdbc dialect specific datetime floor operators
> --
>
> Key: CALCITE-1798
> URL: https://issues.apache.org/jira/browse/CALCITE-1798
> Project: Calcite
> Issue Type: Bug
>Reporter: Chris Baynes
>Assignee: Julian Hyde
>
> The FLOOR operator (on dates) is currently broken for all jdbc dialects.
> The syntax allowed by the parser looks like: "FLOOR(datetime to timeUnit)".
> However no jdbc dialect (as far as I'm aware) actually name the function
> FLOOR:
> In postgres: DATE_TRUNC('year', my_datetime)
> In hsqldb: TRUNC ( my_datetime, '' )
> In oracle: TRUNC(my_datetime, 'YEAR')
> In mysql: There's no direct equivalent in mysql (though it could be emulated
> with some nasty timestamp diffing)
> The other issue is that the timeUnits are sometimes also named differently by
> each dialect (e.g. '' in hsqldb).
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (CALCITE-1798) Jdbc dialect specific datetime floor operators
Chris Baynes created CALCITE-1798:
-
Summary: Jdbc dialect specific datetime floor operators
Key: CALCITE-1798
URL: https://issues.apache.org/jira/browse/CALCITE-1798
Project: Calcite
Issue Type: Bug
Reporter: Chris Baynes
Assignee: Julian Hyde
The FLOOR operator (on dates) is currently broken for all jdbc dialects.
The syntax allowed by the parser looks like: "FLOOR(datetime to timeUnit)".
However no jdbc dialect (as far as I'm aware) actually name the function FLOOR:
In postgres: DATE_TRUNC('year', my_datetime)
In hsqldb: TRUNC ( my_datetime, '' )
In oracle: TRUNC(my_datetime, 'YEAR')
In mysql: There's no direct equivalent in mysql (though it could be emulated
with some nasty timestamp diffing)
The other issue is that the timeUnits are sometimes also named differently by
each dialect (e.g. '' in hsqldb).
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (CALCITE-1793) Allow RelBuilder to make calls to EXTRACT
[
https://issues.apache.org/jira/browse/CALCITE-1793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16014438#comment-16014438
]
Chris Baynes commented on CALCITE-1793:
---
After taking another look at this I've realised it could be a problem with the
jdbc adapter for the extract function.
Direct execution of the `select extract(year from date '2008-2-23') from
"foodmart"."employee"` fails with:
{code}
Caused by: java.lang.UnsupportedOperationException: class
org.apache.calcite.sql.SqlSyntax$6: SPECIAL
at org.apache.calcite.util.Util.needToImplement(Util.java:925)
at org.apache.calcite.sql.SqlSyntax$6.unparse(SqlSyntax.java:116)
{code}
>From my understanding EXTRACT is converted to an EXTRACT_DATE containing a
>literal and a reinterpret.
EXTRACT has an unparse method which is called in the preparation & validation
phases and works fine.
EXTRACT_DATE.unparse is eventually called by
JdbcToEnumerableConverter.generateSql which raises the above exception.
What's the reason for converting the extract -> extract_date? Seems like this
should be an extract op before converting to sql which gets fired off against
the physical db.
JdbcTest.testExtract passes right now since it doesn't use a FROM clause and so
doesn't go through the jdbc converter.
Fixing the EXTRACT_DATE unparse method seems like the wrong thing to do. Do you
have any ideas for the right way to go about fixing this?
> Allow RelBuilder to make calls to EXTRACT
> -
>
> Key: CALCITE-1793
> URL: https://issues.apache.org/jira/browse/CALCITE-1793
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.11.0, 1.12.0
>Reporter: Chris Baynes
>Assignee: Julian Hyde
>Priority: Minor
>
> EXTRACT_DATE was originally intended to be an internal function, always
> created by translating a call to EXTRACT.
> Currently this makes the EXTRACT_DATE function rather awkward to use:
> {code}
> SqlOperator op = new SqlSpecialOperator("EXTRACT_DATE", SqlKind.EXTRACT, 2,
> true, ReturnTypes.INTEGER, null, null);
> builder.call(op, builder.getRexBuilder().makeFlag(TimeUnitRange.YEAR),
> builder.field(1, 0, "my_date"));
> {code}
> [~julianhyde] suggests calling EXTRACT directly and then have RelBuilder
> invoke a convertlet to translate into calls to EXTRACT_DATE or date-time
> arithmetic.
> Mailing list discussion:
> [http://mail-archives.apache.org/mod_mbox/calcite-dev/201705.mbox/%3CCAPSgeET9OVWkvGsGXAezqhqP3Zd2dmXxs0k-J92WZM32%2BMq3kw%40mail.gmail.com%3E]
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (CALCITE-1793) Allow RelBuilder to make calls to EXTRACT
[
https://issues.apache.org/jira/browse/CALCITE-1793?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris Baynes updated CALCITE-1793:
--
Description:
EXTRACT_DATE was originally intended to be an internal function, always created
by translating a call to EXTRACT.
Currently this makes the EXTRACT_DATE function rather awkward to use:
{code}
SqlOperator op = new SqlSpecialOperator("EXTRACT_DATE", SqlKind.EXTRACT, 2,
true, ReturnTypes.INTEGER, null, null);
builder.call(op, builder.getRexBuilder().makeFlag(TimeUnitRange.YEAR),
builder.field(1, 0, "my_date"));
{code}
[~julianhyde] suggests calling EXTRACT directly and then have RelBuilder invoke
a convertlet to translate into calls to EXTRACT_DATE or date-time arithmetic.
Mailing list discussion:
[http://mail-archives.apache.org/mod_mbox/calcite-dev/201705.mbox/%3CCAPSgeET9OVWkvGsGXAezqhqP3Zd2dmXxs0k-J92WZM32%2BMq3kw%40mail.gmail.com%3E]
was:
EXTRACT_DATE was originally intended to be an internal function, always created
by translating a call to EXTRACT.
Currently this makes the EXTRACT_DATE function rather awkward to use:
{code}
SqlOperator op = new SqlSpecialOperator("EXTRACT_DATE", SqlKind.EXTRACT, 2,
true, ReturnTypes.INTEGER, null, null);
builder.call(op, builder.getRexBuilder().makeFlag(TimeUnitRange.YEAR),
builder.field(1, 0, "my_date"));
{code}
[~julianhyde] suggests calling EXTRACT directly and then have RelBuilder invoke
a convertlet to translate into calls to EXTRACT_DATE or date-time arithmetic:
[http://mail-archives.apache.org/mod_mbox/calcite-dev/201705.mbox/%3CCAPSgeET9OVWkvGsGXAezqhqP3Zd2dmXxs0k-J92WZM32%2BMq3kw%40mail.gmail.com%3E]
> Allow RelBuilder to make calls to EXTRACT
> -
>
> Key: CALCITE-1793
> URL: https://issues.apache.org/jira/browse/CALCITE-1793
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.11.0, 1.12.0
>Reporter: Chris Baynes
>Assignee: Julian Hyde
>Priority: Minor
>
> EXTRACT_DATE was originally intended to be an internal function, always
> created by translating a call to EXTRACT.
> Currently this makes the EXTRACT_DATE function rather awkward to use:
> {code}
> SqlOperator op = new SqlSpecialOperator("EXTRACT_DATE", SqlKind.EXTRACT, 2,
> true, ReturnTypes.INTEGER, null, null);
> builder.call(op, builder.getRexBuilder().makeFlag(TimeUnitRange.YEAR),
> builder.field(1, 0, "my_date"));
> {code}
> [~julianhyde] suggests calling EXTRACT directly and then have RelBuilder
> invoke a convertlet to translate into calls to EXTRACT_DATE or date-time
> arithmetic.
> Mailing list discussion:
> [http://mail-archives.apache.org/mod_mbox/calcite-dev/201705.mbox/%3CCAPSgeET9OVWkvGsGXAezqhqP3Zd2dmXxs0k-J92WZM32%2BMq3kw%40mail.gmail.com%3E]
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (CALCITE-1793) Allow RelBuilder to make calls to EXTRACT
[
https://issues.apache.org/jira/browse/CALCITE-1793?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris Baynes updated CALCITE-1793:
--
Description:
EXTRACT_DATE was originally intended to be an internal function, always created
by translating a call to EXTRACT.
Currently this makes the EXTRACT_DATE function rather awkward to use:
{code}
SqlOperator op = new SqlSpecialOperator("EXTRACT_DATE", SqlKind.EXTRACT, 2,
true, ReturnTypes.INTEGER, null, null);
builder.call(op, builder.getRexBuilder().makeFlag(TimeUnitRange.YEAR),
builder.field(1, 0, "my_date"));
{code}
[~julianhyde] suggests calling EXTRACT directly and then have RelBuilder invoke
a convertlet to translate into calls to EXTRACT_DATE or date-time arithmetic:
[http://mail-archives.apache.org/mod_mbox/calcite-dev/201705.mbox/%3CCAPSgeET9OVWkvGsGXAezqhqP3Zd2dmXxs0k-J92WZM32%2BMq3kw%40mail.gmail.com%3E]
was:
EXTRACT_DATE was originally intended
to be an internal function, always created by translating a call to
EXTRACT.
Currently this makes the EXTRACT_DATE function rather awkward to use:
{code}
SqlOperator op = new SqlSpecialOperator("EXTRACT_DATE", SqlKind.EXTRACT, 2,
true, ReturnTypes.INTEGER, null, null);
builder.call(op, builder.getRexBuilder().makeFlag(TimeUnitRange.YEAR),
builder.field(1, 0, "my_date"));
{code}
[~julianhyde] suggests calling EXTRACT directly and then have
RelBuilder invoke a convertlet to translate into calls to
EXTRACT_DATE or date-time arithmetic:
[http://mail-archives.apache.org/mod_mbox/calcite-dev/201705.mbox/%3CCAPSgeET9OVWkvGsGXAezqhqP3Zd2dmXxs0k-J92WZM32%2BMq3kw%40mail.gmail.com%3E]
> Allow RelBuilder to make calls to EXTRACT
> -
>
> Key: CALCITE-1793
> URL: https://issues.apache.org/jira/browse/CALCITE-1793
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.11.0, 1.12.0
>Reporter: Chris Baynes
>Assignee: Julian Hyde
>Priority: Minor
>
> EXTRACT_DATE was originally intended to be an internal function, always
> created by translating a call to EXTRACT.
> Currently this makes the EXTRACT_DATE function rather awkward to use:
> {code}
> SqlOperator op = new SqlSpecialOperator("EXTRACT_DATE", SqlKind.EXTRACT, 2,
> true, ReturnTypes.INTEGER, null, null);
> builder.call(op, builder.getRexBuilder().makeFlag(TimeUnitRange.YEAR),
> builder.field(1, 0, "my_date"));
> {code}
> [~julianhyde] suggests calling EXTRACT directly and then have RelBuilder
> invoke a convertlet to translate into calls to EXTRACT_DATE or date-time
> arithmetic:
> [http://mail-archives.apache.org/mod_mbox/calcite-dev/201705.mbox/%3CCAPSgeET9OVWkvGsGXAezqhqP3Zd2dmXxs0k-J92WZM32%2BMq3kw%40mail.gmail.com%3E]
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (CALCITE-1328) RelBuilder not pushing down jdbc predicates
[
https://issues.apache.org/jira/browse/CALCITE-1328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15393685#comment-15393685
]
Chris Baynes commented on CALCITE-1328:
---
Ah ok, didn't realise the rules had to be manually configured. So I've tried
that now, but it doesn't seem make any difference to the planner trace.
Here's what I tried:
{code}
JdbcConvention out = JdbcConvention.of(null, null, "postgresconv");
List rules = JdbcRules.rules(out);
Program program = Programs.ofRules(rules);
FrameworkConfig config = Frameworks.newConfigBuilder()
.defaultSchema(rootSchema.getSubSchema("source1"))
.parserConfig(SqlParser.Config.DEFAULT)
.programs(program)
.build();
RelBuilder builder = RelBuilder.create(config);
RelNode root = builder
.scan("agg_lc_06_sales_fact_1997")
.filter(builder.call(SqlStdOperatorTable.EQUALS,
builder.field(1, 0, "time_id"), builder.literal(400)))
.project(builder.field(1, 0, "time_id"))
.build();
{code}
Perhaps you can see what I'm doing wrong there?
> RelBuilder not pushing down jdbc predicates
> ---
>
> Key: CALCITE-1328
> URL: https://issues.apache.org/jira/browse/CALCITE-1328
> Project: Calcite
> Issue Type: Bug
>Reporter: Chris Baynes
>Assignee: Julian Hyde
>
> Querying a jdbc datasource does not push down any predicates (filters,
> projects, or joins). This seems to be the case no matter whether the database
> is postgres or mysql.
> The lack of push down can be reproduced using the foodmart database and the
> following query:
> {code}
> RelNode root = builder
> .scan("agg_lc_06_sales_fact_1997")
> .filter(builder.call(SqlStdOperatorTable.EQUALS, builder.field(1, 0,
> "time_id"), builder.literal(400)))
> .project(builder.field(1, 0, "time_id"))
> .build();
> {code}
> The full planner trace is
> https://gist.github.com/chris-baynes/79bc39a7e40d3310ca0b9f0cdb34293f
> Here's the cheapest plan from the planner trace:
> {noformat}
> 1064 [main] DEBUG org.apache.calcite.plan.RelOptPlanner - Cheapest plan:
> EnumerableProject(time_id=[$0]): rowcount = 15.0, cumulative cost = {80.0
> rows, 165.0 cpu, 0.0 io}, id = 52
> EnumerableFilter(condition=[=($0, 400)]): rowcount = 15.0, cumulative cost
> = {65.0 rows, 150.0 cpu, 0.0 io}, id = 51
> EnumerableInterpreter: rowcount = 100.0, cumulative cost = {50.0 rows,
> 50.0 cpu, 0.0 io}, id = 50
> BindableTableScan(table=[[source1, agg_lc_06_sales_fact_1997]]):
> rowcount = 100.0, cumulative cost = {1.0 rows, 1.01 cpu, 0.0 io}, id = 41
> 1066 [main] DEBUG org.apache.calcite.plan.RelOptPlanner - Provenance:
> EnumerableProject#52
> direct
>
> rel#30:EnumerableProject.ENUMERABLE.[](input=rel#29:Subset#3.ENUMERABLE.[],time_id=$0)
> call#133 rule [EnumerableProjectRule]
>
> rel#25:LogicalProject.NONE.[](input=rel#24:Subset#3.NONE.[],time_id=$0)
> call#62 rule [FilterProjectTransposeRule]
>
> rel#8:LogicalFilter.NONE.[](input=rel#7:Subset#1.NONE.[],condition==($0, 400))
> no parent
>
> rel#6:LogicalProject.NONE.[](input=rel#5:Subset#0.NONE.[],time_id=$0)
> no parent
> EnumerableFilter#51
> direct
>
> rel#34:EnumerableFilter.ENUMERABLE.[](input=rel#33:Subset#0.ENUMERABLE.[],condition==($0,
> 400))
> call#110 rule [EnumerableFilterRule]
>
> rel#22:LogicalFilter.NONE.[](input=rel#5:Subset#0.NONE.[],condition==($0,
> 400))
> call#62 rule [FilterProjectTransposeRule]
> rel#8 (see above)
> rel#6 (see above)
> EnumerableInterpreter#50
> direct
>
> rel#45:EnumerableInterpreter.ENUMERABLE.[](input=rel#42:Subset#0.BINDABLE.[])
> call#255 rule [EnumerableInterpreterRule]
> rel#42:Subset#0.BINDABLE.[]
> subset rel#42:Subset#0.BINDABLE.[]
> rel#41:BindableTableScan.BINDABLE.[](table=[source1,
> agg_lc_06_sales_fact_1997])
> call#5 rule [BindableTableScanRule]
> rel#0:LogicalTableScan.NONE.[](table=[source1,
> agg_lc_06_sales_fact_1997])
> no parent
> rel#41 (see above)
> {noformat}
> I couldn't reproduce with a testcase in the JdbcAdapterTest. Filters and
> projects against the default hsqldb are always pushed down. I couldn't get
> the tests to use anything other than hsqldb though: using
> -Dcalcite.test.db=postgresql after creating a local foodmart db as the
> foodmart user always throws the exception:
> org.apache.calcite.sql.validate.SqlValidatorException: Table
> 'sales_fact_1997' not found - but the table is definitely there.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CALCITE-1328) RelBuilder not pushing down jdbc predicates
[
https://issues.apache.org/jira/browse/CALCITE-1328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15391832#comment-15391832
]
Chris Baynes commented on CALCITE-1328:
---
Before the schemaType property was available I was using JdbcSchema.create, but
the problem was the same.
> RelBuilder not pushing down jdbc predicates
> ---
>
> Key: CALCITE-1328
> URL: https://issues.apache.org/jira/browse/CALCITE-1328
> Project: Calcite
> Issue Type: Bug
>Reporter: Chris Baynes
>Assignee: Julian Hyde
>
> Querying a jdbc datasource does not push down any predicates (filters,
> projects, or joins). This seems to be the case no matter whether the database
> is postgres or mysql.
> The lack of push down can be reproduced using the foodmart database and the
> following query:
> {code}
> RelNode root = builder
> .scan("agg_lc_06_sales_fact_1997")
> .filter(builder.call(SqlStdOperatorTable.EQUALS, builder.field(1, 0,
> "time_id"), builder.literal(400)))
> .project(builder.field(1, 0, "time_id"))
> .build();
> {code}
> The full planner trace is
> https://gist.github.com/chris-baynes/79bc39a7e40d3310ca0b9f0cdb34293f
> Here's the cheapest plan from the planner trace:
> {noformat}
> 1064 [main] DEBUG org.apache.calcite.plan.RelOptPlanner - Cheapest plan:
> EnumerableProject(time_id=[$0]): rowcount = 15.0, cumulative cost = {80.0
> rows, 165.0 cpu, 0.0 io}, id = 52
> EnumerableFilter(condition=[=($0, 400)]): rowcount = 15.0, cumulative cost
> = {65.0 rows, 150.0 cpu, 0.0 io}, id = 51
> EnumerableInterpreter: rowcount = 100.0, cumulative cost = {50.0 rows,
> 50.0 cpu, 0.0 io}, id = 50
> BindableTableScan(table=[[source1, agg_lc_06_sales_fact_1997]]):
> rowcount = 100.0, cumulative cost = {1.0 rows, 1.01 cpu, 0.0 io}, id = 41
> 1066 [main] DEBUG org.apache.calcite.plan.RelOptPlanner - Provenance:
> EnumerableProject#52
> direct
>
> rel#30:EnumerableProject.ENUMERABLE.[](input=rel#29:Subset#3.ENUMERABLE.[],time_id=$0)
> call#133 rule [EnumerableProjectRule]
>
> rel#25:LogicalProject.NONE.[](input=rel#24:Subset#3.NONE.[],time_id=$0)
> call#62 rule [FilterProjectTransposeRule]
>
> rel#8:LogicalFilter.NONE.[](input=rel#7:Subset#1.NONE.[],condition==($0, 400))
> no parent
>
> rel#6:LogicalProject.NONE.[](input=rel#5:Subset#0.NONE.[],time_id=$0)
> no parent
> EnumerableFilter#51
> direct
>
> rel#34:EnumerableFilter.ENUMERABLE.[](input=rel#33:Subset#0.ENUMERABLE.[],condition==($0,
> 400))
> call#110 rule [EnumerableFilterRule]
>
> rel#22:LogicalFilter.NONE.[](input=rel#5:Subset#0.NONE.[],condition==($0,
> 400))
> call#62 rule [FilterProjectTransposeRule]
> rel#8 (see above)
> rel#6 (see above)
> EnumerableInterpreter#50
> direct
>
> rel#45:EnumerableInterpreter.ENUMERABLE.[](input=rel#42:Subset#0.BINDABLE.[])
> call#255 rule [EnumerableInterpreterRule]
> rel#42:Subset#0.BINDABLE.[]
> subset rel#42:Subset#0.BINDABLE.[]
> rel#41:BindableTableScan.BINDABLE.[](table=[source1,
> agg_lc_06_sales_fact_1997])
> call#5 rule [BindableTableScanRule]
> rel#0:LogicalTableScan.NONE.[](table=[source1,
> agg_lc_06_sales_fact_1997])
> no parent
> rel#41 (see above)
> {noformat}
> I couldn't reproduce with a testcase in the JdbcAdapterTest. Filters and
> projects against the default hsqldb are always pushed down. I couldn't get
> the tests to use anything other than hsqldb though: using
> -Dcalcite.test.db=postgresql after creating a local foodmart db as the
> foodmart user always throws the exception:
> org.apache.calcite.sql.validate.SqlValidatorException: Table
> 'sales_fact_1997' not found - but the table is definitely there.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CALCITE-1328) RelBuilder not pushing down jdbc predicates
[
https://issues.apache.org/jira/browse/CALCITE-1328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15391678#comment-15391678
]
Chris Baynes commented on CALCITE-1328:
---
The connection is created with: "jdbc:calcite:schemaType=JDBC". Is there
somewhere else the rules have to be enabled?
> RelBuilder not pushing down jdbc predicates
> ---
>
> Key: CALCITE-1328
> URL: https://issues.apache.org/jira/browse/CALCITE-1328
> Project: Calcite
> Issue Type: Bug
>Reporter: Chris Baynes
>Assignee: Julian Hyde
>
> Querying a jdbc datasource does not push down any predicates (filters,
> projects, or joins). This seems to be the case no matter whether the database
> is postgres or mysql.
> The lack of push down can be reproduced using the foodmart database and the
> following query:
> {code}
> RelNode root = builder
> .scan("agg_lc_06_sales_fact_1997")
> .filter(builder.call(SqlStdOperatorTable.EQUALS, builder.field(1, 0,
> "time_id"), builder.literal(400)))
> .project(builder.field(1, 0, "time_id"))
> .build();
> {code}
> The full planner trace is
> https://gist.github.com/chris-baynes/79bc39a7e40d3310ca0b9f0cdb34293f
> Here's the cheapest plan from the planner trace:
> {noformat}
> 1064 [main] DEBUG org.apache.calcite.plan.RelOptPlanner - Cheapest plan:
> EnumerableProject(time_id=[$0]): rowcount = 15.0, cumulative cost = {80.0
> rows, 165.0 cpu, 0.0 io}, id = 52
> EnumerableFilter(condition=[=($0, 400)]): rowcount = 15.0, cumulative cost
> = {65.0 rows, 150.0 cpu, 0.0 io}, id = 51
> EnumerableInterpreter: rowcount = 100.0, cumulative cost = {50.0 rows,
> 50.0 cpu, 0.0 io}, id = 50
> BindableTableScan(table=[[source1, agg_lc_06_sales_fact_1997]]):
> rowcount = 100.0, cumulative cost = {1.0 rows, 1.01 cpu, 0.0 io}, id = 41
> 1066 [main] DEBUG org.apache.calcite.plan.RelOptPlanner - Provenance:
> EnumerableProject#52
> direct
>
> rel#30:EnumerableProject.ENUMERABLE.[](input=rel#29:Subset#3.ENUMERABLE.[],time_id=$0)
> call#133 rule [EnumerableProjectRule]
>
> rel#25:LogicalProject.NONE.[](input=rel#24:Subset#3.NONE.[],time_id=$0)
> call#62 rule [FilterProjectTransposeRule]
>
> rel#8:LogicalFilter.NONE.[](input=rel#7:Subset#1.NONE.[],condition==($0, 400))
> no parent
>
> rel#6:LogicalProject.NONE.[](input=rel#5:Subset#0.NONE.[],time_id=$0)
> no parent
> EnumerableFilter#51
> direct
>
> rel#34:EnumerableFilter.ENUMERABLE.[](input=rel#33:Subset#0.ENUMERABLE.[],condition==($0,
> 400))
> call#110 rule [EnumerableFilterRule]
>
> rel#22:LogicalFilter.NONE.[](input=rel#5:Subset#0.NONE.[],condition==($0,
> 400))
> call#62 rule [FilterProjectTransposeRule]
> rel#8 (see above)
> rel#6 (see above)
> EnumerableInterpreter#50
> direct
>
> rel#45:EnumerableInterpreter.ENUMERABLE.[](input=rel#42:Subset#0.BINDABLE.[])
> call#255 rule [EnumerableInterpreterRule]
> rel#42:Subset#0.BINDABLE.[]
> subset rel#42:Subset#0.BINDABLE.[]
> rel#41:BindableTableScan.BINDABLE.[](table=[source1,
> agg_lc_06_sales_fact_1997])
> call#5 rule [BindableTableScanRule]
> rel#0:LogicalTableScan.NONE.[](table=[source1,
> agg_lc_06_sales_fact_1997])
> no parent
> rel#41 (see above)
> {noformat}
> I couldn't reproduce with a testcase in the JdbcAdapterTest. Filters and
> projects against the default hsqldb are always pushed down. I couldn't get
> the tests to use anything other than hsqldb though: using
> -Dcalcite.test.db=postgresql after creating a local foodmart db as the
> foodmart user always throws the exception:
> org.apache.calcite.sql.validate.SqlValidatorException: Table
> 'sales_fact_1997' not found - but the table is definitely there.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CALCITE-1328) RelBuilder not pushing down jdbc predicates
Chris Baynes created CALCITE-1328:
-
Summary: RelBuilder not pushing down jdbc predicates
Key: CALCITE-1328
URL: https://issues.apache.org/jira/browse/CALCITE-1328
Project: Calcite
Issue Type: Bug
Reporter: Chris Baynes
Assignee: Julian Hyde
Querying a jdbc datasource does not push down any predicates (filters,
projects, or joins). This seems to be the case no matter whether the database
is postgres or mysql.
The lack of push down can be reproduced using the foodmart database and the
following query:
{code}
RelNode root = builder
.scan("agg_lc_06_sales_fact_1997")
.filter(builder.call(SqlStdOperatorTable.EQUALS, builder.field(1, 0,
"time_id"), builder.literal(400)))
.project(builder.field(1, 0, "time_id"))
.build();
{code}
The full planner trace is
https://gist.github.com/chris-baynes/79bc39a7e40d3310ca0b9f0cdb34293f
Here's the cheapest plan from the planner trace:
1064 [main] DEBUG org.apache.calcite.plan.RelOptPlanner - Cheapest plan:
EnumerableProject(time_id=[$0]): rowcount = 15.0, cumulative cost = {80.0 rows,
165.0 cpu, 0.0 io}, id = 52
EnumerableFilter(condition=[=($0, 400)]): rowcount = 15.0, cumulative cost =
{65.0 rows, 150.0 cpu, 0.0 io}, id = 51
EnumerableInterpreter: rowcount = 100.0, cumulative cost = {50.0 rows, 50.0
cpu, 0.0 io}, id = 50
BindableTableScan(table=[[source1, agg_lc_06_sales_fact_1997]]): rowcount
= 100.0, cumulative cost = {1.0 rows, 1.01 cpu, 0.0 io}, id = 41
1066 [main] DEBUG org.apache.calcite.plan.RelOptPlanner - Provenance:
EnumerableProject#52
direct
rel#30:EnumerableProject.ENUMERABLE.[](input=rel#29:Subset#3.ENUMERABLE.[],time_id=$0)
call#133 rule [EnumerableProjectRule]
rel#25:LogicalProject.NONE.[](input=rel#24:Subset#3.NONE.[],time_id=$0)
call#62 rule [FilterProjectTransposeRule]
rel#8:LogicalFilter.NONE.[](input=rel#7:Subset#1.NONE.[],condition==($0, 400))
no parent
rel#6:LogicalProject.NONE.[](input=rel#5:Subset#0.NONE.[],time_id=$0)
no parent
EnumerableFilter#51
direct
rel#34:EnumerableFilter.ENUMERABLE.[](input=rel#33:Subset#0.ENUMERABLE.[],condition==($0,
400))
call#110 rule [EnumerableFilterRule]
rel#22:LogicalFilter.NONE.[](input=rel#5:Subset#0.NONE.[],condition==($0, 400))
call#62 rule [FilterProjectTransposeRule]
rel#8 (see above)
rel#6 (see above)
EnumerableInterpreter#50
direct
rel#45:EnumerableInterpreter.ENUMERABLE.[](input=rel#42:Subset#0.BINDABLE.[])
call#255 rule [EnumerableInterpreterRule]
rel#42:Subset#0.BINDABLE.[]
subset rel#42:Subset#0.BINDABLE.[]
rel#41:BindableTableScan.BINDABLE.[](table=[source1,
agg_lc_06_sales_fact_1997])
call#5 rule [BindableTableScanRule]
rel#0:LogicalTableScan.NONE.[](table=[source1,
agg_lc_06_sales_fact_1997])
no parent
rel#41 (see above)
I couldn't reproduce with a testcase in the JdbcAdapterTest. Filters and
projects against the default hsqldb are always pushed down. I couldn't get the
tests to use anything other than hsqldb though: using
-Dcalcite.test.db=postgresql after creating a local foodmart db as the foodmart
user always throws the exception:
org.apache.calcite.sql.validate.SqlValidatorException: Table 'sales_fact_1997'
not found - but the table is definitely there.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CALCITE-1264) Litmus fail does not interpolate arguments
[
https://issues.apache.org/jira/browse/CALCITE-1264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15307413#comment-15307413
]
Chris Baynes commented on CALCITE-1264:
---
Here's the PR: https://github.com/apache/calcite/pull/241
> Litmus fail does not interpolate arguments
> --
>
> Key: CALCITE-1264
> URL: https://issues.apache.org/jira/browse/CALCITE-1264
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Chris Baynes
>Assignee: Julian Hyde
> Fix For: 1.8.0
>
>
> Litmus#fail is currently implemented with String.format which does not accept
> a pair of curly brackets '{}' for formatting variables.
> For example,
> litmus.fail("msg is {}", "some error");
> => "msg is {}"
> I see 2 options:
> 1. Change every call to fail that uses {}
> 2. fail should use the sl4j MessageFormatter
> I'm going to open a PR with strategy 2. It's nice to keep the same message
> format as the logger, otherwise it's easy to introduce bugs there. There are
> currently only 2 places that use the "%s" format to call fail, so those can
> be easily changed.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CALCITE-1264) Litmus fail does not interpolate arguments
Chris Baynes created CALCITE-1264:
-
Summary: Litmus fail does not interpolate arguments
Key: CALCITE-1264
URL: https://issues.apache.org/jira/browse/CALCITE-1264
Project: Calcite
Issue Type: Bug
Components: core
Reporter: Chris Baynes
Assignee: Julian Hyde
Litmus#fail is currently implemented with String.format which does not accept a
pair of curly brackets '{}' for formatting variables.
For example,
litmus.fail("msg is {}", "some error");
=> "msg is {}"
I see 2 options:
1. Change every call to fail that uses {}
2. fail should use the sl4j MessageFormatter
I'm going to open a PR with strategy 2. It's nice to keep the same message
format as the logger, otherwise it's easy to introduce bugs there. There are
currently only 2 places that use the "%s" format to call fail, so those can be
easily changed.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CALCITE-1245) Allow RelBuilder scan to take multiple arguments
[ https://issues.apache.org/jira/browse/CALCITE-1245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15299695#comment-15299695 ] Chris Baynes commented on CALCITE-1245: --- [~julianhyde] Have pushed again taking into account your suggestions, and squashed everything into a single commit (that seemed to me the way it has been done in other PRs). > Allow RelBuilder scan to take multiple arguments > > > Key: CALCITE-1245 > URL: https://issues.apache.org/jira/browse/CALCITE-1245 > Project: Calcite > Issue Type: Improvement >Reporter: Chris Baynes >Assignee: Julian Hyde > > Currently Relbuilder.scan takes a single tableName string argument, however > we'd like to use this to specify a sub-schema so we can use the Relbuilder to > construct our queries across datasources. > The idea would be to change "scan(String tableName)" to "scan(String… > tableNames)", and add "scan(Iterable tableNames)". > This is as discussed here: > http://mail-archives.apache.org/mod_mbox/calcite-dev/201605.mbox/%3CE4C0C38B-EDC2-4016-99C1-E7465AAC0C20%40apache.org%3E > Opened this ticket so that we can submit a PR with the change. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
