[
https://issues.apache.org/jira/browse/CALCITE-1569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15830579#comment-15830579
]
Julian Hyde commented on CALCITE-1569:
--------------------------------------
The fix isn't ideal. I'd rather that we convert java.sql.Date values when they
enter the system. And, if we allow java.sql.Date values then we should treat
java.util.Date, java.sql.Time and java.sql.Timestamp values similarly. But
being pragmatic, I'm going to accept the patch because it fixes cases that
didn't work previously. If we see further problems in this area, we might back
out the changes and do it properly.
[[email protected]], Can you please test your code against the patch and
confirm that it fixes the problem.
[~zhenw], Can you please submit a pull request, and post the URL here.
> Date condition can generates Integer == Integer, which is always false
> ----------------------------------------------------------------------
>
> Key: CALCITE-1569
> URL: https://issues.apache.org/jira/browse/CALCITE-1569
> Project: Calcite
> Issue Type: Bug
> Affects Versions: 1.10.0
> Reporter: liyang
> Assignee: Julian Hyde
>
> Run the below query on calcite 1.10.
> {code}
> select
> l.cal_dt
> , sum(left_join_gvm) as left_join_sum
> , sum(inner_join_gvm) as inner_join_sum
> from
> (
> select test_kylin_fact.cal_dt, sum(price) as left_join_gvm
> from test_kylin_fact
> group by test_kylin_fact.cal_dt
> ) l
> ,
> (
> select test_kylin_fact.cal_dt, sum(price) as inner_join_gvm
> from test_kylin_fact
> group by test_kylin_fact.cal_dt
> ) i
> where
> l.cal_dt = i.cal_dt -- this condition
> group by
> l.cal_dt
> {code}
> The where condition generates Baz code like below.
> {code}
> /* 284 */ final org.apache.calcite.linq4j.AbstractEnumerable child1 = new
> org.apache.calcite.linq4j.AbstractEnumerable(){
> /* 285 */ public org.apache.calcite.linq4j.Enumerator enumerator() {
> /* 286 */ return new org.apache.calcite.linq4j.Enumerator(){
> /* 287 */ public final org.apache.calcite.linq4j.Enumerator
> inputEnumerator = _inputEnumerable1.enumerator();
> /* 288 */ public void reset() {
> /* 289 */ inputEnumerator.reset();
> /* 290 */ }
> /* 291 */
> /* 292 */ public boolean moveNext() {
> /* 293 */ while (inputEnumerator.moveNext()) {
> /* 294 */ final Object[] current = (Object[])
> inputEnumerator.current();
> /* 295 */ final Integer inp0_ = (Integer) current[0];
> /* 296 */ final Integer inp2_ = (Integer) current[2];
> /* 297 */ if (inp0_ != null && inp2_ != null && inp0_ == inp2_)
> {
> /* 298 */ return true;
> /* 299 */ }
> /* 300 */ }
> /* 301 */ return false;
> /* 302 */ }
> /* 303 */
> /* 304 */ public void close() {
> /* 305 */ inputEnumerator.close();
> /* 306 */ }
> /* 307 */
> /* 308 */ public Object current() {
> /* 309 */ final Object[] current = (Object[])
> inputEnumerator.current();
> /* 310 */ return new Object[] {
> /* 311 */ current[0],
> /* 312 */ current[1],
> /* 313 */ current[3]};
> /* 314 */ }
> /* 315 */
> /* 316 */ };
> /* 317 */ }
> /* 318 */
> /* 319 */ };
> {code}
> The problem is {code} if (inp0_ != null && inp2_ != null && inp0_ == inp2_)
> {code} is always false, by using == to compare two Integers.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
