You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@kylin.apache.org by "hongbin ma (JIRA)" <ji...@apache.org> on 2016/03/01 04:01:18 UTC

[jira] [Commented] (KYLIN-1345) measure type expansion when dealing sum of decimal metric

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

hongbin ma commented on KYLIN-1345:
-----------------------------------

i think it's a reasonable semantic for the FunctionDesc to return "revised"
return data types. After all a fundamental question is "how was the return
type" determined? Currently when user defines a measure when creating cube,
the kylin frontend automatically creates the function with the return type
deriving from the column's original type (
https://github.com/binmahone/kylin/blob/4cdd1a435c09556b84c8daf7957388d94faa0863/webapp/app/js/controllers/cubeMeasures.js#L142-L142)
In this sense the function return type is somewhat "transparent" to the
user. So a simple solution here is to replace

 if(colType.indexOf('decimal')!=-1){
              $scope.newMeasure.function.returntype= colType;
            }else{
              $scope.newMeasure.function.returntype= 'decimal';
            }

to:

$scope.newMeasure.function.returntype= 'decimal'

The current approach in the patch will increase too much complexity, I
guess. Not to mention the effort for you to go through invocation of
getReturnType









-- 
Regards,

*Bin Mahone | 马洪宾*
Apache Kylin: http://kylin.io
Github: https://github.com/binmahone


> measure type expansion when dealing sum of decimal metric
> ---------------------------------------------------------
>
>                 Key: KYLIN-1345
>                 URL: https://issues.apache.org/jira/browse/KYLIN-1345
>             Project: Kylin
>          Issue Type: Improvement
>            Reporter: hongbin ma
>            Assignee: Edward Zhang
>              Labels: newbie
>
> suppose a metric column price is of type decimal (6,2), the sum aggregator of it might exceed the maximal of decimal (6,2). Currently for metric aggregators we inherite the column's type in hive. We should think auto expanding decimal type to decimal(18,4) (just an example) for such cases



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)