[jira] [Created] (CALCITE-3065) RexLiteral#getValueAs should consider primitive type
Jiatao Tao created CALCITE-3065: --- Summary: RexLiteral#getValueAs should consider primitive type Key: CALCITE-3065 URL: https://issues.apache.org/jira/browse/CALCITE-3065 Project: Calcite Issue Type: Improvement Components: core Environment: I would like to take this JIRA if community think this is indeed a problem. [|https://issues.apache.org/jira/secure/AddComment!default.jspa?id=13229529] Reporter: Jiatao Tao Attachments: image-2019-05-13-11-58-54-852.png !image-2019-05-13-11-58-54-852.png! -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-3065) RexLiteral#getValueAs should consider primitive type
[ https://issues.apache.org/jira/browse/CALCITE-3065?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16838493#comment-16838493 ] Jiatao Tao commented on CALCITE-3065: - I would like to take this JIRA if community think this is indeed a problem. > RexLiteral#getValueAs should consider primitive type > > > Key: CALCITE-3065 > URL: https://issues.apache.org/jira/browse/CALCITE-3065 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: Jiatao Tao >Priority: Major > Attachments: image-2019-05-13-11-58-54-852.png > > > !image-2019-05-13-11-58-54-852.png! -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CALCITE-3065) RexLiteral#getValueAs should consider primitive type
[ https://issues.apache.org/jira/browse/CALCITE-3065?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jiatao Tao updated CALCITE-3065: Environment: (was: I would like to take this JIRA if community think this is indeed a problem. [|https://issues.apache.org/jira/secure/AddComment!default.jspa?id=13229529]) > RexLiteral#getValueAs should consider primitive type > > > Key: CALCITE-3065 > URL: https://issues.apache.org/jira/browse/CALCITE-3065 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: Jiatao Tao >Priority: Major > Attachments: image-2019-05-13-11-58-54-852.png > > > !image-2019-05-13-11-58-54-852.png! -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CALCITE-3065) RexLiteral#getValueAs should consider primitive type
[ https://issues.apache.org/jira/browse/CALCITE-3065?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jiatao Tao updated CALCITE-3065: Description: !image-2019-05-13-12-04-36-365.png! (was: !image-2019-05-13-11-58-54-852.png!) > RexLiteral#getValueAs should consider primitive type > > > Key: CALCITE-3065 > URL: https://issues.apache.org/jira/browse/CALCITE-3065 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: Jiatao Tao >Priority: Major > Attachments: image-2019-05-13-11-58-54-852.png, > image-2019-05-13-12-04-36-365.png > > > !image-2019-05-13-12-04-36-365.png! -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CALCITE-3065) RexLiteral#getValueAs should consider primitive type
[ https://issues.apache.org/jira/browse/CALCITE-3065?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jiatao Tao updated CALCITE-3065: Attachment: (was: image-2019-05-13-11-58-54-852.png) > RexLiteral#getValueAs should consider primitive type > > > Key: CALCITE-3065 > URL: https://issues.apache.org/jira/browse/CALCITE-3065 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: Jiatao Tao >Priority: Major > Attachments: image-2019-05-13-12-04-36-365.png > > > !image-2019-05-13-12-04-36-365.png! -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CALCITE-3065) RexLiteral#getValueAs should consider primitive type
[ https://issues.apache.org/jira/browse/CALCITE-3065?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jiatao Tao updated CALCITE-3065: Attachment: image-2019-05-13-12-04-36-365.png > RexLiteral#getValueAs should consider primitive type > > > Key: CALCITE-3065 > URL: https://issues.apache.org/jira/browse/CALCITE-3065 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: Jiatao Tao >Priority: Major > Attachments: image-2019-05-13-11-58-54-852.png, > image-2019-05-13-12-04-36-365.png > > > !image-2019-05-13-11-58-54-852.png! -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-3065) RexLiteral#getValueAs should consider primitive type
[
https://issues.apache.org/jira/browse/CALCITE-3065?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16839961#comment-16839961
]
Jiatao Tao commented on CALCITE-3065:
-
Hi [~danny0405] [~julianhyde]
code like this
{code:java}
val tp = new JavaTypeFactoryImpl(RelDataTypeSystem.DEFAULT)
literal.getValueAs(tp.getJavaClass(literal.getType).asInstanceOf[java.lang.Class[_]])
{code}
And `tp.getJavaClass(literal.getType)` return int not Interger, and getValueAs
can not recognize int, so I open this jira.
And Primitive.box(clazz) do work, but in my opinion, leave this to callee is
more elegant, maybe we can do this in method "getValueAs".
And do appreciate for your reply, hope to hear your opinion again.
> RexLiteral#getValueAs should consider primitive type
>
>
> Key: CALCITE-3065
> URL: https://issues.apache.org/jira/browse/CALCITE-3065
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: Jiatao Tao
>Priority: Major
> Labels: pull-request-available
> Attachments: image-2019-05-13-12-04-36-365.png
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> !image-2019-05-13-12-04-36-365.png!
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-3065) RexLiteral#getValueAs should consider primitive type
[ https://issues.apache.org/jira/browse/CALCITE-3065?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16840108#comment-16840108 ] Jiatao Tao commented on CALCITE-3065: - Hi [~danny0405] Here I briefly describe how I encountered this problem.The literal I get is from RexVisitor#visitLiteral, and calcite will treat all numeric as *decimal*, and Spark will add cast in filter for that scenario. In some case, filter with cast can not use the ability of pruning. For "passed in a Boxed type class to *SqlLiteral#getValueAs* explicitly." , In my opinion, leave this to callee is more elegan, why not "Primitive.box" class first in *SqlLiteral#**getValueAs?* . By the way, may I ask why Calcite treate all numeric as *decimal?* Do appreciate for your reply, hope to hear your opinion again. > RexLiteral#getValueAs should consider primitive type > > > Key: CALCITE-3065 > URL: https://issues.apache.org/jira/browse/CALCITE-3065 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: Jiatao Tao >Priority: Major > Labels: pull-request-available > Attachments: image-2019-05-13-12-04-36-365.png > > Time Spent: 10m > Remaining Estimate: 0h > > !image-2019-05-13-12-04-36-365.png! -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-3065) RexLiteral#getValueAs should consider primitive type
[ https://issues.apache.org/jira/browse/CALCITE-3065?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16840933#comment-16840933 ] Jiatao Tao commented on CALCITE-3065: - [~danny0405] Thanks, it answers my doubts. But I got this literal in RexVisitor, I think it is after validating? [~julianhyde] By the way, I still think we can do "Primitive.box(clazz)" inside *SqlLiteral#**getValueAs,* isn't this more reasonable? ** We expected all clazz to be boxed, use "Primitive.box" to insure this. Hope to hear your opinion, really appreciate. > RexLiteral#getValueAs should consider primitive type > > > Key: CALCITE-3065 > URL: https://issues.apache.org/jira/browse/CALCITE-3065 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: Jiatao Tao >Priority: Major > Labels: pull-request-available > Attachments: image-2019-05-13-12-04-36-365.png > > Time Spent: 10m > Remaining Estimate: 0h > > !image-2019-05-13-12-04-36-365.png! -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (CALCITE-3065) RexLiteral#getValueAs should consider primitive type
[
https://issues.apache.org/jira/browse/CALCITE-3065?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16840933#comment-16840933
]
Jiatao Tao edited comment on CALCITE-3065 at 5/16/19 2:39 AM:
--
Hi [~danny0405]
Thanks, it answers my doubts. But I got this literal in RexVisitor, I think it
is after validating?
Hi [~julianhyde]
By the way, I still think we can do "Primitive.box(clazz)" inside
*SqlLiteral#**getValueAs,*
isn't this more reasonable? ** We expected all clazz to be boxed, use
"Primitive.box" to insure this.
{code:java}
public T getValueAs(Class clazz) {
clazz = Primitive.box(clazz);
...
}{code}
Hope to hear your opinion, really appreciate.
was (Author: aron.tao):
[~danny0405]
Thanks, it answers my doubts. But I got this literal in RexVisitor, I think it
is after validating?
[~julianhyde]
By the way, I still think we can do "Primitive.box(clazz)" inside
*SqlLiteral#**getValueAs,*
isn't this more reasonable? ** We expected all clazz to be boxed, use
"Primitive.box" to insure this.
Hope to hear your opinion, really appreciate.
> RexLiteral#getValueAs should consider primitive type
>
>
> Key: CALCITE-3065
> URL: https://issues.apache.org/jira/browse/CALCITE-3065
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: Jiatao Tao
>Priority: Major
> Labels: pull-request-available
> Attachments: image-2019-05-13-12-04-36-365.png
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> !image-2019-05-13-12-04-36-365.png!
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-3065) RexLiteral#getValueAs should consider primitive type
[ https://issues.apache.org/jira/browse/CALCITE-3065?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16841934#comment-16841934 ] Jiatao Tao commented on CALCITE-3065: - Hi [~danny0405] you mean literal.getType? *SqlTypeName typeName* is Integer, from the first coommet, I didn't argue that. But the value of RexLiteral is decimal, so I do this:*literal.getValueAs*. code from previous comment: val tp = new JavaTypeFactoryImpl(RelDataTypeSystem.DEFAULT) literal.getValueAs(tp.getJavaClass(literal.getType).asInstanceOf[java.lang.Class[_]]) *literal.getType ->* INTEGER *tp.getJavaClass*(*INTEGER*) -> int literal.getValueAs does not process `int` scenario. I didn't get your point, hope to hear your voice. Thanks. > RexLiteral#getValueAs should consider primitive type > > > Key: CALCITE-3065 > URL: https://issues.apache.org/jira/browse/CALCITE-3065 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: Jiatao Tao >Priority: Major > Labels: pull-request-available > Attachments: image-2019-05-13-12-04-36-365.png > > Time Spent: 10m > Remaining Estimate: 0h > > !image-2019-05-13-12-04-36-365.png! -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (CALCITE-3065) RexLiteral#getValueAs should consider primitive type
[ https://issues.apache.org/jira/browse/CALCITE-3065?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16841934#comment-16841934 ] Jiatao Tao edited comment on CALCITE-3065 at 5/17/19 6:04 AM: -- Hi [~danny0405] you mean literal.getType? *SqlTypeName typeName* is Integer, from the first coommet, I didn't argue that. But the value of RexLiteral is decimal, so I do this:*literal.getValueAs(Otherwise why exists this method)*. code from previous comment: val tp = new JavaTypeFactoryImpl(RelDataTypeSystem.DEFAULT) literal.getValueAs(tp.getJavaClass(literal.getType).asInstanceOf[java.lang.Class[_]]) *literal.getType ->* INTEGER *tp.getJavaClass*(*INTEGER*) -> int literal.getValueAs does not process `int` scenario. I didn't get your point, hope to hear your voice. Thanks. was (Author: aron.tao): Hi [~danny0405] you mean literal.getType? *SqlTypeName typeName* is Integer, from the first coommet, I didn't argue that. But the value of RexLiteral is decimal, so I do this:*literal.getValueAs*. code from previous comment: val tp = new JavaTypeFactoryImpl(RelDataTypeSystem.DEFAULT) literal.getValueAs(tp.getJavaClass(literal.getType).asInstanceOf[java.lang.Class[_]]) *literal.getType ->* INTEGER *tp.getJavaClass*(*INTEGER*) -> int literal.getValueAs does not process `int` scenario. I didn't get your point, hope to hear your voice. Thanks. > RexLiteral#getValueAs should consider primitive type > > > Key: CALCITE-3065 > URL: https://issues.apache.org/jira/browse/CALCITE-3065 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: Jiatao Tao >Priority: Major > Labels: pull-request-available > Attachments: image-2019-05-13-12-04-36-365.png > > Time Spent: 10m > Remaining Estimate: 0h > > !image-2019-05-13-12-04-36-365.png! -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CALCITE-3065) RexLiteral#getValueAs should consider primitive type
[ https://issues.apache.org/jira/browse/CALCITE-3065?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jiatao Tao updated CALCITE-3065: Attachment: image-2019-05-17-08-23-52-735.png > RexLiteral#getValueAs should consider primitive type > > > Key: CALCITE-3065 > URL: https://issues.apache.org/jira/browse/CALCITE-3065 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: Jiatao Tao >Priority: Major > Labels: pull-request-available > Attachments: image-2019-05-13-12-04-36-365.png, > image-2019-05-17-08-23-52-735.png > > Time Spent: 10m > Remaining Estimate: 0h > > !image-2019-05-13-12-04-36-365.png! -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (CALCITE-3065) RexLiteral#getValueAs should consider primitive type
[ https://issues.apache.org/jira/browse/CALCITE-3065?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16841993#comment-16841993 ] Jiatao Tao edited comment on CALCITE-3065 at 5/17/19 8:26 AM: -- [~danny0405] [~julianhyde] !image-2019-05-17-08-23-52-735.png! The reason I do that is to reduce "cast". And do hope we can community more efficient. Thanks. was (Author: aron.tao): [~danny0405] !image-2019-05-17-08-23-52-735.png! The reason I do that is to reduce "cast". And do hope we can community more efficient. Thanks. > RexLiteral#getValueAs should consider primitive type > > > Key: CALCITE-3065 > URL: https://issues.apache.org/jira/browse/CALCITE-3065 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: Jiatao Tao >Priority: Major > Labels: pull-request-available > Attachments: image-2019-05-13-12-04-36-365.png, > image-2019-05-17-08-23-52-735.png > > Time Spent: 10m > Remaining Estimate: 0h > > !image-2019-05-13-12-04-36-365.png! -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-3065) RexLiteral#getValueAs should consider primitive type
[ https://issues.apache.org/jira/browse/CALCITE-3065?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16841993#comment-16841993 ] Jiatao Tao commented on CALCITE-3065: - [~danny0405] !image-2019-05-17-08-23-52-735.png! The reason I do that is to reduce "cast". And do hope we can community more efficient. Thanks. > RexLiteral#getValueAs should consider primitive type > > > Key: CALCITE-3065 > URL: https://issues.apache.org/jira/browse/CALCITE-3065 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: Jiatao Tao >Priority: Major > Labels: pull-request-available > Attachments: image-2019-05-13-12-04-36-365.png, > image-2019-05-17-08-23-52-735.png > > Time Spent: 10m > Remaining Estimate: 0h > > !image-2019-05-13-12-04-36-365.png! -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (CALCITE-3065) RexLiteral#getValueAs should consider primitive type
[ https://issues.apache.org/jira/browse/CALCITE-3065?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16841993#comment-16841993 ] Jiatao Tao edited comment on CALCITE-3065 at 5/17/19 8:34 AM: -- [~danny0405] [~julianhyde] !image-2019-05-17-08-23-52-735.png! The reason I do that is to reduce "cast". And do hope we can community more efficient. And leave my scenario aside, shouldn't "literal.getValueAs" process both "int" and "Integer" cases? At least in Java, int and Integer are not so different in most case. Thanks. was (Author: aron.tao): [~danny0405] [~julianhyde] !image-2019-05-17-08-23-52-735.png! The reason I do that is to reduce "cast". And do hope we can community more efficient. Thanks. > RexLiteral#getValueAs should consider primitive type > > > Key: CALCITE-3065 > URL: https://issues.apache.org/jira/browse/CALCITE-3065 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: Jiatao Tao >Priority: Major > Labels: pull-request-available > Attachments: image-2019-05-13-12-04-36-365.png, > image-2019-05-17-08-23-52-735.png > > Time Spent: 10m > Remaining Estimate: 0h > > !image-2019-05-13-12-04-36-365.png! -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (CALCITE-3065) RexLiteral#getValueAs should consider primitive type
[ https://issues.apache.org/jira/browse/CALCITE-3065?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16841993#comment-16841993 ] Jiatao Tao edited comment on CALCITE-3065 at 5/17/19 8:35 AM: -- [~danny0405] [~julianhyde] !image-2019-05-17-08-23-52-735.png! The reason I do that is to reduce "cast". And do hope we can community more efficient. And leave my scenario aside, shouldn't "literal.getValueAs" process both "int" and "Integer"? At least in Java, int and Integer are not so different in most case. Thanks. was (Author: aron.tao): [~danny0405] [~julianhyde] !image-2019-05-17-08-23-52-735.png! The reason I do that is to reduce "cast". And do hope we can community more efficient. And leave my scenario aside, shouldn't "literal.getValueAs" process both "int" and "Integer" cases? At least in Java, int and Integer are not so different in most case. Thanks. > RexLiteral#getValueAs should consider primitive type > > > Key: CALCITE-3065 > URL: https://issues.apache.org/jira/browse/CALCITE-3065 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: Jiatao Tao >Priority: Major > Labels: pull-request-available > Attachments: image-2019-05-13-12-04-36-365.png, > image-2019-05-17-08-23-52-735.png > > Time Spent: 10m > Remaining Estimate: 0h > > !image-2019-05-13-12-04-36-365.png! -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-3065) RexLiteral#getValueAs should consider primitive type
[ https://issues.apache.org/jira/browse/CALCITE-3065?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16842877#comment-16842877 ] Jiatao Tao commented on CALCITE-3065: - [~julianhyde] [~danny0405] # For calcite, I just need to box "class" in SqlLiteral.getValue, and then I can get a reasonable value. If it is easy for Spark to support pruning with "cast", It will already be done. Besides, I think it is put the cart before the horse. # "solve the type consistency", in my opinion, "literal.getValueAs" has done that, it returns the true type. An int value shouldn't be int but decimal, literal.getValueAs just return int? # Let's put Spark aside and leave my scenario aside, shouldn't "literal.getValueAs" process both "int" and "Integer"? At least in Java, int and Integer are not so different in most case. So in summary, I can not buy in your thoughts. > RexLiteral#getValueAs should consider primitive type > > > Key: CALCITE-3065 > URL: https://issues.apache.org/jira/browse/CALCITE-3065 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: Jiatao Tao >Priority: Major > Labels: pull-request-available > Attachments: image-2019-05-13-12-04-36-365.png, > image-2019-05-17-08-23-52-735.png > > Time Spent: 10m > Remaining Estimate: 0h > > !image-2019-05-13-12-04-36-365.png! -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (CALCITE-3065) RexLiteral#getValueAs should consider primitive type
[ https://issues.apache.org/jira/browse/CALCITE-3065?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16842877#comment-16842877 ] Jiatao Tao edited comment on CALCITE-3065 at 5/18/19 2:12 AM: -- [~danny0405] # For calcite, I just need to box "class" in SqlLiteral.getValue, and then I can get a reasonable value. If it is easy for Spark to support pruning with "cast", It will already be done. Besides, I think it is put the cart before the horse. # "solve the type consistency", in my opinion, "literal.getValueAs" has done that, it returns the value in its true type(In accordance with common sense). # Let's put Spark aside and leave my scenario aside, shouldn't "literal.getValueAs" process both "int" and "Integer"? At least in Java, int and Integer are not so different in most case. So in summary, I can not buy in your thoughts. Can you provide other reasons? Or [~julianhyde], can you give some comments? I think you understand my question at first. Very thanks if you give me some feedbacks. was (Author: aron.tao): [~julianhyde] [~danny0405] # For calcite, I just need to box "class" in SqlLiteral.getValue, and then I can get a reasonable value. If it is easy for Spark to support pruning with "cast", It will already be done. Besides, I think it is put the cart before the horse. # "solve the type consistency", in my opinion, "literal.getValueAs" has done that, it returns the true type. An int value shouldn't be int but decimal, literal.getValueAs just return int? # Let's put Spark aside and leave my scenario aside, shouldn't "literal.getValueAs" process both "int" and "Integer"? At least in Java, int and Integer are not so different in most case. So in summary, I can not buy in your thoughts. > RexLiteral#getValueAs should consider primitive type > > > Key: CALCITE-3065 > URL: https://issues.apache.org/jira/browse/CALCITE-3065 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: Jiatao Tao >Priority: Major > Labels: pull-request-available > Attachments: image-2019-05-13-12-04-36-365.png, > image-2019-05-17-08-23-52-735.png > > Time Spent: 10m > Remaining Estimate: 0h > > !image-2019-05-13-12-04-36-365.png! -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (CALCITE-3065) RexLiteral#getValueAs should consider primitive type
[ https://issues.apache.org/jira/browse/CALCITE-3065?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16842877#comment-16842877 ] Jiatao Tao edited comment on CALCITE-3065 at 5/18/19 2:14 AM: -- [~danny0405] # For calcite, I just need to box "class" in SqlLiteral.getValue, and then I can get a reasonable value. If it is easy for Spark to support pruning with "cast", It will already be done. Besides, I think it is put the cart before the horse. # "solve the type consistency", in my opinion, "literal.getValueAs" has done that, it returns the value in its true type(In accordance with common sense). # Let's put Spark aside and leave my scenario aside, shouldn't "literal.getValueAs" process both "int" and "Integer"? At least in Java, int and Integer are not so different in most case. So in summary, I can not buy in your thoughts. Can you provide other reasons? Or [~julianhyde], can you give some comments? It seems that you understand my problem at first. Very thanks if you give me some feedback. Very appreciate for your work. was (Author: aron.tao): [~danny0405] # For calcite, I just need to box "class" in SqlLiteral.getValue, and then I can get a reasonable value. If it is easy for Spark to support pruning with "cast", It will already be done. Besides, I think it is put the cart before the horse. # "solve the type consistency", in my opinion, "literal.getValueAs" has done that, it returns the value in its true type(In accordance with common sense). # Let's put Spark aside and leave my scenario aside, shouldn't "literal.getValueAs" process both "int" and "Integer"? At least in Java, int and Integer are not so different in most case. So in summary, I can not buy in your thoughts. Can you provide other reasons? Or [~julianhyde], can you give some comments? I think you understand my question at first. Very thanks if you give me some feedbacks. > RexLiteral#getValueAs should consider primitive type > > > Key: CALCITE-3065 > URL: https://issues.apache.org/jira/browse/CALCITE-3065 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: Jiatao Tao >Priority: Major > Labels: pull-request-available > Attachments: image-2019-05-13-12-04-36-365.png, > image-2019-05-17-08-23-52-735.png > > Time Spent: 10m > Remaining Estimate: 0h > > !image-2019-05-13-12-04-36-365.png! -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (CALCITE-3065) RexLiteral#getValueAs should consider primitive type
[
https://issues.apache.org/jira/browse/CALCITE-3065?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16842877#comment-16842877
]
Jiatao Tao edited comment on CALCITE-3065 at 5/18/19 2:14 AM:
--
[~danny0405]
# For calcite, I just need to box "class" in SqlLiteral.getValue, and then I
can get a reasonable value. If it is easy for Spark to support pruning with
"cast", It will already be done. Besides, I think it is put the cart before the
horse.
# "solve the type consistency", in my opinion, "literal.getValueAs" has done
that, it returns the value in its true type(In accordance with common sense).
# Let's put Spark aside and leave my scenario aside, shouldn't
"literal.getValueAs" process both "int" and "Integer"? At least in Java, int
and Integer are not so different in most case.
PS. code like this:
public T getValueAs(Class clazz) \{
clazz = Primitive.box(clazz);
...
}
So in summary, I can not buy in your thoughts. Can you provide other reasons?
Or [~julianhyde], can you give some comments? It seems that you understand my
problem at first. Very thanks if you give me some feedback.
Very appreciate for your work.
was (Author: aron.tao):
[~danny0405]
# For calcite, I just need to box "class" in SqlLiteral.getValue, and then I
can get a reasonable value. If it is easy for Spark to support pruning with
"cast", It will already be done. Besides, I think it is put the cart before the
horse.
# "solve the type consistency", in my opinion, "literal.getValueAs" has done
that, it returns the value in its true type(In accordance with common sense).
# Let's put Spark aside and leave my scenario aside, shouldn't
"literal.getValueAs" process both "int" and "Integer"? At least in Java, int
and Integer are not so different in most case.
So in summary, I can not buy in your thoughts. Can you provide other reasons?
Or [~julianhyde], can you give some comments? It seems that you understand my
problem at first. Very thanks if you give me some feedback.
Very appreciate for your work.
> RexLiteral#getValueAs should consider primitive type
>
>
> Key: CALCITE-3065
> URL: https://issues.apache.org/jira/browse/CALCITE-3065
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: Jiatao Tao
>Priority: Major
> Labels: pull-request-available
> Attachments: image-2019-05-13-12-04-36-365.png,
> image-2019-05-17-08-23-52-735.png
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> !image-2019-05-13-12-04-36-365.png!
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (CALCITE-3065) RexLiteral#getValueAs should consider primitive type
[
https://issues.apache.org/jira/browse/CALCITE-3065?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16842877#comment-16842877
]
Jiatao Tao edited comment on CALCITE-3065 at 5/18/19 2:15 AM:
--
[~danny0405]
# For calcite, I just need to box "class" in SqlLiteral.getValue, and then I
can get a reasonable value. If it is easy for Spark to support pruning with
"cast", It will already be done. Besides, I think it is put the cart before the
horse.
# "solve the type consistency", in my opinion, "literal.getValueAs" has done
that, it returns the value in its true type(In accordance with common sense).
# Let's put Spark aside and leave my scenario aside, shouldn't
"literal.getValueAs" process both "int" and "Integer"? At least in Java, int
and Integer are not so different in most case.
PS. code like this, if you think it is ok, I will provide tests or any other
things you needed:
public T getValueAs(Class clazz) {
clazz = Primitive.box(clazz);
...
}
So in summary, I can not buy in your thoughts. Can you provide other reasons?
Or [~julianhyde], can you give some comments? It seems that you understand my
problem at first. Very thanks if you give me some feedback.
Very appreciate for your work.
was (Author: aron.tao):
[~danny0405]
# For calcite, I just need to box "class" in SqlLiteral.getValue, and then I
can get a reasonable value. If it is easy for Spark to support pruning with
"cast", It will already be done. Besides, I think it is put the cart before the
horse.
# "solve the type consistency", in my opinion, "literal.getValueAs" has done
that, it returns the value in its true type(In accordance with common sense).
# Let's put Spark aside and leave my scenario aside, shouldn't
"literal.getValueAs" process both "int" and "Integer"? At least in Java, int
and Integer are not so different in most case.
PS. code like this:
public T getValueAs(Class clazz) \{
clazz = Primitive.box(clazz);
...
}
So in summary, I can not buy in your thoughts. Can you provide other reasons?
Or [~julianhyde], can you give some comments? It seems that you understand my
problem at first. Very thanks if you give me some feedback.
Very appreciate for your work.
> RexLiteral#getValueAs should consider primitive type
>
>
> Key: CALCITE-3065
> URL: https://issues.apache.org/jira/browse/CALCITE-3065
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: Jiatao Tao
>Priority: Major
> Labels: pull-request-available
> Attachments: image-2019-05-13-12-04-36-365.png,
> image-2019-05-17-08-23-52-735.png
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> !image-2019-05-13-12-04-36-365.png!
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (CALCITE-3065) RexLiteral#getValueAs should consider primitive type
[
https://issues.apache.org/jira/browse/CALCITE-3065?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16842877#comment-16842877
]
Jiatao Tao edited comment on CALCITE-3065 at 5/18/19 2:16 AM:
--
[~danny0405]
# For calcite, I just need to box "class" in SqlLiteral.getValue, and then I
can get a reasonable value. If it is easy for Spark to support pruning with
"cast", It will already be done. Besides, I think it is put the cart before the
horse.
# "solve the type consistency", in my opinion, "literal.getValueAs" has done
that, it returns the value in its true type(In accordance with common sense).
# Let's put Spark aside and leave my scenario aside, shouldn't
"literal.getValueAs" process both "int" and "Integer"? At least in Java, int
and Integer are not so different in most case.
PS. code like this, if you think it is ok, I will provide tests or any other
things you needed:
public T getValueAs(Class clazz) \{
clazz = Primitive.box(clazz);
...
}
So in summary, I can not buy in your thoughts. Can you provide other reasons?
Or [~julianhyde], can you give some comments? It seems that you understand my
problem at first. Very thanks if you give me some feedback.
Very appreciate for your work.
was (Author: aron.tao):
[~danny0405]
# For calcite, I just need to box "class" in SqlLiteral.getValue, and then I
can get a reasonable value. If it is easy for Spark to support pruning with
"cast", It will already be done. Besides, I think it is put the cart before the
horse.
# "solve the type consistency", in my opinion, "literal.getValueAs" has done
that, it returns the value in its true type(In accordance with common sense).
# Let's put Spark aside and leave my scenario aside, shouldn't
"literal.getValueAs" process both "int" and "Integer"? At least in Java, int
and Integer are not so different in most case.
PS. code like this, if you think it is ok, I will provide tests or any other
things you needed:
public T getValueAs(Class clazz) {
clazz = Primitive.box(clazz);
...
}
So in summary, I can not buy in your thoughts. Can you provide other reasons?
Or [~julianhyde], can you give some comments? It seems that you understand my
problem at first. Very thanks if you give me some feedback.
Very appreciate for your work.
> RexLiteral#getValueAs should consider primitive type
>
>
> Key: CALCITE-3065
> URL: https://issues.apache.org/jira/browse/CALCITE-3065
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: Jiatao Tao
>Priority: Major
> Labels: pull-request-available
> Attachments: image-2019-05-13-12-04-36-365.png,
> image-2019-05-17-08-23-52-735.png
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> !image-2019-05-13-12-04-36-365.png!
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (CALCITE-3065) RexLiteral#getValueAs should consider primitive type
[
https://issues.apache.org/jira/browse/CALCITE-3065?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16842877#comment-16842877
]
Jiatao Tao edited comment on CALCITE-3065 at 5/18/19 2:16 AM:
--
[~danny0405]
# For calcite, I just need to box "class" in SqlLiteral.getValue, and then I
can get a reasonable value. If it is easy for Spark to support pruning with
"cast", It will already be done. Besides, I think it is put the cart before the
horse.
# "solve the type consistency", in my opinion, "literal.getValueAs" has done
that, it returns the value in its true type(In accordance with common sense).
# Let's put Spark aside and leave my scenario aside, shouldn't
"literal.getValueAs" process both "int" and "Integer"? At least in Java, int
and Integer are not so different in most case.
PS. code like this, if you think it is ok, I will provide tests or any other
things you needed:
```
public T getValueAs(Class clazz) {
clazz = Primitive.box(clazz);
...
}
```
So in summary, I can not buy in your thoughts. Can you provide other reasons?
Or [~julianhyde], can you give some comments? It seems that you understand my
problem at first. Very thanks if you give me some feedback.
Very appreciate for your work.
was (Author: aron.tao):
[~danny0405]
# For calcite, I just need to box "class" in SqlLiteral.getValue, and then I
can get a reasonable value. If it is easy for Spark to support pruning with
"cast", It will already be done. Besides, I think it is put the cart before the
horse.
# "solve the type consistency", in my opinion, "literal.getValueAs" has done
that, it returns the value in its true type(In accordance with common sense).
# Let's put Spark aside and leave my scenario aside, shouldn't
"literal.getValueAs" process both "int" and "Integer"? At least in Java, int
and Integer are not so different in most case.
PS. code like this, if you think it is ok, I will provide tests or any other
things you needed:
public T getValueAs(Class clazz) \{
clazz = Primitive.box(clazz);
...
}
So in summary, I can not buy in your thoughts. Can you provide other reasons?
Or [~julianhyde], can you give some comments? It seems that you understand my
problem at first. Very thanks if you give me some feedback.
Very appreciate for your work.
> RexLiteral#getValueAs should consider primitive type
>
>
> Key: CALCITE-3065
> URL: https://issues.apache.org/jira/browse/CALCITE-3065
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: Jiatao Tao
>Priority: Major
> Labels: pull-request-available
> Attachments: image-2019-05-13-12-04-36-365.png,
> image-2019-05-17-08-23-52-735.png
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> !image-2019-05-13-12-04-36-365.png!
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (CALCITE-3065) RexLiteral#getValueAs should consider primitive type
[
https://issues.apache.org/jira/browse/CALCITE-3065?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16842877#comment-16842877
]
Jiatao Tao edited comment on CALCITE-3065 at 5/18/19 2:16 AM:
--
[~danny0405]
# For calcite, I just need to box "class" in SqlLiteral.getValue, and then I
can get a reasonable value. If it is easy for Spark to support pruning with
"cast", It will already be done. Besides, I think it is put the cart before the
horse.
# "solve the type consistency", in my opinion, "literal.getValueAs" has done
that, it returns the value in its true type(In accordance with common sense).
# Let's put Spark aside and leave my scenario aside, shouldn't
"literal.getValueAs" process both "int" and "Integer"? At least in Java, int
and Integer are not so different in most case.
PS. code like this, if you think it is ok, I will provide tests or any other
things you needed:
public T getValueAs(Class clazz) \{
clazz = Primitive.box(clazz);
...
}
So in summary, I can not buy in your thoughts. Can you provide other reasons?
Or [~julianhyde], can you give some comments? It seems that you understand my
problem at first. Very thanks if you give me some feedback.
Very appreciate for your work.
was (Author: aron.tao):
[~danny0405]
# For calcite, I just need to box "class" in SqlLiteral.getValue, and then I
can get a reasonable value. If it is easy for Spark to support pruning with
"cast", It will already be done. Besides, I think it is put the cart before the
horse.
# "solve the type consistency", in my opinion, "literal.getValueAs" has done
that, it returns the value in its true type(In accordance with common sense).
# Let's put Spark aside and leave my scenario aside, shouldn't
"literal.getValueAs" process both "int" and "Integer"? At least in Java, int
and Integer are not so different in most case.
PS. code like this, if you think it is ok, I will provide tests or any other
things you needed:
public T getValueAs(Class clazz) \{
clazz = Primitive.box(clazz);
...
}
So in summary, I can not buy in your thoughts. Can you provide other reasons?
Or [~julianhyde], can you give some comments? It seems that you understand my
problem at first. Very thanks if you give me some feedback.
Very appreciate for your work.
> RexLiteral#getValueAs should consider primitive type
>
>
> Key: CALCITE-3065
> URL: https://issues.apache.org/jira/browse/CALCITE-3065
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: Jiatao Tao
>Priority: Major
> Labels: pull-request-available
> Attachments: image-2019-05-13-12-04-36-365.png,
> image-2019-05-17-08-23-52-735.png
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> !image-2019-05-13-12-04-36-365.png!
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (CALCITE-3065) RexLiteral#getValueAs should consider primitive type
[
https://issues.apache.org/jira/browse/CALCITE-3065?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16842877#comment-16842877
]
Jiatao Tao edited comment on CALCITE-3065 at 5/18/19 2:17 AM:
--
[~danny0405]
# For calcite, I just need to box "class" in SqlLiteral.getValue, and then I
can get a reasonable value. If it is easy for Spark to support pruning with
"cast", It will already be done. Besides, I think it is put the cart before the
horse.
# "solve the type consistency", in my opinion, "literal.getValueAs" has done
that, it returns the value in its true type(In accordance with common sense).
# Let's put Spark aside and leave my scenario aside, shouldn't
"literal.getValueAs" process both "int" and "Integer"? At least in Java, int
and Integer are not so different in most case.
PS. code like this, if you think it is ok, I will provide tests or any other
things you needed:
public T getValueAs(Class clazz) \{
clazz = Primitive.box(clazz);
...
}
So in summary, I can not buy in your thoughts. Can you provide other reasons?
Or [~julianhyde], can you give some comments? It seems that you understand my
problem at first. Very thanks if you give me some feedback.
Very appreciate for your work.
was (Author: aron.tao):
[~danny0405]
# For calcite, I just need to box "class" in SqlLiteral.getValue, and then I
can get a reasonable value. If it is easy for Spark to support pruning with
"cast", It will already be done. Besides, I think it is put the cart before the
horse.
# "solve the type consistency", in my opinion, "literal.getValueAs" has done
that, it returns the value in its true type(In accordance with common sense).
# Let's put Spark aside and leave my scenario aside, shouldn't
"literal.getValueAs" process both "int" and "Integer"? At least in Java, int
and Integer are not so different in most case.
PS. code like this, if you think it is ok, I will provide tests or any other
things you needed:
```
public T getValueAs(Class clazz) {
clazz = Primitive.box(clazz);
...
}
```
So in summary, I can not buy in your thoughts. Can you provide other reasons?
Or [~julianhyde], can you give some comments? It seems that you understand my
problem at first. Very thanks if you give me some feedback.
Very appreciate for your work.
> RexLiteral#getValueAs should consider primitive type
>
>
> Key: CALCITE-3065
> URL: https://issues.apache.org/jira/browse/CALCITE-3065
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: Jiatao Tao
>Priority: Major
> Labels: pull-request-available
> Attachments: image-2019-05-13-12-04-36-365.png,
> image-2019-05-17-08-23-52-735.png
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> !image-2019-05-13-12-04-36-365.png!
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CALCITE-3065) RexLiteral#getValueAs should consider primitive type
[ https://issues.apache.org/jira/browse/CALCITE-3065?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jiatao Tao updated CALCITE-3065: Attachment: image-2019-06-02-08-15-35-460.png > RexLiteral#getValueAs should consider primitive type > > > Key: CALCITE-3065 > URL: https://issues.apache.org/jira/browse/CALCITE-3065 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: Jiatao Tao >Priority: Major > Labels: pull-request-available > Attachments: image-2019-05-13-12-04-36-365.png, > image-2019-05-17-08-23-52-735.png, image-2019-06-02-08-15-35-460.png > > Time Spent: 40m > Remaining Estimate: 0h > > !image-2019-05-13-12-04-36-365.png! -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-3065) RexLiteral#getValueAs should consider primitive type
[ https://issues.apache.org/jira/browse/CALCITE-3065?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16853913#comment-16853913 ] Jiatao Tao commented on CALCITE-3065: - Hi [~julianhyde] I can buy in your thoughts about null scenario. But the code below, is all Calcite' API, and `tp.getJavaClass(literal.getType)` returns int not Integer(`type.isNullable` return false.). val tp = new JavaTypeFactoryImpl(RelDataTypeSystem.DEFAULT) literal.getValueAs(tp.getJavaClass(literal.getType).asInstanceOf[java.lang.Class[_]]) !image-2019-06-02-08-15-35-460.png! My point is `JavaTypeFactoryImpl#getJavaClass` may return primitive type(means type is not nullable), shouldn't we consider primitive type in `getValueAs`? > RexLiteral#getValueAs should consider primitive type > > > Key: CALCITE-3065 > URL: https://issues.apache.org/jira/browse/CALCITE-3065 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: Jiatao Tao >Priority: Major > Labels: pull-request-available > Attachments: image-2019-05-13-12-04-36-365.png, > image-2019-05-17-08-23-52-735.png, image-2019-06-02-08-15-35-460.png > > Time Spent: 40m > Remaining Estimate: 0h > > !image-2019-05-13-12-04-36-365.png! -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (CALCITE-3065) RexLiteral#getValueAs should consider primitive type
[ https://issues.apache.org/jira/browse/CALCITE-3065?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16853913#comment-16853913 ] Jiatao Tao edited comment on CALCITE-3065 at 6/2/19 8:20 AM: - Hi [~julianhyde] I can buy in your thoughts about null scenario. But the code below, is all Calcite' API, and `tp.getJavaClass(literal.getType)` returns int not Integer(`type.isNullable` return false.). val tp = new JavaTypeFactoryImpl(RelDataTypeSystem.DEFAULT) literal.getValueAs(tp.getJavaClass(literal.getType).asInstanceOf[java.lang.Class[_]]) !image-2019-06-02-08-15-35-460.png! My point is `JavaTypeFactoryImpl#getJavaClass` may return primitive type(means type is not nullable), shouldn't we consider primitive type in `getValueAs`? Or am I use the API in a wrong way? Hope for your opinion, thanks was (Author: aron.tao): Hi [~julianhyde] I can buy in your thoughts about null scenario. But the code below, is all Calcite' API, and `tp.getJavaClass(literal.getType)` returns int not Integer(`type.isNullable` return false.). val tp = new JavaTypeFactoryImpl(RelDataTypeSystem.DEFAULT) literal.getValueAs(tp.getJavaClass(literal.getType).asInstanceOf[java.lang.Class[_]]) !image-2019-06-02-08-15-35-460.png! My point is `JavaTypeFactoryImpl#getJavaClass` may return primitive type(means type is not nullable), shouldn't we consider primitive type in `getValueAs`? > RexLiteral#getValueAs should consider primitive type > > > Key: CALCITE-3065 > URL: https://issues.apache.org/jira/browse/CALCITE-3065 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: Jiatao Tao >Priority: Major > Labels: pull-request-available > Attachments: image-2019-05-13-12-04-36-365.png, > image-2019-05-17-08-23-52-735.png, image-2019-06-02-08-15-35-460.png > > Time Spent: 40m > Remaining Estimate: 0h > > !image-2019-05-13-12-04-36-365.png! -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (CALCITE-3065) RexLiteral#getValueAs should consider primitive type
[ https://issues.apache.org/jira/browse/CALCITE-3065?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16853913#comment-16853913 ] Jiatao Tao edited comment on CALCITE-3065 at 6/2/19 8:23 AM: - Hi [~julianhyde] I can buy in your thoughts about null scenario. But the code below, is all Calcite' API, and `tp.getJavaClass(literal.getType)` returns int not Integer(`type.isNullable` return false.). ``` val tp = new JavaTypeFactoryImpl(RelDataTypeSystem.DEFAULT) literal.getValueAs(tp.getJavaClass(literal.getType)) ``` !image-2019-06-02-08-15-35-460.png! My point is `JavaTypeFactoryImpl#getJavaClass` may return primitive type(means type is not nullable), shouldn't we consider primitive type in `getValueAs`? Or am I use the API in a wrong way? Hope for your opinion, thanks was (Author: aron.tao): Hi [~julianhyde] I can buy in your thoughts about null scenario. But the code below, is all Calcite' API, and `tp.getJavaClass(literal.getType)` returns int not Integer(`type.isNullable` return false.). val tp = new JavaTypeFactoryImpl(RelDataTypeSystem.DEFAULT) literal.getValueAs(tp.getJavaClass(literal.getType).asInstanceOf[java.lang.Class[_]]) !image-2019-06-02-08-15-35-460.png! My point is `JavaTypeFactoryImpl#getJavaClass` may return primitive type(means type is not nullable), shouldn't we consider primitive type in `getValueAs`? Or am I use the API in a wrong way? Hope for your opinion, thanks > RexLiteral#getValueAs should consider primitive type > > > Key: CALCITE-3065 > URL: https://issues.apache.org/jira/browse/CALCITE-3065 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: Jiatao Tao >Priority: Major > Labels: pull-request-available > Attachments: image-2019-05-13-12-04-36-365.png, > image-2019-05-17-08-23-52-735.png, image-2019-06-02-08-15-35-460.png > > Time Spent: 40m > Remaining Estimate: 0h > > !image-2019-05-13-12-04-36-365.png! -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CALCITE-3065) RexLiteral#getValueAs should consider primitive type
[ https://issues.apache.org/jira/browse/CALCITE-3065?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jiatao Tao updated CALCITE-3065: Attachment: image-2019-06-02-08-43-51-646.png > RexLiteral#getValueAs should consider primitive type > > > Key: CALCITE-3065 > URL: https://issues.apache.org/jira/browse/CALCITE-3065 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: Jiatao Tao >Priority: Major > Labels: pull-request-available > Attachments: image-2019-05-13-12-04-36-365.png, > image-2019-05-17-08-23-52-735.png, image-2019-06-02-08-15-35-460.png, > image-2019-06-02-08-43-51-646.png > > Time Spent: 40m > Remaining Estimate: 0h > > !image-2019-05-13-12-04-36-365.png! -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-3065) RexLiteral#getValueAs should consider primitive type
[ https://issues.apache.org/jira/browse/CALCITE-3065?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16853917#comment-16853917 ] Jiatao Tao commented on CALCITE-3065: - !image-2019-06-02-08-43-51-646.png! > RexLiteral#getValueAs should consider primitive type > > > Key: CALCITE-3065 > URL: https://issues.apache.org/jira/browse/CALCITE-3065 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: Jiatao Tao >Priority: Major > Labels: pull-request-available > Attachments: image-2019-05-13-12-04-36-365.png, > image-2019-05-17-08-23-52-735.png, image-2019-06-02-08-15-35-460.png > > Time Spent: 40m > Remaining Estimate: 0h > > !image-2019-05-13-12-04-36-365.png! -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-3065) RexLiteral#getValueAs should consider primitive type
[ https://issues.apache.org/jira/browse/CALCITE-3065?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16854165#comment-16854165 ] Jiatao Tao commented on CALCITE-3065: - Hi [~julianhyde] truly thanks for your explanation. Seems the name "getJavaClass" is a little confusing, it only does a little thing, not a universal API. And seems that the value that "RexLiteral.getValueAs" returns are all nullable(although we can get this from SqlType). > RexLiteral#getValueAs should consider primitive type > > > Key: CALCITE-3065 > URL: https://issues.apache.org/jira/browse/CALCITE-3065 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: Jiatao Tao >Priority: Major > Labels: pull-request-available > Attachments: image-2019-05-13-12-04-36-365.png, > image-2019-05-17-08-23-52-735.png, image-2019-06-02-08-15-35-460.png, > image-2019-06-02-08-43-51-646.png > > Time Spent: 40m > Remaining Estimate: 0h > > !image-2019-05-13-12-04-36-365.png! -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (CALCITE-3065) RexLiteral#getValueAs should consider primitive type
[ https://issues.apache.org/jira/browse/CALCITE-3065?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16854165#comment-16854165 ] Jiatao Tao edited comment on CALCITE-3065 at 6/3/19 2:52 AM: - Hi [~julianhyde] truly thanks for your explanation. Seems the name "getJavaClass" is a little confusing, it only does a little thing, not a universal API. And in my opinion, an API that can get class from "RelDataType" is useful, so that I can easily get the true value from RexLiteral though getValueAs. And seems that the value that "RexLiteral.getValueAs" returns are all nullable, it may diff from its ori type. was (Author: aron.tao): Hi [~julianhyde] truly thanks for your explanation. Seems the name "getJavaClass" is a little confusing, it only does a little thing, not a universal API. And seems that the value that "RexLiteral.getValueAs" returns are all nullable(although we can get this from SqlType). > RexLiteral#getValueAs should consider primitive type > > > Key: CALCITE-3065 > URL: https://issues.apache.org/jira/browse/CALCITE-3065 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: Jiatao Tao >Priority: Major > Labels: pull-request-available > Attachments: image-2019-05-13-12-04-36-365.png, > image-2019-05-17-08-23-52-735.png, image-2019-06-02-08-15-35-460.png, > image-2019-06-02-08-43-51-646.png > > Time Spent: 50m > Remaining Estimate: 0h > > !image-2019-05-13-12-04-36-365.png! -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CALCITE-3770) Minor change "EnumerableCalcRel" to "EnumerableCalcRel"
Jiatao Tao created CALCITE-3770: --- Summary: Minor change "EnumerableCalcRel" to "EnumerableCalcRel" Key: CALCITE-3770 URL: https://issues.apache.org/jira/browse/CALCITE-3770 Project: Calcite Issue Type: Improvement Reporter: Jiatao Tao EnumerableCalcRel appears in many places in code, but the class's name is EnumerableCalc. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-3770) Minor change "EnumerableCalcRel" to "EnumerableCalcRel"
[ https://issues.apache.org/jira/browse/CALCITE-3770?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17030403#comment-17030403 ] Jiatao Tao commented on CALCITE-3770: - I don't know if it is on purpose, but it seems confusing when I want to find the class EnumerableCalcRel but I can not find it. > Minor change "EnumerableCalcRel" to "EnumerableCalcRel" > --- > > Key: CALCITE-3770 > URL: https://issues.apache.org/jira/browse/CALCITE-3770 > Project: Calcite > Issue Type: Improvement >Reporter: Jiatao Tao >Priority: Trivial > > EnumerableCalcRel appears in many places in code, but the class's name is > EnumerableCalc. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Issue Comment Deleted] (CALCITE-3770) Minor change "EnumerableCalcRel" to "EnumerableCalcRel"
[ https://issues.apache.org/jira/browse/CALCITE-3770?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jiatao Tao updated CALCITE-3770: Comment: was deleted (was: I don't know if it is on purpose, but it seems confusing when I want to find the class EnumerableCalcRel but I can not find it. ) > Minor change "EnumerableCalcRel" to "EnumerableCalcRel" > --- > > Key: CALCITE-3770 > URL: https://issues.apache.org/jira/browse/CALCITE-3770 > Project: Calcite > Issue Type: Improvement >Reporter: Jiatao Tao >Priority: Trivial > > EnumerableCalcRel appears in many places in code, but the class's name is > EnumerableCalc. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CALCITE-3770) Minor change "EnumerableCalcRel" to "EnumerableCalcRel"
[ https://issues.apache.org/jira/browse/CALCITE-3770?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jiatao Tao updated CALCITE-3770: Description: EnumerableCalcRel appears in many places in code, but the class's name is EnumerableCalc. I don't know if it is on purpose, but it seems confusing when I want to find the class EnumerableCalcRel but I can not find it. was:EnumerableCalcRel appears in many places in code, but the class's name is EnumerableCalc. > Minor change "EnumerableCalcRel" to "EnumerableCalcRel" > --- > > Key: CALCITE-3770 > URL: https://issues.apache.org/jira/browse/CALCITE-3770 > Project: Calcite > Issue Type: Improvement >Reporter: Jiatao Tao >Priority: Trivial > > EnumerableCalcRel appears in many places in code, but the class's name is > EnumerableCalc. > I don't know if it is on purpose, but it seems confusing when I want to find > the class EnumerableCalcRel but I can not find it. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-3770) Minor change "EnumerableCalcRel" to "EnumerableCalcRel"
[ https://issues.apache.org/jira/browse/CALCITE-3770?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17030405#comment-17030405 ] Jiatao Tao commented on CALCITE-3770: - PR: https://github.com/apache/calcite/pull/1706 > Minor change "EnumerableCalcRel" to "EnumerableCalcRel" > --- > > Key: CALCITE-3770 > URL: https://issues.apache.org/jira/browse/CALCITE-3770 > Project: Calcite > Issue Type: Improvement >Reporter: Jiatao Tao >Priority: Trivial > > EnumerableCalcRel appears in many places in code, but the class's name is > EnumerableCalc. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-3770) Minor change "EnumerableCalcRel" to "EnumerableCalcRel"
[ https://issues.apache.org/jira/browse/CALCITE-3770?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17035336#comment-17035336 ] Jiatao Tao commented on CALCITE-3770: - Hi [~julianhyde] Thanks a lot, I'll check them all latter. > Minor change "EnumerableCalcRel" to "EnumerableCalcRel" > --- > > Key: CALCITE-3770 > URL: https://issues.apache.org/jira/browse/CALCITE-3770 > Project: Calcite > Issue Type: Improvement >Reporter: Jiatao Tao >Priority: Trivial > > EnumerableCalcRel appears in many places in code, but the class's name is > EnumerableCalc. > I don't know if it is on purpose, but it seems confusing when I want to find > the class EnumerableCalcRel but I can not find it. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (CALCITE-3770) Minor change "EnumerableCalcRel" to "EnumerableCalcRel"
[ https://issues.apache.org/jira/browse/CALCITE-3770?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17035336#comment-17035336 ] Jiatao Tao edited comment on CALCITE-3770 at 2/12/20 12:48 PM: --- Hi [~julianhyde] Thanks a lot, I'll fix the formatting and check the sub rel name latter. was (Author: aron.tao): Hi [~julianhyde] Thanks a lot, I'll check them all latter. > Minor change "EnumerableCalcRel" to "EnumerableCalcRel" > --- > > Key: CALCITE-3770 > URL: https://issues.apache.org/jira/browse/CALCITE-3770 > Project: Calcite > Issue Type: Improvement >Reporter: Jiatao Tao >Priority: Trivial > Labels: pull-request-available > Time Spent: 10m > Remaining Estimate: 0h > > EnumerableCalcRel appears in many places in code, but the class's name is > EnumerableCalc. > I don't know if it is on purpose, but it seems confusing when I want to find > the class EnumerableCalcRel but I can not find it. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (CALCITE-3770) Minor change "EnumerableCalcRel" to "EnumerableCalcRel"
[ https://issues.apache.org/jira/browse/CALCITE-3770?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17035336#comment-17035336 ] Jiatao Tao edited comment on CALCITE-3770 at 2/12/20 1:24 PM: -- Hi [~julianhyde] Thanks a lot, I'll fix the formatting and check the list latter. was (Author: aron.tao): Hi [~julianhyde] Thanks a lot, I'll fix the formatting and check the sub rel name latter. > Minor change "EnumerableCalcRel" to "EnumerableCalcRel" > --- > > Key: CALCITE-3770 > URL: https://issues.apache.org/jira/browse/CALCITE-3770 > Project: Calcite > Issue Type: Improvement >Reporter: Jiatao Tao >Priority: Trivial > Labels: pull-request-available > Time Spent: 10m > Remaining Estimate: 0h > > EnumerableCalcRel appears in many places in code, but the class's name is > EnumerableCalc. > I don't know if it is on purpose, but it seems confusing when I want to find > the class EnumerableCalcRel but I can not find it. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CALCITE-3870) set "SqlToRelConverter.ConfigBuilder#expand" default to false
[ https://issues.apache.org/jira/browse/CALCITE-3870?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jiatao Tao updated CALCITE-3870: Description: Now the default "expand" in SqlToRelConverter.ConfigBuilder is true but in calcite's main process, actually, it is false( `withExpand(THREAD_EXPAND.get())`) That leads we need to explicitly set `withExpand` to false when we use SqlToRelConverter. So I think we should change the default to "false" in SqlToRelConverter.ConfigBuilder. !https://mail.google.com/mail/u/0?ui=2&ik=09d5de6bf3&attid=0.1&permmsgid=msg-a:r-1571046416348666034&th=17106774a5349d1d&view=fimg&sz=s0-l75-ft&attbid=ANGjdJ_IjYbiwT8IKlaiAIDzbkq_ehCBktd4DzCYr14Ppst6lBftqMbrrWu8hzGpN2wpCz46a3F1FKvfD_miGHkC-EMx509KPC4FEovxtN2M0WcU1up209hyLtKoZqE&disp=emb&realattid=ii_k8460q950! !https://mail.google.com/mail/u/0?ui=2&ik=09d5de6bf3&attid=0.2&permmsgid=msg-a:r-1571046416348666034&th=17106774a5349d1d&view=fimg&sz=s0-l75-ft&attbid=ANGjdJ_K-EyE_x0Vo66h6sHRzpEOxIE5qTzuujqG8WqZVPdprgC3khwcO_8OLLai-8ikrMRC9ksO-xAzqe2HFr-QYM1lzQDLYfSlD5x-eOXbww9CNsb5cgu-979N1lU&disp=emb&realattid=ii_k846zj601! was: Now the default "expand" in SqlToRelConverter.ConfigBuilder is true but in calcite's main process, actually, it is false( `withExpand(THREAD_EXPAND.get())`) That leads we need to explicitly set `withExpand` to false when we use SqlToRelConverter. So I think we should change the default to "false" in SqlToRelConverter.ConfigBuilder. !https://mail.google.com/mail/u/0?ui=2&ik=09d5de6bf3&attid=0.1&permmsgid=msg-a:r-1571046416348666034&th=17106774a5349d1d&view=fimg&sz=s0-l75-ft&attbid=ANGjdJ_IjYbiwT8IKlaiAIDzbkq_ehCBktd4DzCYr14Ppst6lBftqMbrrWu8hzGpN2wpCz46a3F1FKvfD_miGHkC-EMx509KPC4FEovxtN2M0WcU1up209hyLtKoZqE&disp=emb&realattid=ii_k8460q950! > set "SqlToRelConverter.ConfigBuilder#expand" default to false > - > > Key: CALCITE-3870 > URL: https://issues.apache.org/jira/browse/CALCITE-3870 > Project: Calcite > Issue Type: Bug > Components: core >Reporter: Jiatao Tao >Priority: Minor > > Now the default "expand" in SqlToRelConverter.ConfigBuilder is true but in > calcite's main process, actually, it is false( > `withExpand(THREAD_EXPAND.get())`) > > That leads we need to explicitly set `withExpand` to false when we use > SqlToRelConverter. > > So I think we should change the default to "false" in > SqlToRelConverter.ConfigBuilder. > > > !https://mail.google.com/mail/u/0?ui=2&ik=09d5de6bf3&attid=0.1&permmsgid=msg-a:r-1571046416348666034&th=17106774a5349d1d&view=fimg&sz=s0-l75-ft&attbid=ANGjdJ_IjYbiwT8IKlaiAIDzbkq_ehCBktd4DzCYr14Ppst6lBftqMbrrWu8hzGpN2wpCz46a3F1FKvfD_miGHkC-EMx509KPC4FEovxtN2M0WcU1up209hyLtKoZqE&disp=emb&realattid=ii_k8460q950! > > !https://mail.google.com/mail/u/0?ui=2&ik=09d5de6bf3&attid=0.2&permmsgid=msg-a:r-1571046416348666034&th=17106774a5349d1d&view=fimg&sz=s0-l75-ft&attbid=ANGjdJ_K-EyE_x0Vo66h6sHRzpEOxIE5qTzuujqG8WqZVPdprgC3khwcO_8OLLai-8ikrMRC9ksO-xAzqe2HFr-QYM1lzQDLYfSlD5x-eOXbww9CNsb5cgu-979N1lU&disp=emb&realattid=ii_k846zj601! -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CALCITE-3870) set "SqlToRelConverter.ConfigBuilder#expand" default to false
Jiatao Tao created CALCITE-3870: --- Summary: set "SqlToRelConverter.ConfigBuilder#expand" default to false Key: CALCITE-3870 URL: https://issues.apache.org/jira/browse/CALCITE-3870 Project: Calcite Issue Type: Bug Components: core Reporter: Jiatao Tao Now the default "expand" in SqlToRelConverter.ConfigBuilder is true but in calcite's main process, actually, it is false( `withExpand(THREAD_EXPAND.get())`) That leads we need to explicitly set `withExpand` to false when we use SqlToRelConverter. So I think we should change the default to "false" in SqlToRelConverter.ConfigBuilder. !https://mail.google.com/mail/u/0?ui=2&ik=09d5de6bf3&attid=0.1&permmsgid=msg-a:r-1571046416348666034&th=17106774a5349d1d&view=fimg&sz=s0-l75-ft&attbid=ANGjdJ_IjYbiwT8IKlaiAIDzbkq_ehCBktd4DzCYr14Ppst6lBftqMbrrWu8hzGpN2wpCz46a3F1FKvfD_miGHkC-EMx509KPC4FEovxtN2M0WcU1up209hyLtKoZqE&disp=emb&realattid=ii_k8460q950! -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CALCITE-3870) set "SqlToRelConverter.ConfigBuilder#expand" default to false
[ https://issues.apache.org/jira/browse/CALCITE-3870?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jiatao Tao updated CALCITE-3870: Attachment: image-2020-03-25-14-05-04-011.png > set "SqlToRelConverter.ConfigBuilder#expand" default to false > - > > Key: CALCITE-3870 > URL: https://issues.apache.org/jira/browse/CALCITE-3870 > Project: Calcite > Issue Type: Bug > Components: core >Reporter: Jiatao Tao >Priority: Minor > Labels: pull-request-available > Attachments: image-2020-03-25-14-05-04-011.png > > Time Spent: 20m > Remaining Estimate: 0h > > Now the default "expand" in SqlToRelConverter.ConfigBuilder is true but in > calcite's main process, actually, it is false( > `withExpand(THREAD_EXPAND.get())`) > > That leads we need to explicitly set `withExpand` to false when we use > SqlToRelConverter. > > So I think we should change the default to "false" in > SqlToRelConverter.ConfigBuilder. > > > !https://mail.google.com/mail/u/0?ui=2&ik=09d5de6bf3&attid=0.1&permmsgid=msg-a:r-1571046416348666034&th=17106774a5349d1d&view=fimg&sz=s0-l75-ft&attbid=ANGjdJ_IjYbiwT8IKlaiAIDzbkq_ehCBktd4DzCYr14Ppst6lBftqMbrrWu8hzGpN2wpCz46a3F1FKvfD_miGHkC-EMx509KPC4FEovxtN2M0WcU1up209hyLtKoZqE&disp=emb&realattid=ii_k8460q950! > > !https://mail.google.com/mail/u/0?ui=2&ik=09d5de6bf3&attid=0.2&permmsgid=msg-a:r-1571046416348666034&th=17106774a5349d1d&view=fimg&sz=s0-l75-ft&attbid=ANGjdJ_K-EyE_x0Vo66h6sHRzpEOxIE5qTzuujqG8WqZVPdprgC3khwcO_8OLLai-8ikrMRC9ksO-xAzqe2HFr-QYM1lzQDLYfSlD5x-eOXbww9CNsb5cgu-979N1lU&disp=emb&realattid=ii_k846zj601! -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-3870) set "SqlToRelConverter.ConfigBuilder#expand" default to false
[ https://issues.apache.org/jira/browse/CALCITE-3870?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17066415#comment-17066415 ] Jiatao Tao commented on CALCITE-3870: - [~julianhyde] Ok, And seems there are many tests failed because we contract SqlToRelConverter.Config with default "expand" config, like in PlannerImpl#rel. !image-2020-03-25-14-05-04-011.png|width=543,height=205! And here comes two solutions to me: * add `withExpand(true)` in every failed UT, as a workaround. ** advantage: less workload, ** disadvantage: *** still have lots of `withExpand(true)` in our code *** will impact on existing Calcite users if they didn't claim "expand" to false when they use SqlToRelConverter, it is a breaking change. * add the expand process(SubQueryRemoveRule, may be more rules) to the process of org.apache.calcite.sql2rel.RelDecorrelator#decorrelateQuery. ** advantage: if the existing users do `decorrelateQuery` after SqlToRelConverter(I think most will do that), This change has little effect on them. ** disadvantage: more workload compare solutions1. Hope to hear your voice. > set "SqlToRelConverter.ConfigBuilder#expand" default to false > - > > Key: CALCITE-3870 > URL: https://issues.apache.org/jira/browse/CALCITE-3870 > Project: Calcite > Issue Type: Bug > Components: core >Reporter: Jiatao Tao >Priority: Minor > Labels: pull-request-available > Attachments: image-2020-03-25-14-05-04-011.png > > Time Spent: 20m > Remaining Estimate: 0h > > Now the default "expand" in SqlToRelConverter.ConfigBuilder is true but in > calcite's main process, actually, it is false( > `withExpand(THREAD_EXPAND.get())`) > > That leads we need to explicitly set `withExpand` to false when we use > SqlToRelConverter. > > So I think we should change the default to "false" in > SqlToRelConverter.ConfigBuilder. > > > !https://mail.google.com/mail/u/0?ui=2&ik=09d5de6bf3&attid=0.1&permmsgid=msg-a:r-1571046416348666034&th=17106774a5349d1d&view=fimg&sz=s0-l75-ft&attbid=ANGjdJ_IjYbiwT8IKlaiAIDzbkq_ehCBktd4DzCYr14Ppst6lBftqMbrrWu8hzGpN2wpCz46a3F1FKvfD_miGHkC-EMx509KPC4FEovxtN2M0WcU1up209hyLtKoZqE&disp=emb&realattid=ii_k8460q950! > > !https://mail.google.com/mail/u/0?ui=2&ik=09d5de6bf3&attid=0.2&permmsgid=msg-a:r-1571046416348666034&th=17106774a5349d1d&view=fimg&sz=s0-l75-ft&attbid=ANGjdJ_K-EyE_x0Vo66h6sHRzpEOxIE5qTzuujqG8WqZVPdprgC3khwcO_8OLLai-8ikrMRC9ksO-xAzqe2HFr-QYM1lzQDLYfSlD5x-eOXbww9CNsb5cgu-979N1lU&disp=emb&realattid=ii_k846zj601! -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (CALCITE-3870) set "SqlToRelConverter.ConfigBuilder#expand" default to false
[ https://issues.apache.org/jira/browse/CALCITE-3870?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17066415#comment-17066415 ] Jiatao Tao edited comment on CALCITE-3870 at 3/25/20, 6:23 AM: --- [~julianhyde] Ok, And seems there are many tests failed because we contract SqlToRelConverter.Config with default "expand" config, like in PlannerImpl#rel. !image-2020-03-25-14-05-04-011.png|width=543,height=205! And here comes two solutions to me: * add `withExpand(true)` in every failed UT, as a workaround. ** advantage: less workload, ** disadvantage: *** still have lots of `withExpand(true)` in our code *** will impact on existing Calcite users if they didn't claim "expand" to false when they use SqlToRelConverter, it is a breaking change. * add the expand process(SubQueryRemoveRule, may be more rules) to the process of org.apache.calcite.sql2rel.RelDecorrelator#decorrelateQuery. ** advantage: if the existing users do `decorrelateQuery` after SqlToRelConverter(I think most will do that), This change has little effect on them. ** disadvantage: more workload compare solutions1. This change's impact seems much bigger than I first thought(The impact to the existing user who without setting expand explicitly), hope to hear more voice about this. Thanks again was (Author: aron.tao): [~julianhyde] Ok, And seems there are many tests failed because we contract SqlToRelConverter.Config with default "expand" config, like in PlannerImpl#rel. !image-2020-03-25-14-05-04-011.png|width=543,height=205! And here comes two solutions to me: * add `withExpand(true)` in every failed UT, as a workaround. ** advantage: less workload, ** disadvantage: *** still have lots of `withExpand(true)` in our code *** will impact on existing Calcite users if they didn't claim "expand" to false when they use SqlToRelConverter, it is a breaking change. * add the expand process(SubQueryRemoveRule, may be more rules) to the process of org.apache.calcite.sql2rel.RelDecorrelator#decorrelateQuery. ** advantage: if the existing users do `decorrelateQuery` after SqlToRelConverter(I think most will do that), This change has little effect on them. ** disadvantage: more workload compare solutions1. Hope to hear your voice. > set "SqlToRelConverter.ConfigBuilder#expand" default to false > - > > Key: CALCITE-3870 > URL: https://issues.apache.org/jira/browse/CALCITE-3870 > Project: Calcite > Issue Type: Bug > Components: core >Reporter: Jiatao Tao >Priority: Minor > Labels: pull-request-available > Attachments: image-2020-03-25-14-05-04-011.png > > Time Spent: 20m > Remaining Estimate: 0h > > Now the default "expand" in SqlToRelConverter.ConfigBuilder is true but in > calcite's main process, actually, it is false( > `withExpand(THREAD_EXPAND.get())`) > > That leads we need to explicitly set `withExpand` to false when we use > SqlToRelConverter. > > So I think we should change the default to "false" in > SqlToRelConverter.ConfigBuilder. > > > !https://mail.google.com/mail/u/0?ui=2&ik=09d5de6bf3&attid=0.1&permmsgid=msg-a:r-1571046416348666034&th=17106774a5349d1d&view=fimg&sz=s0-l75-ft&attbid=ANGjdJ_IjYbiwT8IKlaiAIDzbkq_ehCBktd4DzCYr14Ppst6lBftqMbrrWu8hzGpN2wpCz46a3F1FKvfD_miGHkC-EMx509KPC4FEovxtN2M0WcU1up209hyLtKoZqE&disp=emb&realattid=ii_k8460q950! > > !https://mail.google.com/mail/u/0?ui=2&ik=09d5de6bf3&attid=0.2&permmsgid=msg-a:r-1571046416348666034&th=17106774a5349d1d&view=fimg&sz=s0-l75-ft&attbid=ANGjdJ_K-EyE_x0Vo66h6sHRzpEOxIE5qTzuujqG8WqZVPdprgC3khwcO_8OLLai-8ikrMRC9ksO-xAzqe2HFr-QYM1lzQDLYfSlD5x-eOXbww9CNsb5cgu-979N1lU&disp=emb&realattid=ii_k846zj601! -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (CALCITE-3870) set "SqlToRelConverter.ConfigBuilder#expand" default to false
[ https://issues.apache.org/jira/browse/CALCITE-3870?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17066415#comment-17066415 ] Jiatao Tao edited comment on CALCITE-3870 at 3/25/20, 6:25 AM: --- [~julianhyde] Ok, And seems there are many tests failed because we contract SqlToRelConverter.Config with the default "expand" config(true), like in PlannerImpl#rel. !image-2020-03-25-14-05-04-011.png|width=543,height=205! And here comes two solutions to me: * add `withExpand(true)` in every failed UT, as a workaround, mainly for passing UT. ** advantage: less workload ** disadvantage: *** still have lots of `withExpand(true)` in our code *** will impact on existing Calcite users if they didn't claim "expand" to false when they use SqlToRelConverter, it is a breaking change. * add the expand process(SubQueryRemoveRule, may be more rules) to the process of org.apache.calcite.sql2rel.RelDecorrelator#decorrelateQuery. ** advantage: if the existing users do `decorrelateQuery` after SqlToRelConverter(I think most will do that), This change has little effect on them. ** disadvantage: more workload compare solutions1. This change's impact seems much bigger than I first thought(The impact to the existing user who without setting expand explicitly), hope to hear more voice about this. Thanks again was (Author: aron.tao): [~julianhyde] Ok, And seems there are many tests failed because we contract SqlToRelConverter.Config with default "expand" config, like in PlannerImpl#rel. !image-2020-03-25-14-05-04-011.png|width=543,height=205! And here comes two solutions to me: * add `withExpand(true)` in every failed UT, as a workaround. ** advantage: less workload, ** disadvantage: *** still have lots of `withExpand(true)` in our code *** will impact on existing Calcite users if they didn't claim "expand" to false when they use SqlToRelConverter, it is a breaking change. * add the expand process(SubQueryRemoveRule, may be more rules) to the process of org.apache.calcite.sql2rel.RelDecorrelator#decorrelateQuery. ** advantage: if the existing users do `decorrelateQuery` after SqlToRelConverter(I think most will do that), This change has little effect on them. ** disadvantage: more workload compare solutions1. This change's impact seems much bigger than I first thought(The impact to the existing user who without setting expand explicitly), hope to hear more voice about this. Thanks again > set "SqlToRelConverter.ConfigBuilder#expand" default to false > - > > Key: CALCITE-3870 > URL: https://issues.apache.org/jira/browse/CALCITE-3870 > Project: Calcite > Issue Type: Bug > Components: core >Reporter: Jiatao Tao >Priority: Minor > Labels: pull-request-available > Attachments: image-2020-03-25-14-05-04-011.png > > Time Spent: 20m > Remaining Estimate: 0h > > Now the default "expand" in SqlToRelConverter.ConfigBuilder is true but in > calcite's main process, actually, it is false( > `withExpand(THREAD_EXPAND.get())`) > > That leads we need to explicitly set `withExpand` to false when we use > SqlToRelConverter. > > So I think we should change the default to "false" in > SqlToRelConverter.ConfigBuilder. > > > !https://mail.google.com/mail/u/0?ui=2&ik=09d5de6bf3&attid=0.1&permmsgid=msg-a:r-1571046416348666034&th=17106774a5349d1d&view=fimg&sz=s0-l75-ft&attbid=ANGjdJ_IjYbiwT8IKlaiAIDzbkq_ehCBktd4DzCYr14Ppst6lBftqMbrrWu8hzGpN2wpCz46a3F1FKvfD_miGHkC-EMx509KPC4FEovxtN2M0WcU1up209hyLtKoZqE&disp=emb&realattid=ii_k8460q950! > > !https://mail.google.com/mail/u/0?ui=2&ik=09d5de6bf3&attid=0.2&permmsgid=msg-a:r-1571046416348666034&th=17106774a5349d1d&view=fimg&sz=s0-l75-ft&attbid=ANGjdJ_K-EyE_x0Vo66h6sHRzpEOxIE5qTzuujqG8WqZVPdprgC3khwcO_8OLLai-8ikrMRC9ksO-xAzqe2HFr-QYM1lzQDLYfSlD5x-eOXbww9CNsb5cgu-979N1lU&disp=emb&realattid=ii_k846zj601! -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (CALCITE-3870) set "SqlToRelConverter.ConfigBuilder#expand" default to false
[ https://issues.apache.org/jira/browse/CALCITE-3870?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17066415#comment-17066415 ] Jiatao Tao edited comment on CALCITE-3870 at 3/25/20, 6:43 AM: --- HI [~julianhyde] Thanks for your comment. Seems there are many tests failed because we contract SqlToRelConverter.Config with the default "expand" config(true), like in PlannerImpl#rel. !image-2020-03-25-14-05-04-011.png|width=543,height=205! And here comes two solutions to me: * add `withExpand(true)` in every failed UT, as a workaround, mainly for passing UT. ** advantage: less workload ** disadvantage: *** still have lots of `withExpand(true)` in our code *** will impact on existing Calcite users if they didn't claim "expand" to false when they use SqlToRelConverter, it is a breaking change. * add the expand process(SubQueryRemoveRule, may be more rules) to the process of org.apache.calcite.sql2rel.RelDecorrelator#decorrelateQuery. ** advantage: if the existing users do `decorrelateQuery` after SqlToRelConverter(I think most will do that), This change has little effect on them. ** disadvantage: more workload compare solutions1. This change's impact seems much bigger than I first thought(The impact to the existing user who without setting expand explicitly), hope to hear more voice about this. Thanks again was (Author: aron.tao): [~julianhyde] Ok, And seems there are many tests failed because we contract SqlToRelConverter.Config with the default "expand" config(true), like in PlannerImpl#rel. !image-2020-03-25-14-05-04-011.png|width=543,height=205! And here comes two solutions to me: * add `withExpand(true)` in every failed UT, as a workaround, mainly for passing UT. ** advantage: less workload ** disadvantage: *** still have lots of `withExpand(true)` in our code *** will impact on existing Calcite users if they didn't claim "expand" to false when they use SqlToRelConverter, it is a breaking change. * add the expand process(SubQueryRemoveRule, may be more rules) to the process of org.apache.calcite.sql2rel.RelDecorrelator#decorrelateQuery. ** advantage: if the existing users do `decorrelateQuery` after SqlToRelConverter(I think most will do that), This change has little effect on them. ** disadvantage: more workload compare solutions1. This change's impact seems much bigger than I first thought(The impact to the existing user who without setting expand explicitly), hope to hear more voice about this. Thanks again > set "SqlToRelConverter.ConfigBuilder#expand" default to false > - > > Key: CALCITE-3870 > URL: https://issues.apache.org/jira/browse/CALCITE-3870 > Project: Calcite > Issue Type: Bug > Components: core >Reporter: Jiatao Tao >Priority: Minor > Labels: pull-request-available > Attachments: image-2020-03-25-14-05-04-011.png > > Time Spent: 20m > Remaining Estimate: 0h > > Now the default "expand" in SqlToRelConverter.ConfigBuilder is true but in > calcite's main process, actually, it is false( > `withExpand(THREAD_EXPAND.get())`) > > That leads we need to explicitly set `withExpand` to false when we use > SqlToRelConverter. > > So I think we should change the default to "false" in > SqlToRelConverter.ConfigBuilder. > > > !https://mail.google.com/mail/u/0?ui=2&ik=09d5de6bf3&attid=0.1&permmsgid=msg-a:r-1571046416348666034&th=17106774a5349d1d&view=fimg&sz=s0-l75-ft&attbid=ANGjdJ_IjYbiwT8IKlaiAIDzbkq_ehCBktd4DzCYr14Ppst6lBftqMbrrWu8hzGpN2wpCz46a3F1FKvfD_miGHkC-EMx509KPC4FEovxtN2M0WcU1up209hyLtKoZqE&disp=emb&realattid=ii_k8460q950! > > !https://mail.google.com/mail/u/0?ui=2&ik=09d5de6bf3&attid=0.2&permmsgid=msg-a:r-1571046416348666034&th=17106774a5349d1d&view=fimg&sz=s0-l75-ft&attbid=ANGjdJ_K-EyE_x0Vo66h6sHRzpEOxIE5qTzuujqG8WqZVPdprgC3khwcO_8OLLai-8ikrMRC9ksO-xAzqe2HFr-QYM1lzQDLYfSlD5x-eOXbww9CNsb5cgu-979N1lU&disp=emb&realattid=ii_k846zj601! -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (CALCITE-2057) StackOverflowError when running a JDBC query
[
https://issues.apache.org/jira/browse/CALCITE-2057?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17087564#comment-17087564
]
Jiatao Tao edited comment on CALCITE-2057 at 4/20/20, 10:02 AM:
any update, 1.22 still meets this problem?
was (Author: aron.tao):
any update?
> StackOverflowError when running a JDBC query
>
>
> Key: CALCITE-2057
> URL: https://issues.apache.org/jira/browse/CALCITE-2057
> Project: Calcite
> Issue Type: Bug
>Affects Versions: 1.14.0
>Reporter: Eyal Segal
>Priority: Minor
>
> I've ran the following code:
> {code:java}
> try (ResultSet rs = statement.executeQuery(
> "SELECT p.name, r.views " +
> "FROM reports.a as r " +
> "INNER JOIN main.b as p ON p.id = CAST(r.p_id AS INT) AND
> p.id = 196 " +
> "WHERE p.id = 196 " +
> "AND r.p_id = 196 " +
> "AND r.data_timestamp = TIMESTAMP '2017-11-14 00:00:00'
> " )) {
> {code}
> And I'm getting the following StackOverflowError:
> {code:java}
> Exception in thread "main" java.lang.StackOverflowError
> at
> com.google.common.collect.ImmutableList.indexOf(ImmutableList.java:339)
> at GeneratedMetadataHandler_RowCount.getRowCount_$(Unknown Source)
> at GeneratedMetadataHandler_RowCount.getRowCount(Unknown Source)
> at
> org.apache.calcite.rel.metadata.RelMetadataQuery.getRowCount(RelMetadataQuery.java:235)
> at
> org.apache.calcite.rel.metadata.RelMdRowCount.getRowCount(RelMdRowCount.java:71)
> at GeneratedMetadataHandler_RowCount.getRowCount_$(Unknown Source)
> at GeneratedMetadataHandler_RowCount.getRowCount(Unknown Source)
> at
> org.apache.calcite.rel.metadata.RelMetadataQuery.getRowCount(RelMetadataQuery.java:235)
> at
> org.apache.calcite.rel.metadata.RelMdUtil.estimateFilteredRows(RelMdUtil.java:718)
> at
> org.apache.calcite.rel.metadata.RelMdRowCount.getRowCount(RelMdRowCount.java:123)
> at GeneratedMetadataHandler_RowCount.getRowCount_$(Unknown Source)
> at GeneratedMetadataHandler_RowCount.getRowCount(Unknown Source)
> at
> org.apache.calcite.rel.metadata.RelMetadataQuery.getRowCount(RelMetadataQuery.java:235)
> at
> org.apache.calcite.rel.metadata.RelMdRowCount.getRowCount(RelMdRowCount.java:71)
> at GeneratedMetadataHandler_RowCount.getRowCount_$(Unknown Source)
> at GeneratedMetadataHandler_RowCount.getRowCount(Unknown Source)
> at
> org.apache.calcite.rel.metadata.RelMetadataQuery.getRowCount(RelMetadataQuery.java:235)
> at
> org.apache.calcite.rel.metadata.RelMdUtil.estimateFilteredRows(RelMdUtil.java:718)
> at
> org.apache.calcite.rel.metadata.RelMdRowCount.getRowCount(RelMdRowCount.java:123)
> at GeneratedMetadataHandler_RowCount.getRowCount_$(Unknown Source)
> at GeneratedMetadataHandler_RowCount.getRowCount(Unknown Source)
> ...
> {code}
> It's solved by removing "AND p.id = 196" from the INNER JOIN, but it's still
> worth fixing.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-2057) StackOverflowError when running a JDBC query
[
https://issues.apache.org/jira/browse/CALCITE-2057?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17087564#comment-17087564
]
Jiatao Tao commented on CALCITE-2057:
-
any update?
> StackOverflowError when running a JDBC query
>
>
> Key: CALCITE-2057
> URL: https://issues.apache.org/jira/browse/CALCITE-2057
> Project: Calcite
> Issue Type: Bug
>Affects Versions: 1.14.0
>Reporter: Eyal Segal
>Priority: Minor
>
> I've ran the following code:
> {code:java}
> try (ResultSet rs = statement.executeQuery(
> "SELECT p.name, r.views " +
> "FROM reports.a as r " +
> "INNER JOIN main.b as p ON p.id = CAST(r.p_id AS INT) AND
> p.id = 196 " +
> "WHERE p.id = 196 " +
> "AND r.p_id = 196 " +
> "AND r.data_timestamp = TIMESTAMP '2017-11-14 00:00:00'
> " )) {
> {code}
> And I'm getting the following StackOverflowError:
> {code:java}
> Exception in thread "main" java.lang.StackOverflowError
> at
> com.google.common.collect.ImmutableList.indexOf(ImmutableList.java:339)
> at GeneratedMetadataHandler_RowCount.getRowCount_$(Unknown Source)
> at GeneratedMetadataHandler_RowCount.getRowCount(Unknown Source)
> at
> org.apache.calcite.rel.metadata.RelMetadataQuery.getRowCount(RelMetadataQuery.java:235)
> at
> org.apache.calcite.rel.metadata.RelMdRowCount.getRowCount(RelMdRowCount.java:71)
> at GeneratedMetadataHandler_RowCount.getRowCount_$(Unknown Source)
> at GeneratedMetadataHandler_RowCount.getRowCount(Unknown Source)
> at
> org.apache.calcite.rel.metadata.RelMetadataQuery.getRowCount(RelMetadataQuery.java:235)
> at
> org.apache.calcite.rel.metadata.RelMdUtil.estimateFilteredRows(RelMdUtil.java:718)
> at
> org.apache.calcite.rel.metadata.RelMdRowCount.getRowCount(RelMdRowCount.java:123)
> at GeneratedMetadataHandler_RowCount.getRowCount_$(Unknown Source)
> at GeneratedMetadataHandler_RowCount.getRowCount(Unknown Source)
> at
> org.apache.calcite.rel.metadata.RelMetadataQuery.getRowCount(RelMetadataQuery.java:235)
> at
> org.apache.calcite.rel.metadata.RelMdRowCount.getRowCount(RelMdRowCount.java:71)
> at GeneratedMetadataHandler_RowCount.getRowCount_$(Unknown Source)
> at GeneratedMetadataHandler_RowCount.getRowCount(Unknown Source)
> at
> org.apache.calcite.rel.metadata.RelMetadataQuery.getRowCount(RelMetadataQuery.java:235)
> at
> org.apache.calcite.rel.metadata.RelMdUtil.estimateFilteredRows(RelMdUtil.java:718)
> at
> org.apache.calcite.rel.metadata.RelMdRowCount.getRowCount(RelMdRowCount.java:123)
> at GeneratedMetadataHandler_RowCount.getRowCount_$(Unknown Source)
> at GeneratedMetadataHandler_RowCount.getRowCount(Unknown Source)
> ...
> {code}
> It's solved by removing "AND p.id = 196" from the INNER JOIN, but it's still
> worth fixing.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-3968) Disable JoinPushThroughJoinRule.right by default
[ https://issues.apache.org/jira/browse/CALCITE-3968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17098265#comment-17098265 ] Jiatao Tao commented on CALCITE-3968: - +1, also found that TPCH query will nerver finish. > Disable JoinPushThroughJoinRule.right by default > > > Key: CALCITE-3968 > URL: https://issues.apache.org/jira/browse/CALCITE-3968 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: Haisheng Yuan >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > JoinPushThroughJoinRule.right does > (RS)T -> (RT)S > JoinPushThroughJoinRule.left does > (RS)T -> (TS)R > If JoinCommuteRule is enabled, only enabling JoinPushThroughJoinRule.right > can achieve the same alternative with JoinPushThroughJoinRule.left, vice > versa (suppose they are connected). So there is no need to enable left and > right instances at the same time, which will slow down the optimization > dramatically, e.g TPCH q05, q07 in TpchTest.java never finish. There is also > the same bug report from [1]. > Meanwhile, JoinPushThroughJoinRule matches RelNode.class, which is > unnecessary. It should be just a group, or RelSet / RelSubset, as a place > holder, because we don't care about what exactly the top join's right child > is. But since the rule is designed to work with both HepPlanner and > VolcanoPlanner, so just bear with the slowness. > [1] > https://lists.apache.org/thread.html/r195c267ef15f50aa21bbcefd7bf523f8bf2495b2345fd163e91e3c36%40%3Cdev.calcite.apache.org%3E -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (CALCITE-3968) Disable JoinPushThroughJoinRule.right by default
[ https://issues.apache.org/jira/browse/CALCITE-3968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17098265#comment-17098265 ] Jiatao Tao edited comment on CALCITE-3968 at 5/3/20, 6:46 AM: -- +1, also found that TPCH query will never finish. was (Author: aron.tao): +1, also found that TPCH query will nerver finish. > Disable JoinPushThroughJoinRule.right by default > > > Key: CALCITE-3968 > URL: https://issues.apache.org/jira/browse/CALCITE-3968 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: Haisheng Yuan >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > JoinPushThroughJoinRule.right does > (RS)T -> (RT)S > JoinPushThroughJoinRule.left does > (RS)T -> (TS)R > If JoinCommuteRule is enabled, only enabling JoinPushThroughJoinRule.right > can achieve the same alternative with JoinPushThroughJoinRule.left, vice > versa (suppose they are connected). So there is no need to enable left and > right instances at the same time, which will slow down the optimization > dramatically, e.g TPCH q05, q07 in TpchTest.java never finish. There is also > the same bug report from [1]. > Meanwhile, JoinPushThroughJoinRule matches RelNode.class, which is > unnecessary. It should be just a group, or RelSet / RelSubset, as a place > holder, because we don't care about what exactly the top join's right child > is. But since the rule is designed to work with both HepPlanner and > VolcanoPlanner, so just bear with the slowness. > [1] > https://lists.apache.org/thread.html/r195c267ef15f50aa21bbcefd7bf523f8bf2495b2345fd163e91e3c36%40%3Cdev.calcite.apache.org%3E -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-3505) Infinite matching of FilterProjectTransposeRule causes stackoverflow
[
https://issues.apache.org/jira/browse/CALCITE-3505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17106227#comment-17106227
]
Jiatao Tao commented on CALCITE-3505:
-
"I strongly think we should resolve the infinite rule matching caused by cycle
from engine level. Because when a new Calcite user create a RelOptRule, if
infinite matching happens,"
+1
> Infinite matching of FilterProjectTransposeRule causes stackoverflow
>
>
> Key: CALCITE-3505
> URL: https://issues.apache.org/jira/browse/CALCITE-3505
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Jin Xing
>Priority: Major
> Attachments: graphviz.svg
>
>
> Run ScannableTableTest#testProjectableFilterableTableJoin with minor change
> to reproduce
> {code:java}
> @Test public void testProjectableFilterableTableJoin() throws Exception {
> final StringBuilder buf = new StringBuilder();
> final String explain = "PLAN="
> + "EnumerableHashJoin(condition=[=($0, $3)], joinType=[inner])\n"
> + " EnumerableInterpreter\n"
> + "BindableTableScan(table=[[s, b1]], filters=[[=($0, 10)]])\n"
> + " EnumerableInterpreter\n"
> + "BindableTableScan(table=[[s, b2]], filters=[[=($0, 10)]])";
> CalciteAssert.that()
> .with(
> newSchema("s",
> Pair.of("b1", new BeatlesProjectableFilterableTable(buf,
> true)),
> Pair.of("b2", new BeatlesProjectableFilterableTable(buf,
> true
> .query("select * from \"s\".\"b1\", \"s\".\"b2\" "
> + "where \"s\".\"b1\".\"i\" = 10 and \"s\".\"b2\".\"i\" =
> 10 "
> + "and \"s\".\"b1\".\"i\" = \"s\".\"b2\".\"i\"")
> .withHook(Hook.PLANNER, (Consumer) planner -> {
> planner.removeRule(EnumerableRules.ENUMERABLE_MERGE_JOIN_RULE);
> })
> .explainContains(explain);
> }
> {code}
> This test has nothing to do with ENUMERABLE_MERGE_JOIN_RULE, but if we
> disable it with planner hook, stackoverflow happens;
> I debugged and found that FilterProjectTransposeRule is matched infinitely
> but not sure the root cause.
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (CALCITE-4059) equalSansNullability doesn't consider Array/Map
Jiatao Tao created CALCITE-4059: --- Summary: equalSansNullability doesn't consider Array/Map Key: CALCITE-4059 URL: https://issues.apache.org/jira/browse/CALCITE-4059 Project: Calcite Issue Type: Bug Reporter: Jiatao Tao -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CALCITE-4059) SqlTypeUtil#equalSansNullability doesn't consider Array/Map
[ https://issues.apache.org/jira/browse/CALCITE-4059?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jiatao Tao updated CALCITE-4059: Summary: SqlTypeUtil#equalSansNullability doesn't consider Array/Map (was: equalSansNullability doesn't consider Array/Map) > SqlTypeUtil#equalSansNullability doesn't consider Array/Map > --- > > Key: CALCITE-4059 > URL: https://issues.apache.org/jira/browse/CALCITE-4059 > Project: Calcite > Issue Type: Bug >Reporter: Jiatao Tao >Priority: Minor > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-4059) SqlTypeUtil#equalSansNullability doesn't consider Array/Map
[ https://issues.apache.org/jira/browse/CALCITE-4059?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17133247#comment-17133247 ] Jiatao Tao commented on CALCITE-4059: - Origin SqlTypeUtil#equalSansNullability only consider atomic type. mr: [https://github.com/apache/calcite/pull/2019] > SqlTypeUtil#equalSansNullability doesn't consider Array/Map > --- > > Key: CALCITE-4059 > URL: https://issues.apache.org/jira/browse/CALCITE-4059 > Project: Calcite > Issue Type: Bug >Reporter: Jiatao Tao >Priority: Minor > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CALCITE-4060) TypeCoercionImpl#inOperationCoercion doesn't consider NOT_IN.
Jiatao Tao created CALCITE-4060: --- Summary: TypeCoercionImpl#inOperationCoercion doesn't consider NOT_IN. Key: CALCITE-4060 URL: https://issues.apache.org/jira/browse/CALCITE-4060 Project: Calcite Issue Type: Bug Reporter: Jiatao Tao -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-4060) TypeCoercionImpl#inOperationCoercion doesn't consider NOT_IN.
[ https://issues.apache.org/jira/browse/CALCITE-4060?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17133280#comment-17133280 ] Jiatao Tao commented on CALCITE-4060: - MR: [https://github.com/apache/calcite/pull/2020] > TypeCoercionImpl#inOperationCoercion doesn't consider NOT_IN. > - > > Key: CALCITE-4060 > URL: https://issues.apache.org/jira/browse/CALCITE-4060 > Project: Calcite > Issue Type: Bug >Reporter: Jiatao Tao >Priority: Critical > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-4059) SqlTypeUtil#equalSansNullability doesn't consider Array/Map
[ https://issues.apache.org/jira/browse/CALCITE-4059?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17133842#comment-17133842 ] Jiatao Tao commented on CALCITE-4059: - [~amaliujia] 👌 > SqlTypeUtil#equalSansNullability doesn't consider Array/Map > --- > > Key: CALCITE-4059 > URL: https://issues.apache.org/jira/browse/CALCITE-4059 > Project: Calcite > Issue Type: Bug >Reporter: Jiatao Tao >Priority: Minor > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CALCITE-4060) TypeCoercionImpl#inOperationCoercion doesn't consider NOT_IN.
[ https://issues.apache.org/jira/browse/CALCITE-4060?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jiatao Tao updated CALCITE-4060: Attachment: image-2020-06-12-10-22-49-218.png > TypeCoercionImpl#inOperationCoercion doesn't consider NOT_IN. > - > > Key: CALCITE-4060 > URL: https://issues.apache.org/jira/browse/CALCITE-4060 > Project: Calcite > Issue Type: Bug >Reporter: Jiatao Tao >Priority: Critical > Attachments: image-2020-06-12-10-22-49-218.png > > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (CALCITE-4060) TypeCoercionImpl#inOperationCoercion doesn't consider NOT_IN.
[ https://issues.apache.org/jira/browse/CALCITE-4060?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17133846#comment-17133846 ] Jiatao Tao edited comment on CALCITE-4060 at 6/12/20, 2:23 AM: --- Hi [~julianhyde], I add a ut, and debug find the op is NOT IN: org.apache.calcite.test.TypeCoercionConverterTest#testNotInOperation !image-2020-06-12-10-22-49-218.png! was (Author: aron.tao): Hi [~julianhyde], I add a ut, and debug we can find the op is NOT IN: org.apache.calcite.test.TypeCoercionConverterTest#testNotInOperation !image-2020-06-12-10-22-49-218.png! > TypeCoercionImpl#inOperationCoercion doesn't consider NOT_IN. > - > > Key: CALCITE-4060 > URL: https://issues.apache.org/jira/browse/CALCITE-4060 > Project: Calcite > Issue Type: Bug >Reporter: Jiatao Tao >Priority: Critical > Attachments: image-2020-06-12-10-22-49-218.png > > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-4060) TypeCoercionImpl#inOperationCoercion doesn't consider NOT_IN.
[ https://issues.apache.org/jira/browse/CALCITE-4060?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17133846#comment-17133846 ] Jiatao Tao commented on CALCITE-4060: - Hi [~julianhyde], I add a ut, and debug we can find the op is NOT IN: org.apache.calcite.test.TypeCoercionConverterTest#testNotInOperation !image-2020-06-12-10-22-49-218.png! > TypeCoercionImpl#inOperationCoercion doesn't consider NOT_IN. > - > > Key: CALCITE-4060 > URL: https://issues.apache.org/jira/browse/CALCITE-4060 > Project: Calcite > Issue Type: Bug >Reporter: Jiatao Tao >Priority: Critical > Attachments: image-2020-06-12-10-22-49-218.png > > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-4060) TypeCoercionImpl#inOperationCoercion doesn't consider NOT_IN.
[ https://issues.apache.org/jira/browse/CALCITE-4060?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17133853#comment-17133853 ] Jiatao Tao commented on CALCITE-4060: - [~amaliujia] I add a ut: TypeCoercionConverterTest#testNotInOperation, imitate "TypeCoercionConverterTest#testInOperation" > TypeCoercionImpl#inOperationCoercion doesn't consider NOT_IN. > - > > Key: CALCITE-4060 > URL: https://issues.apache.org/jira/browse/CALCITE-4060 > Project: Calcite > Issue Type: Bug >Reporter: Jiatao Tao >Priority: Critical > Attachments: image-2020-06-12-10-22-49-218.png > > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CALCITE-4060) TypeCoercionImpl#inOperationCoercion doesn't consider NOT_IN.
[ https://issues.apache.org/jira/browse/CALCITE-4060?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jiatao Tao updated CALCITE-4060: Description: current !image-2020-06-12-10-43-52-584.png! > TypeCoercionImpl#inOperationCoercion doesn't consider NOT_IN. > - > > Key: CALCITE-4060 > URL: https://issues.apache.org/jira/browse/CALCITE-4060 > Project: Calcite > Issue Type: Bug >Reporter: Jiatao Tao >Priority: Critical > Attachments: image-2020-06-12-10-22-49-218.png, > image-2020-06-12-10-43-52-584.png > > Time Spent: 10m > Remaining Estimate: 0h > > current > !image-2020-06-12-10-43-52-584.png! -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CALCITE-4060) TypeCoercionImpl#inOperationCoercion doesn't consider NOT_IN.
[ https://issues.apache.org/jira/browse/CALCITE-4060?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jiatao Tao updated CALCITE-4060: Attachment: image-2020-06-12-10-43-52-584.png > TypeCoercionImpl#inOperationCoercion doesn't consider NOT_IN. > - > > Key: CALCITE-4060 > URL: https://issues.apache.org/jira/browse/CALCITE-4060 > Project: Calcite > Issue Type: Bug >Reporter: Jiatao Tao >Priority: Critical > Attachments: image-2020-06-12-10-22-49-218.png, > image-2020-06-12-10-43-52-584.png > > Time Spent: 10m > Remaining Estimate: 0h > > current > !image-2020-06-12-10-43-52-584.png! -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CALCITE-4060) TypeCoercionImpl#inOperationCoercion doesn't consider NOT_IN.
[ https://issues.apache.org/jira/browse/CALCITE-4060?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jiatao Tao updated CALCITE-4060: Description: Current TypeCoercionImpl#inOperationCoercion only considers IN. !image-2020-06-12-10-43-52-584.png! was: current !image-2020-06-12-10-43-52-584.png! > TypeCoercionImpl#inOperationCoercion doesn't consider NOT_IN. > - > > Key: CALCITE-4060 > URL: https://issues.apache.org/jira/browse/CALCITE-4060 > Project: Calcite > Issue Type: Bug >Reporter: Jiatao Tao >Priority: Critical > Attachments: image-2020-06-12-10-22-49-218.png, > image-2020-06-12-10-43-52-584.png > > Time Spent: 10m > Remaining Estimate: 0h > > Current TypeCoercionImpl#inOperationCoercion only considers IN. > !image-2020-06-12-10-43-52-584.png! -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-4059) SqlTypeUtil#equalSansNullability doesn't consider Array/Map
[ https://issues.apache.org/jira/browse/CALCITE-4059?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17134059#comment-17134059 ] Jiatao Tao commented on CALCITE-4059: - [~danny0405] equalAsStructSansNullability handles struct type, the case I added handle array/map. > SqlTypeUtil#equalSansNullability doesn't consider Array/Map > --- > > Key: CALCITE-4059 > URL: https://issues.apache.org/jira/browse/CALCITE-4059 > Project: Calcite > Issue Type: Bug >Reporter: Jiatao Tao >Priority: Minor > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (CALCITE-4059) SqlTypeUtil#equalSansNullability doesn't consider Array/Map
[ https://issues.apache.org/jira/browse/CALCITE-4059?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17134059#comment-17134059 ] Jiatao Tao edited comment on CALCITE-4059 at 6/12/20, 8:39 AM: --- [~danny0405] equalAsStructSansNullability only handles struct type, the case I added handle array/map. was (Author: aron.tao): [~danny0405] equalAsStructSansNullability handles struct type, the case I added handle array/map. > SqlTypeUtil#equalSansNullability doesn't consider Array/Map > --- > > Key: CALCITE-4059 > URL: https://issues.apache.org/jira/browse/CALCITE-4059 > Project: Calcite > Issue Type: Bug >Reporter: Jiatao Tao >Priority: Minor > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (CALCITE-4060) TypeCoercionImpl#inOperationCoercion doesn't consider NOT_IN.
[ https://issues.apache.org/jira/browse/CALCITE-4060?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17133846#comment-17133846 ] Jiatao Tao edited comment on CALCITE-4060 at 6/12/20, 11:00 AM: Hi [~julianhyde], I add a ut, and debug find the op is NOT IN: org.apache.calcite.test.TypeCoercionConverterTest#testNotInOperation !image-2020-06-12-10-22-49-218.png|width=483,height=316! was (Author: aron.tao): Hi [~julianhyde], I add a ut, and debug find the op is NOT IN: org.apache.calcite.test.TypeCoercionConverterTest#testNotInOperation !image-2020-06-12-10-22-49-218.png! > TypeCoercionImpl#inOperationCoercion doesn't consider NOT_IN. > - > > Key: CALCITE-4060 > URL: https://issues.apache.org/jira/browse/CALCITE-4060 > Project: Calcite > Issue Type: Bug >Reporter: Jiatao Tao >Priority: Critical > Attachments: image-2020-06-12-10-22-49-218.png, > image-2020-06-12-10-43-52-584.png > > Time Spent: 20m > Remaining Estimate: 0h > > Current TypeCoercionImpl#inOperationCoercion only considers IN. > !image-2020-06-12-10-43-52-584.png! -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CALCITE-4059) SqlTypeUtil#equalSansNullability doesn't consider Array/Map
[ https://issues.apache.org/jira/browse/CALCITE-4059?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jiatao Tao updated CALCITE-4059: Description: current equalSansNullability only considers > SqlTypeUtil#equalSansNullability doesn't consider Array/Map > --- > > Key: CALCITE-4059 > URL: https://issues.apache.org/jira/browse/CALCITE-4059 > Project: Calcite > Issue Type: Bug >Reporter: Jiatao Tao >Priority: Minor > Time Spent: 10m > Remaining Estimate: 0h > > current equalSansNullability only considers -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CALCITE-4059) SqlTypeUtil#equalSansNullability doesn't consider Array/Map
[ https://issues.apache.org/jira/browse/CALCITE-4059?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jiatao Tao updated CALCITE-4059: Description: Current equalSansNullability only considers the atomic type, not support Array/Map(struct type can supported by ). (was: current equalSansNullability only considers ) > SqlTypeUtil#equalSansNullability doesn't consider Array/Map > --- > > Key: CALCITE-4059 > URL: https://issues.apache.org/jira/browse/CALCITE-4059 > Project: Calcite > Issue Type: Bug >Reporter: Jiatao Tao >Priority: Minor > Time Spent: 10m > Remaining Estimate: 0h > > Current equalSansNullability only considers the atomic type, not support > Array/Map(struct type can supported by ). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CALCITE-4059) SqlTypeUtil#equalSansNullability doesn't consider Array/Map
[ https://issues.apache.org/jira/browse/CALCITE-4059?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jiatao Tao updated CALCITE-4059: Description: Current equalSansNullability only considers the atomic type, not support Array/Map(struct type can be supported by equalAsStructSansNullability). This Jira mainly support Array/Map type in was:Current equalSansNullability only considers the atomic type, not support Array/Map(struct type can supported by ). > SqlTypeUtil#equalSansNullability doesn't consider Array/Map > --- > > Key: CALCITE-4059 > URL: https://issues.apache.org/jira/browse/CALCITE-4059 > Project: Calcite > Issue Type: Bug >Reporter: Jiatao Tao >Priority: Minor > Time Spent: 10m > Remaining Estimate: 0h > > Current equalSansNullability only considers the atomic type, not support > Array/Map(struct type can be supported by equalAsStructSansNullability). > This Jira mainly support Array/Map type in -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CALCITE-4059) SqlTypeUtil#equalSansNullability doesn't consider Array/Map
[ https://issues.apache.org/jira/browse/CALCITE-4059?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jiatao Tao updated CALCITE-4059: Description: Current equalSansNullability only considers the atomic type, not support Array/Map(struct type can be supported by equalAsStructSansNullability). This Jira mainly supports Array/Map type in SqlTypeUtil#equalSansNullabilityI, the nullability of the type or the element of the type will be discarded, the case is in testEqualSansNullability. was: Current equalSansNullability only considers the atomic type, not support Array/Map(struct type can be supported by equalAsStructSansNullability). This Jira mainly supports Array/Map type in SqlTypeUtil#equalSansNullabilityI, the nullability of the type or the element of the type will be discarded, the case is in . > SqlTypeUtil#equalSansNullability doesn't consider Array/Map > --- > > Key: CALCITE-4059 > URL: https://issues.apache.org/jira/browse/CALCITE-4059 > Project: Calcite > Issue Type: Bug >Reporter: Jiatao Tao >Priority: Minor > Time Spent: 10m > Remaining Estimate: 0h > > Current equalSansNullability only considers the atomic type, not support > Array/Map(struct type can be supported by equalAsStructSansNullability). > This Jira mainly supports Array/Map type in > SqlTypeUtil#equalSansNullabilityI, the nullability of the type or the element > of the type will be discarded, the case is in testEqualSansNullability. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CALCITE-4059) SqlTypeUtil#equalSansNullability doesn't consider Array/Map
[ https://issues.apache.org/jira/browse/CALCITE-4059?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jiatao Tao updated CALCITE-4059: Description: Current equalSansNullability only considers the atomic type, not support Array/Map(struct type can be supported by equalAsStructSansNullability). This Jira mainly supports Array/Map type in SqlTypeUtil#equalSansNullabilityI, the nullability of the type or the element of the type will be discarded, the case is in . was: Current equalSansNullability only considers the atomic type, not support Array/Map(struct type can be supported by equalAsStructSansNullability). This Jira mainly support Array/Map type in > SqlTypeUtil#equalSansNullability doesn't consider Array/Map > --- > > Key: CALCITE-4059 > URL: https://issues.apache.org/jira/browse/CALCITE-4059 > Project: Calcite > Issue Type: Bug >Reporter: Jiatao Tao >Priority: Minor > Time Spent: 10m > Remaining Estimate: 0h > > Current equalSansNullability only considers the atomic type, not support > Array/Map(struct type can be supported by equalAsStructSansNullability). > This Jira mainly supports Array/Map type in > SqlTypeUtil#equalSansNullabilityI, the nullability of the type or the element > of the type will be discarded, the case is in . -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (CALCITE-4059) SqlTypeUtil#equalSansNullability doesn't consider Array/Map
[ https://issues.apache.org/jira/browse/CALCITE-4059?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17133842#comment-17133842 ] Jiatao Tao edited comment on CALCITE-4059 at 6/12/20, 11:07 AM: [~amaliujia] 👌, the desc is updated was (Author: aron.tao): [~amaliujia] 👌 > SqlTypeUtil#equalSansNullability doesn't consider Array/Map > --- > > Key: CALCITE-4059 > URL: https://issues.apache.org/jira/browse/CALCITE-4059 > Project: Calcite > Issue Type: Bug >Reporter: Jiatao Tao >Priority: Minor > Time Spent: 10m > Remaining Estimate: 0h > > Current equalSansNullability only considers the atomic type, not support > Array/Map(struct type can be supported by equalAsStructSansNullability). > This Jira mainly supports Array/Map type in > SqlTypeUtil#equalSansNullabilityI, the nullability of the type or the element > of the type will be discarded, the case is in testEqualSansNullability. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-4060) TypeCoercionImpl#inOperationCoercion doesn't consider NOT_IN.
[ https://issues.apache.org/jira/browse/CALCITE-4060?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17136247#comment-17136247 ] Jiatao Tao commented on CALCITE-4060: - Hi [~julianhyde] , you can take a look at "org.apache.calcite.test.TypeCoercionConverterTest#testInOperation", and debug in "org.apache.calcite.sql.validate.implicit.TypeCoercionImpl#inOperationCoercion". > TypeCoercionImpl#inOperationCoercion doesn't consider NOT_IN. > - > > Key: CALCITE-4060 > URL: https://issues.apache.org/jira/browse/CALCITE-4060 > Project: Calcite > Issue Type: Bug >Reporter: Jiatao Tao >Priority: Critical > Attachments: image-2020-06-12-10-22-49-218.png, > image-2020-06-12-10-43-52-584.png > > Time Spent: 0.5h > Remaining Estimate: 0h > > Current TypeCoercionImpl#inOperationCoercion only considers IN. > !image-2020-06-12-10-43-52-584.png! -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-4059) SqlTypeUtil#equalSansNullability doesn't consider Array/Map
[ https://issues.apache.org/jira/browse/CALCITE-4059?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17136262#comment-17136262 ] Jiatao Tao commented on CALCITE-4059: - Hi [~danny0405], Could you possibly review this pr? [https://github.com/apache/calcite/pull/2019] > SqlTypeUtil#equalSansNullability doesn't consider Array/Map > --- > > Key: CALCITE-4059 > URL: https://issues.apache.org/jira/browse/CALCITE-4059 > Project: Calcite > Issue Type: Bug >Reporter: Jiatao Tao >Priority: Minor > Time Spent: 20m > Remaining Estimate: 0h > > Current equalSansNullability only considers the atomic type, not support > Array/Map(struct type can be supported by equalAsStructSansNullability). > This Jira mainly supports Array/Map type in > SqlTypeUtil#equalSansNullabilityI, the nullability of the type or the element > of the type will be discarded, the case is in testEqualSansNullability. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CALCITE-4059) SqlTypeUtil#equalSansNullability doesn't consider Array/Map
[ https://issues.apache.org/jira/browse/CALCITE-4059?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jiatao Tao updated CALCITE-4059: Description: Current equalSansNullability only considers the atomic type, not support Array/Map(struct type can be supported by equalAsStructSansNullability). This Jira mainly supports Array/MULTISET/Map type equal sans nullability # equalSansNullability, handles atomic type # equalAsCollectionSansNullability, handles type ARRAY/MULTISET # equalAsMapSansNullability, handles type MAP # equalAsStructSansNullability, handles type struct was: Current equalSansNullability only considers the atomic type, not support Array/Map(struct type can be supported by equalAsStructSansNullability). This Jira mainly supports Array/Map type in SqlTypeUtil#equalSansNullabilityI, the nullability of the type or the element of the type will be discarded, the case is in testEqualSansNullability. > SqlTypeUtil#equalSansNullability doesn't consider Array/Map > --- > > Key: CALCITE-4059 > URL: https://issues.apache.org/jira/browse/CALCITE-4059 > Project: Calcite > Issue Type: Bug >Reporter: Jiatao Tao >Priority: Minor > Time Spent: 1h 50m > Remaining Estimate: 0h > > Current equalSansNullability only considers the atomic type, not support > Array/Map(struct type can be supported by equalAsStructSansNullability). > This Jira mainly supports Array/MULTISET/Map type equal sans nullability > # equalSansNullability, handles atomic type > # equalAsCollectionSansNullability, handles type ARRAY/MULTISET > # equalAsMapSansNullability, handles type MAP > # equalAsStructSansNullability, handles type struct -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CALCITE-4059) SqlTypeUtil#equalSansNullability doesn't consider Array/Map
[ https://issues.apache.org/jira/browse/CALCITE-4059?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jiatao Tao updated CALCITE-4059: Description: Current equalSansNullability only considers the atomic type, not support Array/MULTISET/Map(struct type can be supported by equalAsStructSansNullability). This Jira mainly supports Array/MULTISET/Map type equal sans nullability # equalSansNullability, handles atomic type # equalAsCollectionSansNullability, handles type ARRAY/MULTISET # equalAsMapSansNullability, handles type MAP # equalAsStructSansNullability, handles type struct was: Current equalSansNullability only considers the atomic type, not support Array/Map(struct type can be supported by equalAsStructSansNullability). This Jira mainly supports Array/MULTISET/Map type equal sans nullability # equalSansNullability, handles atomic type # equalAsCollectionSansNullability, handles type ARRAY/MULTISET # equalAsMapSansNullability, handles type MAP # equalAsStructSansNullability, handles type struct > SqlTypeUtil#equalSansNullability doesn't consider Array/Map > --- > > Key: CALCITE-4059 > URL: https://issues.apache.org/jira/browse/CALCITE-4059 > Project: Calcite > Issue Type: Bug >Reporter: Jiatao Tao >Priority: Minor > Time Spent: 1h 50m > Remaining Estimate: 0h > > Current equalSansNullability only considers the atomic type, not support > Array/MULTISET/Map(struct type can be supported by > equalAsStructSansNullability). > This Jira mainly supports Array/MULTISET/Map type equal sans nullability > # equalSansNullability, handles atomic type > # equalAsCollectionSansNullability, handles type ARRAY/MULTISET > # equalAsMapSansNullability, handles type MAP > # equalAsStructSansNullability, handles type struct -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CALCITE-4066) SqlTypeUtil#convertTypeToSpec cover Array/Row types
Jiatao Tao created CALCITE-4066: --- Summary: SqlTypeUtil#convertTypeToSpec cover Array/Row types Key: CALCITE-4066 URL: https://issues.apache.org/jira/browse/CALCITE-4066 Project: Calcite Issue Type: Bug Components: core Reporter: Jiatao Tao -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (CALCITE-1973) Get sql node's pos error when SQL has join
[
https://issues.apache.org/jira/browse/CALCITE-1973?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jiatao Tao reassigned CALCITE-1973:
---
Assignee: Jiatao Tao
> Get sql node's pos error when SQL has join
> --
>
> Key: CALCITE-1973
> URL: https://issues.apache.org/jira/browse/CALCITE-1973
> Project: Calcite
> Issue Type: Bug
>Reporter: Jiatao Tao
>Assignee: Jiatao Tao
>Priority: Major
> Attachments: WX20170904-112559.png, screenshot-2.png
>
>
> Hi, I met some problems with parser.
> Parse SQL like "select a from t t1 join tt t2 on t1.c = tt.c", and the from's
> pos is 20,23("oin")(obviously not).
> And I test another query "select a from (select a from KYLIN_SALES) t inner
> join KYLIN_SALES tt on t.price = tt.price", and get from's pos is 51,
> 54("oin"), seems that pos is take "join"
> Hope your advice
> Best Wishes
> Aron
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (CALCITE-3065) RexLiteral#getValueAs should consider primitive type
[ https://issues.apache.org/jira/browse/CALCITE-3065?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jiatao Tao reassigned CALCITE-3065: --- Assignee: Jiatao Tao > RexLiteral#getValueAs should consider primitive type > > > Key: CALCITE-3065 > URL: https://issues.apache.org/jira/browse/CALCITE-3065 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: Jiatao Tao >Assignee: Jiatao Tao >Priority: Major > Labels: pull-request-available > Attachments: image-2019-05-13-12-04-36-365.png, > image-2019-05-17-08-23-52-735.png, image-2019-06-02-08-15-35-460.png, > image-2019-06-02-08-43-51-646.png > > Time Spent: 50m > Remaining Estimate: 0h > > !image-2019-05-13-12-04-36-365.png! -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (CALCITE-1875) Get sql node's pos error when parse SQL like a+(b+c)
[ https://issues.apache.org/jira/browse/CALCITE-1875?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jiatao Tao reassigned CALCITE-1875: --- Assignee: Jiatao Tao > Get sql node's pos error when parse SQL like a+(b+c) > > > Key: CALCITE-1875 > URL: https://issues.apache.org/jira/browse/CALCITE-1875 > Project: Calcite > Issue Type: Bug >Reporter: Jiatao Tao >Assignee: Jiatao Tao >Priority: Major > > Parse SQL like "select c+(a+b) from t", and the selectList's position is 8 > 13, and it should be 8 14. > And I wonder is there any way I can modify the code and solve this problem? > Hope for your advice. > !https://git.oschina.net/Meldoy/image/raw/master/others/wx20170707-103...@2x.png! -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (CALCITE-3870) set "SqlToRelConverter.ConfigBuilder#expand" default to false
[ https://issues.apache.org/jira/browse/CALCITE-3870?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jiatao Tao reassigned CALCITE-3870: --- Assignee: Jiatao Tao > set "SqlToRelConverter.ConfigBuilder#expand" default to false > - > > Key: CALCITE-3870 > URL: https://issues.apache.org/jira/browse/CALCITE-3870 > Project: Calcite > Issue Type: Bug > Components: core >Reporter: Jiatao Tao >Assignee: Jiatao Tao >Priority: Minor > Labels: pull-request-available > Attachments: image-2020-03-25-14-05-04-011.png > > Time Spent: 0.5h > Remaining Estimate: 0h > > Now the default "expand" in SqlToRelConverter.ConfigBuilder is true but in > calcite's main process, actually, it is false( > `withExpand(THREAD_EXPAND.get())`) > > That leads we need to explicitly set `withExpand` to false when we use > SqlToRelConverter. > > So I think we should change the default to "false" in > SqlToRelConverter.ConfigBuilder. > > > !https://mail.google.com/mail/u/0?ui=2&ik=09d5de6bf3&attid=0.1&permmsgid=msg-a:r-1571046416348666034&th=17106774a5349d1d&view=fimg&sz=s0-l75-ft&attbid=ANGjdJ_IjYbiwT8IKlaiAIDzbkq_ehCBktd4DzCYr14Ppst6lBftqMbrrWu8hzGpN2wpCz46a3F1FKvfD_miGHkC-EMx509KPC4FEovxtN2M0WcU1up209hyLtKoZqE&disp=emb&realattid=ii_k8460q950! > > !https://mail.google.com/mail/u/0?ui=2&ik=09d5de6bf3&attid=0.2&permmsgid=msg-a:r-1571046416348666034&th=17106774a5349d1d&view=fimg&sz=s0-l75-ft&attbid=ANGjdJ_K-EyE_x0Vo66h6sHRzpEOxIE5qTzuujqG8WqZVPdprgC3khwcO_8OLLai-8ikrMRC9ksO-xAzqe2HFr-QYM1lzQDLYfSlD5x-eOXbww9CNsb5cgu-979N1lU&disp=emb&realattid=ii_k846zj601! -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (CALCITE-4066) SqlTypeUtil#convertTypeToSpec cover Array/Row types
[ https://issues.apache.org/jira/browse/CALCITE-4066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jiatao Tao reassigned CALCITE-4066: --- Assignee: Jiatao Tao > SqlTypeUtil#convertTypeToSpec cover Array/Row types > --- > > Key: CALCITE-4066 > URL: https://issues.apache.org/jira/browse/CALCITE-4066 > Project: Calcite > Issue Type: Bug > Components: core >Reporter: Jiatao Tao >Assignee: Jiatao Tao >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (CALCITE-3770) Minor change "EnumerableCalcRel" to "EnumerableCalcRel"
[ https://issues.apache.org/jira/browse/CALCITE-3770?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jiatao Tao reassigned CALCITE-3770: --- Assignee: Jiatao Tao > Minor change "EnumerableCalcRel" to "EnumerableCalcRel" > --- > > Key: CALCITE-3770 > URL: https://issues.apache.org/jira/browse/CALCITE-3770 > Project: Calcite > Issue Type: Improvement >Reporter: Jiatao Tao >Assignee: Jiatao Tao >Priority: Trivial > Labels: pull-request-available > Time Spent: 50m > Remaining Estimate: 0h > > EnumerableCalcRel appears in many places in code, but the class's name is > EnumerableCalc. > I don't know if it is on purpose, but it seems confusing when I want to find > the class EnumerableCalcRel but I can not find it. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (CALCITE-4059) SqlTypeUtil#equalSansNullability doesn't consider Array/Map
[ https://issues.apache.org/jira/browse/CALCITE-4059?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jiatao Tao reassigned CALCITE-4059: --- Assignee: Jiatao Tao > SqlTypeUtil#equalSansNullability doesn't consider Array/Map > --- > > Key: CALCITE-4059 > URL: https://issues.apache.org/jira/browse/CALCITE-4059 > Project: Calcite > Issue Type: Bug >Reporter: Jiatao Tao >Assignee: Jiatao Tao >Priority: Minor > Time Spent: 1h 50m > Remaining Estimate: 0h > > Current equalSansNullability only considers the atomic type, not support > Array/MULTISET/Map(struct type can be supported by > equalAsStructSansNullability). > This Jira mainly supports Array/MULTISET/Map type equal sans nullability > # equalSansNullability, handles atomic type > # equalAsCollectionSansNullability, handles type ARRAY/MULTISET > # equalAsMapSansNullability, handles type MAP > # equalAsStructSansNullability, handles type struct -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (CALCITE-4060) TypeCoercionImpl#inOperationCoercion doesn't consider NOT_IN.
[ https://issues.apache.org/jira/browse/CALCITE-4060?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jiatao Tao reassigned CALCITE-4060: --- Assignee: Jiatao Tao > TypeCoercionImpl#inOperationCoercion doesn't consider NOT_IN. > - > > Key: CALCITE-4060 > URL: https://issues.apache.org/jira/browse/CALCITE-4060 > Project: Calcite > Issue Type: Bug >Reporter: Jiatao Tao >Assignee: Jiatao Tao >Priority: Critical > Attachments: image-2020-06-12-10-22-49-218.png, > image-2020-06-12-10-43-52-584.png > > Time Spent: 2h > Remaining Estimate: 0h > > Current TypeCoercionImpl#inOperationCoercion only considers IN. > !image-2020-06-12-10-43-52-584.png! -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CALCITE-4066) SqlTypeUtil#convertTypeToSpec cover Array/Multiset/Row types
[ https://issues.apache.org/jira/browse/CALCITE-4066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jiatao Tao updated CALCITE-4066: Summary: SqlTypeUtil#convertTypeToSpec cover Array/Multiset/Row types (was: SqlTypeUtil#convertTypeToSpec cover Array/Row types) > SqlTypeUtil#convertTypeToSpec cover Array/Multiset/Row types > > > Key: CALCITE-4066 > URL: https://issues.apache.org/jira/browse/CALCITE-4066 > Project: Calcite > Issue Type: Bug > Components: core >Reporter: Jiatao Tao >Assignee: Jiatao Tao >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CALCITE-4060) TypeCoercionImpl#inOperationCoercion doesn't consider NOT_IN.
[ https://issues.apache.org/jira/browse/CALCITE-4060?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jiatao Tao updated CALCITE-4060: Component/s: core > TypeCoercionImpl#inOperationCoercion doesn't consider NOT_IN. > - > > Key: CALCITE-4060 > URL: https://issues.apache.org/jira/browse/CALCITE-4060 > Project: Calcite > Issue Type: Bug > Components: core >Reporter: Jiatao Tao >Assignee: Jiatao Tao >Priority: Critical > Attachments: image-2020-06-12-10-22-49-218.png, > image-2020-06-12-10-43-52-584.png > > Time Spent: 2h > Remaining Estimate: 0h > > Current TypeCoercionImpl#inOperationCoercion only considers IN. > !image-2020-06-12-10-43-52-584.png! -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CALCITE-4059) SqlTypeUtil#equalSansNullability doesn't consider Array/Map
[ https://issues.apache.org/jira/browse/CALCITE-4059?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jiatao Tao updated CALCITE-4059: Component/s: core > SqlTypeUtil#equalSansNullability doesn't consider Array/Map > --- > > Key: CALCITE-4059 > URL: https://issues.apache.org/jira/browse/CALCITE-4059 > Project: Calcite > Issue Type: Bug > Components: core >Reporter: Jiatao Tao >Assignee: Jiatao Tao >Priority: Minor > Time Spent: 2h 50m > Remaining Estimate: 0h > > Current equalSansNullability only considers the atomic type, not support > Array/MULTISET/Map(struct type can be supported by > equalAsStructSansNullability). > This Jira mainly supports Array/MULTISET/Map type equal sans nullability > # equalSansNullability, handles atomic type > # equalAsCollectionSansNullability, handles type ARRAY/MULTISET > # equalAsMapSansNullability, handles type MAP > # equalAsStructSansNullability, handles type struct -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CALCITE-4059) SqlTypeUtil#equalSansNullability doesn't consider Array/Map
[ https://issues.apache.org/jira/browse/CALCITE-4059?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jiatao Tao updated CALCITE-4059: Labels: pull-request-available (was: ) > SqlTypeUtil#equalSansNullability doesn't consider Array/Map > --- > > Key: CALCITE-4059 > URL: https://issues.apache.org/jira/browse/CALCITE-4059 > Project: Calcite > Issue Type: Bug > Components: core >Reporter: Jiatao Tao >Assignee: Jiatao Tao >Priority: Minor > Labels: pull-request-available > Time Spent: 2h 50m > Remaining Estimate: 0h > > Current equalSansNullability only considers the atomic type, not support > Array/MULTISET/Map(struct type can be supported by > equalAsStructSansNullability). > This Jira mainly supports Array/MULTISET/Map type equal sans nullability > # equalSansNullability, handles atomic type > # equalAsCollectionSansNullability, handles type ARRAY/MULTISET > # equalAsMapSansNullability, handles type MAP > # equalAsStructSansNullability, handles type struct -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CALCITE-4060) TypeCoercionImpl#inOperationCoercion doesn't consider NOT_IN.
[ https://issues.apache.org/jira/browse/CALCITE-4060?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jiatao Tao updated CALCITE-4060: Labels: pull-request-available (was: ) > TypeCoercionImpl#inOperationCoercion doesn't consider NOT_IN. > - > > Key: CALCITE-4060 > URL: https://issues.apache.org/jira/browse/CALCITE-4060 > Project: Calcite > Issue Type: Bug > Components: core >Reporter: Jiatao Tao >Assignee: Jiatao Tao >Priority: Critical > Labels: pull-request-available > Attachments: image-2020-06-12-10-22-49-218.png, > image-2020-06-12-10-43-52-584.png > > Time Spent: 2h > Remaining Estimate: 0h > > Current TypeCoercionImpl#inOperationCoercion only considers IN. > !image-2020-06-12-10-43-52-584.png! -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CALCITE-4066) SqlTypeUtil#convertTypeToSpec cover Array/Multiset/Row types
[ https://issues.apache.org/jira/browse/CALCITE-4066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jiatao Tao updated CALCITE-4066: Labels: pull-request-available (was: ) > SqlTypeUtil#convertTypeToSpec cover Array/Multiset/Row types > > > Key: CALCITE-4066 > URL: https://issues.apache.org/jira/browse/CALCITE-4066 > Project: Calcite > Issue Type: Bug > Components: core >Reporter: Jiatao Tao >Assignee: Jiatao Tao >Priority: Major > Labels: pull-request-available > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CALCITE-4059) SqlTypeUtil#equalSansNullability doesn't consider Array/Map
[ https://issues.apache.org/jira/browse/CALCITE-4059?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jiatao Tao updated CALCITE-4059: Fix Version/s: 1.24.0 > SqlTypeUtil#equalSansNullability doesn't consider Array/Map > --- > > Key: CALCITE-4059 > URL: https://issues.apache.org/jira/browse/CALCITE-4059 > Project: Calcite > Issue Type: Bug > Components: core >Reporter: Jiatao Tao >Assignee: Jiatao Tao >Priority: Minor > Labels: pull-request-available > Fix For: 1.24.0 > > Time Spent: 2h 50m > Remaining Estimate: 0h > > Current equalSansNullability only considers the atomic type, not support > Array/MULTISET/Map(struct type can be supported by > equalAsStructSansNullability). > This Jira mainly supports Array/MULTISET/Map type equal sans nullability > # equalSansNullability, handles atomic type > # equalAsCollectionSansNullability, handles type ARRAY/MULTISET > # equalAsMapSansNullability, handles type MAP > # equalAsStructSansNullability, handles type struct -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CALCITE-4060) TypeCoercionImpl#inOperationCoercion doesn't consider NOT_IN.
[ https://issues.apache.org/jira/browse/CALCITE-4060?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jiatao Tao updated CALCITE-4060: Fix Version/s: 1.24.0 > TypeCoercionImpl#inOperationCoercion doesn't consider NOT_IN. > - > > Key: CALCITE-4060 > URL: https://issues.apache.org/jira/browse/CALCITE-4060 > Project: Calcite > Issue Type: Bug > Components: core >Reporter: Jiatao Tao >Assignee: Jiatao Tao >Priority: Critical > Labels: pull-request-available > Fix For: 1.24.0 > > Attachments: image-2020-06-12-10-22-49-218.png, > image-2020-06-12-10-43-52-584.png > > Time Spent: 2h > Remaining Estimate: 0h > > Current TypeCoercionImpl#inOperationCoercion only considers IN. > !image-2020-06-12-10-43-52-584.png! -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-4066) SqlTypeUtil#convertTypeToSpec cover Array/Multiset/Row types
[ https://issues.apache.org/jira/browse/CALCITE-4066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17141263#comment-17141263 ] Jiatao Tao commented on CALCITE-4066: - PR: [https://github.com/apache/calcite/pull/2029/files] > SqlTypeUtil#convertTypeToSpec cover Array/Multiset/Row types > > > Key: CALCITE-4066 > URL: https://issues.apache.org/jira/browse/CALCITE-4066 > Project: Calcite > Issue Type: Bug > Components: core >Reporter: Jiatao Tao >Assignee: Jiatao Tao >Priority: Major > Labels: pull-request-available > Time Spent: 50m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CALCITE-4098) remove redundant code in "RelJson.toJson(RelDistribution)"
Jiatao Tao created CALCITE-4098:
---
Summary: remove redundant code in "RelJson.toJson(RelDistribution)"
Key: CALCITE-4098
URL: https://issues.apache.org/jira/browse/CALCITE-4098
Project: Calcite
Issue Type: Improvement
Components: core
Reporter: Jiatao Tao
Assignee: Jiatao Tao
RelDistribution#getKeys is annotated as nonnull, and must return
"List", so this code is unnecessary.
```
List keys = new ArrayList<>(relDistribution.getKeys().size());
for (Integer key : relDistribution.getKeys()) {
keys.add(toJson(key));
}
```
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-4098) remove redundant code in "RelJson.toJson(RelDistribution)"
[
https://issues.apache.org/jira/browse/CALCITE-4098?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jiatao Tao updated CALCITE-4098:
Description:
RelDistribution#getKeys is annotated as nonnull, and must return
"List", so this code is unnecessary.
{code:java}
List keys = new ArrayList<>(relDistribution.getKeys().size());
for (Integer key : relDistribution.getKeys()) {
keys.add(toJson(key));
}
{code}
was:
RelDistribution#getKeys is annotated as nonnull, and must return
"List", so this code is unnecessary.
```
List keys = new ArrayList<>(relDistribution.getKeys().size());
for (Integer key : relDistribution.getKeys()) {
keys.add(toJson(key));
}
```
> remove redundant code in "RelJson.toJson(RelDistribution)"
> --
>
> Key: CALCITE-4098
> URL: https://issues.apache.org/jira/browse/CALCITE-4098
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: Jiatao Tao
>Assignee: Jiatao Tao
>Priority: Minor
>
> RelDistribution#getKeys is annotated as nonnull, and must return
> "List", so this code is unnecessary.
>
> {code:java}
> List keys = new ArrayList<>(relDistribution.getKeys().size());
> for (Integer key : relDistribution.getKeys()) {
> keys.add(toJson(key));
> }
>
> {code}
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
