[
https://issues.apache.org/jira/browse/CALCITE-6593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17884370#comment-17884370
]
Ruben Q L edited comment on CALCITE-6593 at 9/24/24 6:17 PM:
-------------------------------------------------------------
[~rubenql], Thank you for thinking the unthinkable, and suggesting backing out
CALCITE-3094. It's the right way to think about this. We can't afford to
introduce errors in query processing. I'm glad that you managed to stabilize
the code, and we won't need to revert anything.
I think we should include your fix for this case in 1.38 but delay CALCITE-6465
(Flink's splitter) a little. I want to consider copy-pasting Flink's splitter
code into calcite-linq4j (or some third-party library that doesn't depend on
either Calcite or Flink). When we've solved that bug, do you think we could
reverting this case and CALCITE-3094? With that fix, and a new Avatica release,
it might make sense to release Calcite 1.39 only a month or so after 1.38.
was (Author: julianhyde):
[~rubenql], Thank you for thinking the unthinkable, and suggesting backing out
CALCITE-3094. It's the right way to think about this. We can't afford to
introduce errors in query processing. I'm glad that you managed to stabilize
the code, and we won't need to revert anything.
I think we should include your fix for this case in 1.38 but delay CALCITE-6565
(Flink's splitter) a little. I want to consider copy-pasting Flink's splitter
code into calcite-linq4j (or some third-party library that doesn't depend on
either Calcite or Flink). When we've solved that bug, do you think we could
reverting this case and CALCITE-3094? With that fix, and a new Avatica release,
it might make sense to release Calcite 1.39 only a month or so after 1.38.
> NPE when outer joining tables with many fields and unmatching rows
> ------------------------------------------------------------------
>
> Key: CALCITE-6593
> URL: https://issues.apache.org/jira/browse/CALCITE-6593
> Project: Calcite
> Issue Type: Bug
> Components: core
> Reporter: Rodrigo Rueda
> Assignee: Ruben Q L
> Priority: Blocker
> Labels: pull-request-available
> Fix For: 1.38.0
>
>
> The fix for CALCITE-3094 started generating the following code for a join
> when the resulting field count is >= 100.
> {code:java}
> public Object[] apply(Object[] left, Object[] right) {
> Object[] outputArray = new Object[102];
> System.arraycopy(left, 0, outputArray, 0, 94);
> System.arraycopy(right, 0, outputArray, 94, 8);
> return outputArray;
> } {code}
> But left or right might be null if one of the sides of the join is empty,
> which leads to a NPE:
> {code:java}
> java.lang.NullPointerException
> at java.base/java.lang.System.arraycopy(Native Method)
> at Baz$3.apply(Unknown Source)
> at Baz$3.apply(Unknown Source)
> at Baz$3.apply(Unknown Source)
> at
> org.apache.calcite.linq4j.EnumerableDefaults$12$1.current(EnumerableDefaults.java:2078)
> at Baz$4$1.current(Unknown Source) {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
