Holistics doesn’t currently have the capability to deal with fanouts on measures when used with 1-N model relationships. However, at least if we define metrics with type count distinct, max, min etc the fanout problem is ignored and the query returns OK.
Sometimes, these measures are then used in other measures (e.g. [count distinct x] / [count distinct y]). However the results are not returned, due to a fanout warning, when actually there is no risk of fanout.
It would be helpful to return the value rather than an error.
This issue happens because your aggregate function is defined inside the sql definition property of a field which, currently, makes the SQL semantic technically infeasible to analyze.
You can change to using our aggregation_type instead so that we can easily detect the aggregation type of a field and prevent fanout issue.
I’ve used the aggregation type on the two components of the final measure. However as the components are already aggregates, no aggregation type should be set (I’ve not set the aggregate type but in this case it should be none)
E.g.
Measure 1 aggregation type = count distinct
Measure 2 aggregation type = count distinct
Measure 3 = Measure 1 / Measure 2 (no aggregation type)