[
https://issues.apache.org/jira/browse/CALCITE-1427?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde resolved CALCITE-1427.
----------------------------------
Resolution: Fixed
Fix Version/s: 1.16.0
Fixed in
[d1bada42|http://git-wip-us.apache.org/repos/asf/calcite/commit/d1bada42], as
part of the fix for CALCITE-1054.
> Code generation incorrect (does not compile) for DATE, TIME and TIMESTAMP
> fields
> --------------------------------------------------------------------------------
>
> Key: CALCITE-1427
> URL: https://issues.apache.org/jira/browse/CALCITE-1427
> Project: Calcite
> Issue Type: Bug
> Components: core
> Reporter: Jan Van Besien
> Assignee: Julian Hyde
> Priority: Major
> Fix For: 1.16.0
>
> Attachments: CALCITE_1427_unit_tests.patch
>
>
> The generated code for sql queries that filter on DATE, TIME or TIMESTAMP
> fields is incorrect.
> The problem can easily be reproduced with the csv example using a statement
> such as (patch with unit test in attachment).
> {code}
> select EMPNO from "DATE" where JOINEDAT is not null;
> {code}
> or (similar but not exactly the same problem)
> {code}
> select EMPNO from "DATE" where JOINEDAT > {d '1990-01-01'};
> {code}
> In case of the not-null filter, the generated code contains
> {code}
> if (org.apache.calcite.runtime.SqlFunctions.internalToDate(((Object[])
> inputEnumerator.current())[1]) != null) {...}
> {code}
> This seems to be generated in the assumption that the internal representation
> is a long, rather than a java.sql.Date, java.sql.Time or java.sql.Timestamp.
> So first question: is the enumerator supposed to return java.sql.Date,
> java.sql.Time and java.sql.Timestamp values or simply longs (epoch millis).
> Currently it returns java.sql.* types and that is definitely how it used to
> work in older calcite versions.
> In that case the generated code should probably not contain the
> internalToDate function?
> However the mere existence of that function makes me think that maybe the
> enumerators are supposed to return long values. But in that case the
> generated code is also wrong, it should probably be (added cast):
> {code}
> if (org.apache.calcite.runtime.SqlFunctions.internalToDate((Long) ((Object[])
> inputEnumerator.current())[1]) != null) {...}
> {code}
> With the second sql query (greater than filter), the generated code actually
> does contain a cast to Integer (which fails):
> {code}
> final Integer inp1_ = (Integer) ((Object[]) inputEnumerator.current())[1];
> if (inp1_ != null && inp1_.intValue() > 7305) {...}
> {code}
> The cast fails with java.sql.Date cannot be cast to java.lang.Integer
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
