Database specific metric generation

[Tobias Adamson <to...@gmail.com>]

Hi
We use Clickhouse as our backend for Superset.
Clickhouse supports something called aggregation state 
This means a column can be of type AggregateFunction(sum, Int64) which in turn will be a INTEGER in SQLAlchemy/Superset
The problem is when using sum on a column that has aggregate state you need to use sumMerge(column_name) instead of sum(column_name) as sum will give the wrong result.
Currently superset will generate sum(column_name) and then the user needs to edit each metric to be sumMerge

Would the superset dev team be open to make the generation of metrics and columns DB specific and then use the current model as the generic one if no specific implementation exists?
If you are then I would be happy to work on an implementation

Regards
Toby

Re: Database specific metric generation

[Maxime Beauchemin <ma...@gmail.com>]

Sure, we put all the db-engine-specific code in this module:
https://github.com/apache/incubator-superset/blob/master/superset/db_engine_specs.py

So all you need to do is to implement a new method in BaseEngineSpec, maybe
something named 'default_metric(type)' with the current global logic, and
override it for the Clickhouse engine.

Max

On Wed, Sep 13, 2017 at 7:53 PM, Tobias Adamson <to...@gmail.com>
wrote:

> Hi
> We use Clickhouse as our backend for Superset.
> Clickhouse supports something called aggregation state
> This means a column can be of type AggregateFunction(sum, Int64) which in
> turn will be a INTEGER in SQLAlchemy/Superset
> The problem is when using sum on a column that has aggregate state you
> need to use sumMerge(column_name) instead of sum(column_name) as sum will
> give the wrong result.
> Currently superset will generate sum(column_name) and then the user needs
> to edit each metric to be sumMerge
>
> Would the superset dev team be open to make the generation of metrics and
> columns DB specific and then use the current model as the generic one if no
> specific implementation exists?
> If you are then I would be happy to work on an implementation
>
> Regards
> Toby
>
>