You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@calcite.apache.org by "Yuzhao Chen (JIRA)" <ji...@apache.org> on 2018/06/01 03:50:00 UTC

[jira] [Commented] (CALCITE-2302) Implicit type cast support

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

Yuzhao Chen commented on CALCITE-2302:
--------------------------------------

Hi, committers, can you give me some suggestions? Our users really need this implicit type coercion, i considered to implement this function outside Calcite but it always validates fails, finally i added it in the Calcite validation process, and this seems the only way to, so i really appreciate for your suggestions.

In total, i wanna know if this implementation is ok for now the Calcite architecture, and if there are some hidden trouble or negative effects.

The test cases in Calcite are all ok and desirable, also the Cases i added in TypeCoercionTest.java. But i think this need more cases which computing real dataset and output the right answers.

I plan to add more test cases from Hive/Mysql/Spark in and then let this function default open in our product cluster.

So really look forward to your suggestions if you have time.

> Implicit type cast support
> --------------------------
>
>                 Key: CALCITE-2302
>                 URL: https://issues.apache.org/jira/browse/CALCITE-2302
>             Project: Calcite
>          Issue Type: Improvement
>          Components: core
>    Affects Versions: 1.17.0
>            Reporter: Yuzhao Chen
>            Assignee: Julian Hyde
>            Priority: Major
>             Fix For: 1.17.0
>
>
> Now many DBs have support implicit type cast, eg: SqlServer, Oracle, Hive.
> Implicit type cast is an useful function for many cases, So we should support this.
> I checkout Calcite code and found that:
>  # Now we use a validator to validate our operands types[ through kinds of namespaces and scopes ]
>  # Most of the validations will finally goes to
> {code:java}
> SqlOperator.validateOperands
> {code}
>  # which will use validation logic defined in corresponding SqlOperandTypeChecker
> What i'm confused about is where should i put the implicit type cast logic in? I figured out 2 ways:
>  # Supply a tool class/rules to add casts into a parsed SqlNode tree which will then go through the validation logic later on.
>  # Unleash the validation logic in kinds of SqlOperandTypeChecker, then modify the RelNode/RexNodes tree converted from a validated SqlNode tree to add in casts through custom RelOptRules.
> So guys, which of the 2 ways should i go, or if there are better way to do this?
> I need your help.
>  
> Updated 18-05-30:
> Hi guys, i have made a PR in [CALCITE-2302|https://github.com/apache/calcite/pull/706]
> This is design doc: [Calcite Implicit Type Cast Design|https://docs.google.com/document/d/1g2RUnLXyp_LjUlO-wbblKuP5hqEu3a_2Mt2k4dh6RwU/edit?usp=sharing].
> This is the conversion types mapping: [Conversion Types Mapping|https://docs.google.com/spreadsheets/d/1GhleX5h5W8-kJKh7NMJ4vtoE78pwfaZRJl88ULX_MgU/edit?usp=sharing].
> I really appreciate your suggestions, thx.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)