silundong commented on code in PR #4678:
URL: https://github.com/apache/calcite/pull/4678#discussion_r2616190489
##########
core/src/main/java/org/apache/calcite/adapter/enumerable/EnumerableHashJoin.java:
##########
@@ -218,8 +218,10 @@ private Result
implementHashSemiJoin(EnumerableRelImplementor implementor, Prefe
Expressions.list(
leftExpression,
rightExpression,
-
leftResult.physType.generateAccessorWithoutNulls(joinInfo.leftKeys),
-
rightResult.physType.generateAccessorWithoutNulls(joinInfo.rightKeys),
+ leftResult.physType.generateNullAwareAccessor(
Review Comment:
The "RuntimeException: Cannot convert null to long" error in TpcdsTest may
be related to type inference.
When building the join-key selector, the
`PhysTypeImpl.fieldReference(Expression expression, int field)` is called,
which generates the code that extracts a specific column from a row (just like
`row[i]`). For example, if the i-th column is of type Long and is inferred as
non-nullable, the generated code is `toLong(row[i])` (and `toLong` does not
accept null); if it is inferred to be nullable, the generated code is just
`row[i]`.
In the failing test case, the join key is inferred as non-nullable, so the
generated code is `toLong(row[i])`, but at runtime there is a row whose join
key is actually null, causing `toLong` to receive a null and throw the
exception.
I haven't dug into this deeply yet, so I'm not sure whether this is a bug in
the type inference or an unexpected null appearing during execution. Anyway,
the observed behavior is as described above.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
