[jira] [Comment Edited] (CALCITE-1054) NPE caused by wrong code generation for Timestamp fields
[
https://issues.apache.org/jira/browse/CALCITE-1054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15102032#comment-15102032
]
Frankie Bollaert edited comment on CALCITE-1054 at 1/18/16 7:59 AM:
Issue occurs on master branch and *not* on branch-1.5
Another date problem that occurs with the CSV example:
{code}
select * from sales.emps e WHERE "JOINEDAT" > date '2010-01-01';
{code}
{code}
/* 17 */ public boolean moveNext() {
/* 18 */while (inputEnumerator.moveNext()) {
/* 19 */ final Integer inp9_ = (Integer) ((Object[])
inputEnumerator.current())[9];
/* 20 */ if (inp9_ != null && inp9_.intValue() > 14610) {
/* 21 */return true;
/* 22 */ }
/* 23 */}
/* 24 */return false;
/* 25 */ }
{code}
{code}
Error: Error while executing SQL "select * from sales.emps e WHERE "JOINEDAT" >
date '2010-01-01'": java.sql.Date cannot be cast to java.lang.Integer
(state=,code=0)
{code}
This issue was introduced by
commit d4bbf58d6e5f4f67ebae412b5a1aae23769eccb7
[CALCITE-1041] User-defined function that returns DATE or TIMESTAMP value
Reverting this commit makes the problem disappear.
Should I make a separate JIRA ticket for this?
was (Author: frankieb):
Issue occurs on master branch and *not* on branch-1.5
Another date problem that occurs with the CSV example:
{code}
select * from sales.emps e WHERE "JOINEDAT" > date '2010-01-01';
{code}
{code}
/* 17 */ public boolean moveNext() {
/* 18 */while (inputEnumerator.moveNext()) {
/* 19 */ final Integer inp9_ = (Integer) ((Object[])
inputEnumerator.current())[9];
/* 20 */ if (inp9_ != null && inp9_.intValue() > 14610) {
/* 21 */return true;
/* 22 */ }
/* 23 */}
/* 24 */return false;
/* 25 */ }
{code}
{code}
Error: Error while executing SQL "select * from sales.emps e WHERE "JOINEDAT" >
date '2010-01-01'": java.sql.Date cannot be cast to java.lang.Integer
(state=,code=0)
{code}
This issue was introduced by
commit d4bbf58d6e5f4f67ebae412b5a1aae23769eccb7
[CALCITE-1041] User-defined function that returns DATE or TIMESTAMP value
Reverting this commit makes the problem disappear.
> 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
>Affects Versions: 1.6.0, 1.5.0, 1.4.0-incubating
>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 > 142007040L && (inp23_ != null
> && v < 142274880L)) {
> /* 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.(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 */
[jira] [Commented] (CALCITE-669) Move from Commons Logging to SLF4J
[ https://issues.apache.org/jira/browse/CALCITE-669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15105581#comment-15105581 ] Josh Elser commented on CALCITE-669: Anyone have opinions on how to map the 3 levels from java logging to the 2 which slf4j provide? Java Logging * FINE * FINER * FINEST Slf4j Levels * DEBUG * TRACE What kind of breakdown would we want here? DEBUG == (FINE and FINER), TRACE == FINEST? DEBUG == FINE, TRACE == (FINER and FINEST)? > Move from Commons Logging to SLF4J > -- > > Key: CALCITE-669 > URL: https://issues.apache.org/jira/browse/CALCITE-669 > Project: Calcite > Issue Type: Task > Components: avatica >Reporter: Nick Dimiduk >Assignee: Josh Elser >Priority: Minor > Fix For: 1.7.0 > > > As mentioned on CALCITE-641, it could be useful to adopt a logging > implementation that supports pluggable backends and has > [MDC|http://www.slf4j.org/manual.html#mdc] support. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CALCITE-669) Move from Commons Logging to SLF4J
[ https://issues.apache.org/jira/browse/CALCITE-669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15105500#comment-15105500 ] Julian Hyde commented on CALCITE-669: - +1 As part of this task, be sure to update the existing doc, such as the HOWTO. > Move from Commons Logging to SLF4J > -- > > Key: CALCITE-669 > URL: https://issues.apache.org/jira/browse/CALCITE-669 > Project: Calcite > Issue Type: Task > Components: avatica >Reporter: Nick Dimiduk >Assignee: Josh Elser >Priority: Minor > Fix For: 1.7.0 > > > As mentioned on CALCITE-641, it could be useful to adopt a logging > implementation that supports pluggable backends and has > [MDC|http://www.slf4j.org/manual.html#mdc] support. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CALCITE-669) Move from Commons Logging to SLF4J
[ https://issues.apache.org/jira/browse/CALCITE-669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15105501#comment-15105501 ] Josh Elser commented on CALCITE-669: Thanks for the reminder. Will look at the docs. > Move from Commons Logging to SLF4J > -- > > Key: CALCITE-669 > URL: https://issues.apache.org/jira/browse/CALCITE-669 > Project: Calcite > Issue Type: Task > Components: avatica >Reporter: Nick Dimiduk >Assignee: Josh Elser >Priority: Minor > Fix For: 1.7.0 > > > As mentioned on CALCITE-641, it could be useful to adopt a logging > implementation that supports pluggable backends and has > [MDC|http://www.slf4j.org/manual.html#mdc] support. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CALCITE-669) Move from Commons Logging to SLF4J
[ https://issues.apache.org/jira/browse/CALCITE-669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh Elser reassigned CALCITE-669: -- Assignee: Josh Elser (was: Julian Hyde) > Move from Commons Logging to SLF4J > -- > > Key: CALCITE-669 > URL: https://issues.apache.org/jira/browse/CALCITE-669 > Project: Calcite > Issue Type: Task > Components: avatica >Reporter: Nick Dimiduk >Assignee: Josh Elser >Priority: Minor > > As mentioned on CALCITE-641, it could be useful to adopt a logging > implementation that supports pluggable backends and has > [MDC|http://www.slf4j.org/manual.html#mdc] support. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CALCITE-669) Move from Commons Logging to SLF4J
[ https://issues.apache.org/jira/browse/CALCITE-669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15105490#comment-15105490 ] Josh Elser commented on CALCITE-669: Going to work on swapping this out. > Move from Commons Logging to SLF4J > -- > > Key: CALCITE-669 > URL: https://issues.apache.org/jira/browse/CALCITE-669 > Project: Calcite > Issue Type: Task > Components: avatica >Reporter: Nick Dimiduk >Assignee: Josh Elser >Priority: Minor > Fix For: 1.7.0 > > > As mentioned on CALCITE-641, it could be useful to adopt a logging > implementation that supports pluggable backends and has > [MDC|http://www.slf4j.org/manual.html#mdc] support. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CALCITE-669) Move from Commons Logging to SLF4J
[ https://issues.apache.org/jira/browse/CALCITE-669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh Elser updated CALCITE-669: --- Fix Version/s: 1.7.0 > Move from Commons Logging to SLF4J > -- > > Key: CALCITE-669 > URL: https://issues.apache.org/jira/browse/CALCITE-669 > Project: Calcite > Issue Type: Task > Components: avatica >Reporter: Nick Dimiduk >Assignee: Josh Elser >Priority: Minor > Fix For: 1.7.0 > > > As mentioned on CALCITE-641, it could be useful to adopt a logging > implementation that supports pluggable backends and has > [MDC|http://www.slf4j.org/manual.html#mdc] support. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CALCITE-604) Invoke metadata providers via MethodHandle rather than reflection
[ https://issues.apache.org/jira/browse/CALCITE-604?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15106069#comment-15106069 ] Julian Hyde commented on CALCITE-604: - Work in progress at https://github.com/julianhyde/calcite/tree/604-tune-metadata. > Invoke metadata providers via MethodHandle rather than reflection > - > > Key: CALCITE-604 > URL: https://issues.apache.org/jira/browse/CALCITE-604 > Project: Calcite > Issue Type: Bug >Reporter: Julian Hyde >Assignee: Julian Hyde > > JDK 1.7 introduced > http://docs.oracle.com/javase/7/docs/api/java/lang/invoke/MethodHandle.html, > a more efficient way to invoke methods. Access control etc. is done when the > handle is created, not each invocation. > Currently calls to metadata providers are dispatched via reflection > (Method.invoke, see ReflectiveRelMetadataProvider, ChainedRelMetadataProvider > and CachingInvocationHandler), and I suspect that planning a complex query > (especially with tracing enabled) makes millions of calls. Moving to > MethodHandle would improve performance. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CALCITE-669) Move from Commons Logging to SLF4J
[ https://issues.apache.org/jira/browse/CALCITE-669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15105768#comment-15105768 ] Josh Elser commented on CALCITE-669: I suppose "FINE" could also be put at the INFO level :). It doesn't seem like we have much coming out at that level anyways. > Move from Commons Logging to SLF4J > -- > > Key: CALCITE-669 > URL: https://issues.apache.org/jira/browse/CALCITE-669 > Project: Calcite > Issue Type: Task > Components: avatica >Reporter: Nick Dimiduk >Assignee: Josh Elser >Priority: Minor > Fix For: 1.7.0 > > > As mentioned on CALCITE-641, it could be useful to adopt a logging > implementation that supports pluggable backends and has > [MDC|http://www.slf4j.org/manual.html#mdc] support. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
