drill-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jinfeng Ni (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (DRILL-259) Proposal for CAST mechanism
Date Mon, 16 Dec 2013 16:19:08 GMT

    [ 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)

Mime
View raw message