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

Dmitry Sysolyatin edited comment on CALCITE-5388 at 11/21/22 7:37 PM:
----------------------------------------------------------------------

[~julianhyde] I don't know how to make the 'self-made optimizer' a bit better 
without looking into each Enumerable class and I don't have so much time to do 
it at the moment. It would be better to have separate jira ticket for that.

I have two ideas for fix:
 * Do not reuse the variable if some method changes object state:
For example:
{code:java}
final java.util.List tempList = (java.util.List) 
org.apache.calcite.linq4j.Linq4j.asEnumerable(new Integer[] {1, 2}).into(new 
java.util.ArrayList());

tempList.clear() <--- this operation changes tempList, so tempList can not be 
reused out of logic scope
{code}

 * Set optimize parameter of builder.append to false by default instead of 
true. And set it to true only when developer understand what is going on under 
the hood.

{quote}change the code so that it is clear what is going on.
{quote}
The only thing I can do is to use the "optimize" parameter of the 
"builder.append" method instead of the '_' prefix and write proper commit 
message.


was (Author: dmsysolyatin):
[~julianhyde] I don't know how to make the 'self-made optimizer' a bit better 
without looking into each Enumerable class and I don't have so much time to do 
it at the moment. It would be better to have separate jira ticket for that.

I have two ideas for fix:
 * Do not reuse the variable if some method changes object state:
For example:
{code:java}
final java.util.List tempList = (java.util.List) 
org.apache.calcite.linq4j.Linq4j.asEnumerable(new Integer[] {1, 2}).into(new 
java.util.ArrayList());

tempList.remove() <--- this operation changes tempList, so tempList can not be 
reused out of logic scope
{code}

 * Set optimize parameter of builder.append to false by default instead of 
true. And set it to true only when developer understand what is going on under 
the hood.

{quote}change the code so that it is clear what is going on.
{quote}
The only thing I can do is to use the "optimize" parameter of the 
"builder.append" method instead of the '_' prefix and write proper commit 
message.

> No result when using ROW_NUMBER in two common table expressions
> ---------------------------------------------------------------
>
>                 Key: CALCITE-5388
>                 URL: https://issues.apache.org/jira/browse/CALCITE-5388
>             Project: Calcite
>          Issue Type: Bug
>          Components: core
>    Affects Versions: 1.32.0
>            Reporter: Magnus Mogren
>            Assignee: Dmitry Sysolyatin
>            Priority: Major
>             Fix For: 1.33.0
>
>
> This SQL produces no result.
>  
> {code:java}
> with
>     CTE1(rownr1, val1) as ( select ROW_NUMBER() OVER(ORDER BY id ASC), id 
> from (values (1), (2)) as Vals1(id) ),
>     CTE2(rownr2, val2) as ( select ROW_NUMBER() OVER(ORDER BY id ASC), id 
> from (values (1), (2)) as Vals2(id) )
> select
>     CTE1.rownr1,
>     CTE1.val1,
>     CTE2.rownr2,
>     CTE2.val2 
> from
>     CTE1,
>     CTE2 
> where
>     CTE1.val1 = CTE2.val2{code}
>  
> However, if you remove CTE.rownr2 from the selected columns it produces the 2 
> rows as expected:
> |ROWNR1|VAL1|VAL2|
> |1|1|1|
> |2|2|2|
>  
> Same type of problem occurs of you try to compare the two rownr columns. No 
> result for this:
> {code:java}
> with
>     CTE1(rownr1, val1) as ( select ROW_NUMBER() OVER(ORDER BY id ASC), id 
> from (values (1), (2)) as Vals1(id) ),
>     CTE2(rownr2, val2) as ( select ROW_NUMBER() OVER(ORDER BY id ASC), id 
> from (values (1), (2)) as Vals2(id) )
> select
>     CTE1.val1,
>     CTE2.val2 
> from
>     CTE1,
>     CTE2 
> where
>     CTE1.rownr1 = CTE2.rownr2{code}
>  
> Does calcite get confused over the fact that two ROW_NUMBER functions are 
> used among the common table expressions?



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Reply via email to