[ 
https://issues.apache.org/jira/browse/CALCITE-1427?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jan Van Besien updated CALCITE-1427:
------------------------------------
    Description: 
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

  was:
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


> 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 (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
(v6.3.4#6332)

Reply via email to