[
https://issues.apache.org/jira/browse/CALCITE-1569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15831621#comment-15831621
]
zhen wang commented on CALCITE-1569:
------------------------------------
https://github.com/apache/calcite/pull/356 tests fixed with `mvn clean test`
( previous was due to my mis-understanding when switch back to master, it is
also failing there)
[~julianhyde] I agree with you regarding this is not idea. I don't want some
place middle plugged in a special logic and say `Date` need to be specially
handled. but this is what I have with several attempts.
I don't quite understand `fix when they enter the system`, what about when they
are eventually selected out as result ? convert them back?
to me, the problem seems the `RexToLixTranslator#convert`. ideally the fromType
should be derived from Expression. but this is not the case for Input Arrays.
as there could be all kinds of types on the columns, so the expression
eventually derive `Object` as its type. obviously this has lost precision, we
know that a[0] is Date, but I didn't manage to pass that in elegantly.
to me, this is the problem.
Anyways. I agree with your comment, if anyone want this fix they could patch.
and this should be targeted to be fixed more elegantly.
> 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: zhen wang
> Fix For: 1.12.0
>
>
> 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)
