[jira] [Commented] (DRILL-259) Proposal for CAST mechanism

["Jinfeng Ni (JIRA)" <ji...@apache.org>]

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

Jinfeng Ni commented on DRILL-259:
----------------------------------

1 .  implicit cast vs explicit cast. 

Basically, implicit cast would need leverage explicit cast's implementation. For instance, given an logical expression :  1 + 3.0, if the function resolver finds that argument 1 should be implicitly casted into float4, then, drill code should transform the logical expression into  cast(1 as float4) + 3.0, so that "+" operator will call the add(float4, float4) implementation.  

2. Add implicit cast function call in the logical expression tree.

Currently, drill code uses FunctionImplementationRegistry.getFunction(FunctionCall) to get DrillFuncHolder in EvalVisitor.

Your FunctionResolver is used to find the best match in the call of getFunction(). However, if the best match says implicit cast is required, it's kind of difficult to let getFunction() do 1) insert the cast function to the logical expression tree, and 2) get cast's DrillFuncHolder, and 3) generate the code for the cast function. 

We probably should separate the process of adding implicit cast from the logic of FunctionImplementationRegistry.getFunction() and code generation.  

To do that :
     Introduce a new Visitor class ImplicitCastBuilder.
     ImplicitCastBuilder will look similar to EvalVisitor .  ImplicitCastBuilder extends AbstractExprVisitor<LogicalExpression, FunctionImplenetationRegistry, RuntimeException>
    ImplicitCastBuilder should build cast function call in bottom-up way.
    ImplicitCastBuilder will modify logical expression tree, and inject a cast function on top of an argument, if yourFunctionResolver.getBestMatch() shows implicit cast is required.
   CodeGenerator.addExpr will call ImplicitCastBuilder to insert the implicit cast() to logical expression tree .

  public HoldingContainer addExpr(LogicalExpression ex, boolean rotate){
//    logger.debug("Adding next write {}", ex);
    if(rotate) rotateBlock();     
    ex = implicitCastBuilder.accept(ex, this);
    return evaluationVisitor.addExpr(ex, this);
  }

   EvalVisitor will then do the match() and code generation as before. ( No need to call your FunctionResolver.getBestMatch() at this stage, since all the required implicit cast has been inserted into the logical expression tree). 

For example, let's say we have logical expression tree f1 ( a1, f2( a2, a3))
  
                               f1()
                            /      \
                          /         \
                          a1       f2()
                                   /     \
                                 /        \
                               a2       a3

We may end up with the following logical expression tree, after ImplicitCastBuilder visit.
                 
                              f1()
                            /      \
                          /         \
                          a1     cast1()
                                       \
                                        \
                                          f2()
                                         /   \
                                       /      \
                                     a2     cast2()
                                                |
                                                |
                                               a3

Note that cast2 would be inserted first, followed by cast1 during the visite, since we need do it in bottom-up ( when we do getBestMatch() for f1 and insert cast1, we need know the output type of cast2, in order to determine output type of f2(), which is argument to f1() ).


> Proposal for CAST mechanism
> ---------------------------
>
>                 Key: DRILL-259
>                 URL: https://issues.apache.org/jira/browse/DRILL-259
>             Project: Apache Drill
>          Issue Type: New Feature
>    Affects Versions: 1.0.0-milestone-2
>            Reporter: Yash Sharma
>
> *Proposal for implementing a CAST mechanism in Drill.* 
> ===============================================
> The casting mechanism would be of two types
> - Implicit type casting
> - Explicit type casting
> *Details:*
> * The Implicit type cast would take care of the casting of the lower datatype holders to the higher datatype holders automatically. 
> bq. Eg. IntHolder would be casted to Float4Holder/Float8Holder directly.
> * The explicit type casting would enable the user to use a CAST() function to cast some value to another datatype by specifying the type. The cast function would be a function exposed with syntax similar to standard SQL format. 
> bq. Eg. SELECT CAST (somevalue AS INT) FROM sometable;
> *Type conversion rules:*
> Conversion rules have to be similar to SQL standards.
> _Implicit type conversion:_
> * For arithmetic & comparison operators (+, -, *, /, <, >, =, etc) - 
> ** If both operands types are different, Strings would be converted to Double, and then both the operands would be converted to the same type by choosing the type with higher precision.
> * For values passed to a Function/UDF - 
> ** The values would be converted to the parameter accepted by the Function. 
> ** In case of multiple overloaded functions are present, the function with least number of conversions would be selected.
> ** In case there are multiple functions with least number of conversions, there would be an error returned to user for ambiguous function.
> _Explicit Type Conversion_
> * User would use the CAST Function for converting types to another specified type.
> * For nonconvertible types user gets an error back. 



--
This message was sent by Atlassian JIRA
(v6.1.4#6159)