Jan Van Besien updated CALCITE-1427:
    Attachment: CALCITE_1427_unit_tests.patch

> 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
>         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 (((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

Reply via email to