[
https://issues.apache.org/jira/browse/CALCITE-1054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15096883#comment-15096883
]
Julian Hyde commented on CALCITE-1054:
--------------------------------------
The code generation occurs within RexToLixTranslator. For types that have
primitive representation (such as integer) we insert an 'is not null' check and
then we re-invoke the code generation with the map set so that isKnownNullable
returns FALSE, in which case we can use the primitive representation.
Date, Time, Timestamp are represented as primitive types (int, int, long) but
only after they have been unwrapped. Maybe this unwrapping is taking place at
the wrong time.
> NPE caused by wrong code generation for Timestamp fields
> --------------------------------------------------------
>
> Key: CALCITE-1054
> URL: https://issues.apache.org/jira/browse/CALCITE-1054
> Project: Calcite
> Issue Type: Bug
> Components: core
> Reporter: Frankie Bollaert
> Assignee: Julian Hyde
> Priority: Minor
>
> Problem occurs when:
> - Execute a query containing 2 checks on a Timestamp field
> - Table contains records which have NULL values for this field
> Example query:
> {code}
> select * from aTable where aTimestamp > timestamp '2015-1-1 00:00:00' and
> aTimestamp < timestamp '2015-2-1 00:00:00';
> {code}
> {code}
> /* 48 */ public boolean moveNext() {
> /* 49 */ while (inputEnumerator.moveNext()) {
> /* 50 */ final java.sql.Timestamp inp23_ = (java.sql.Timestamp)
> ((Object[]) inputEnumerator.current())[23];
> /* 51 */ final long v =
> org.apache.calcite.runtime.SqlFunctions.toLong(inp23_);
> /* 52 */ if (inp23_ != null && v > 1420070400000L && (inp23_ != null
> && v < 1422748800000L)) {
> /* 53 */ return true;
> /* 54 */ }
> /* 55 */ }
> /* 56 */ return false;
> /* 57 */ }
> {code}
> Stack trace snippet
> {code}
> Caused by: java.lang.NullPointerException
> at
> org.apache.calcite.runtime.SqlFunctions.toLong(SqlFunctions.java:1094)
> at
> org.apache.calcite.runtime.SqlFunctions.toLong(SqlFunctions.java:1089)
> at Baz$1$1.moveNext(ANONYMOUS.java:51)
> at
> org.apache.calcite.linq4j.Linq4j$EnumeratorIterator.<init>(Linq4j.java:677)
> at org.apache.calcite.linq4j.Linq4j.enumeratorIterator(Linq4j.java:103)
> {code}
> The generated code also looks wrong for date fields.
> {code}
> /* 15 */ public boolean moveNext() {
> /* 16 */ while (inputEnumerator.moveNext()) {
> /* 17 */ final java.sql.Date current = (java.sql.Date)
> inputEnumerator.current();
> /* 18 */ final int v =
> org.apache.calcite.runtime.SqlFunctions.toInt(current);
> /* 19 */ if (current != null && v > 2780 && (current != null && v <
> 5290)) {
> /* 20 */ return true;
> /* 21 */ }
> /* 22 */ }
> /* 23 */ return false;
> /* 24 */ }
> {code}
> \\
> Other types of fields do not have this problem. Below is what the generated
> code looks like in the case of a String field. *On line 20 there is a null
> check.* This is the type of check that needs to be generated for Timestamp
> fields as well.
> {code}
> select empno from sales.emps where gender > 'A' and gender < 'Z';
> {code}
> {code}
> /* 17 */ public boolean moveNext() {
> /* 18 */ while (inputEnumerator.moveNext()) {
> /* 19 */ final Object[] current = (Object[]) inputEnumerator.current();
> /* 20 */ final String inp3_ = current[3] == null ? (String) null :
> current[3].toString();
> /* 21 */ if (inp3_ != null &&
> org.apache.calcite.runtime.SqlFunctions.gt(inp3_,
> $L4J$C$org_apache_calcite_runtime_SqlFunctions_rtrim_A_) && (inp3_ != null &&
> org.apache.calcite.runtime.SqlFunctions.lt(inp3_,
> $L4J$C$org_apache_calcite_runtime_SqlFunctions_rtrim_Z_))) {
> /* 22 */ return true;
> /* 23 */ }
> /* 24 */ }
> /* 25 */ return false;
> /* 26 */ }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
