[ 
https://issues.apache.org/jira/browse/CALCITE-6593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17884333#comment-17884333
 ] 

Ruben Q L edited comment on CALCITE-6593 at 9/24/24 3:39 PM:
-------------------------------------------------------------

bq. Is it possible to run the test suite (one time) with the column count 
threshold set very low, so that we can identify any other issues with the 
algorithm?

That's a good point [~julianhyde], we probably should have done that before 
merging CALCITE-3094. Doing that locally seems to unveil some other exceptions 
with this new code (apart from the NPE described here), mainly a 
CompileException with message: {{A method named "copyValues" is not declared in 
any enclosing class nor any supertype, nor through a static import}}; and a 
ArrayStoreException of the form {{arraycopy: type mismatch: can not copy object 
array[] into int[]}}

Considering our tight schedule for 1.38, I wonder if a cleaner (and more 
practical) solution would be reverting CALCITE-3094, and focusing on the more 
general approach for code size issues provided by CALCITE-6465 (and finalized 
said ticket for 1.38).


was (Author: rubenql):
bq. Is it possible to run the test suite (one time) with the column count 
threshold set very low, so that we can identify any other issues with the 
algorithm?

That's a good point [~julianhyde], we probably should have done that before 
merging CALCITE-3094. Doing that locally seems to unveil some other exceptions 
with this new code (apart from the NPE described here), mainly a 
CompileException with message: {{A method named "copyValues" is not declared in 
any enclosing class nor any supertype, nor through a static import}}

Considering our tight schedule for 1.38, I wonder if a cleaner (and more 
practical) solution would be reverting CALCITE-3094, and focusing on the more 
general approach for code size issues provided by CALCITE-6465 (and finalized 
said ticket for 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)

Reply via email to