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