Create protocol abstraction for `Metrics` about dbt-semantic-interfaces HOT 4 CLOSED

@QMalcolm based on MetricFlow Issue 469, could we add a method here that creates something called metric_formula? This would look like

class MetricTypeParamsProtocol(Protocol):
    """Type params add additional context to certain metric types (the context depends on the metric type)"""

    measure: Optional[MetricInputMeasure]
    measures: Optional[List[MetricInputMeasure]]
    numerator: Optional[MetricInputMeasure]
    denominator: Optional[MetricInputMeasure]
    expr: Optional[str]
    window: Optional[MetricTimeWindow]
    grain_to_date: Optional[TimeGranularity]
    metrics: Optional[List[MetricInput]]

   def metric_formula(self) -> str:
     if metric_type_params.numerator and metric_type_params.denominator:
        return f"{metric_type_params.numerator.name}/{metric_type_params.denominator.name}"
     elif metric_type_params.expr:
        return metric_type_params.expr
     else:
        return metric_type_params.measure.name

To the best of my knowledge, this covers all cases because:

• Measures require expr and resolve to the second path
• Metrics require expr and resolve to the second path
• Numerator/Denominator require each other and resolve to the first path
• Only one left is measure so we default back to that.

Alternatively we could have an additional path and raise an error here but 🤷 .

Then we'd throw an @Property decorator on it in dbt-core and we'd be able to use this in the manifest if I understand our implementation correctly.

from dbt-semantic-interfaces.

@QMalcolm based on MetricFlow Issue 469, could we add a method here that creates something called metric_formula? This would look like

@callum-mcdata Good question! In my mind the metric_formula would be in the realm of the MetricFlow given that it's getting into SQL generation / query planning 🤔 Is there a reason dbt-core would need this functionality without when MetricFlow isn't present? @tlento & @plypaul, do y'all have any thoughts on this.

from dbt-semantic-interfaces.

The main reason is that if we want to surface metric_formula to our integration partners (ie via the discovery api) then it has to be contained in the dbt Manifest. I know this field was a prioritized request from the Cloud Artifacts team

from dbt-semantic-interfaces.

Surfacing a conversation @QMalcolm and I had offline - this isn't actually a requirement of dbt-semantic-interfaces because we can implement this as an @Property method in the dbt Class.

The only funkiness that we need to take in mind is how this impacts the SemanticManifest. Can we product a manifest that contains this property and a SemanticManifest that doesn't? OR can we instantiate the SemanticManifest in MetricFlow that ignores this property in the artifact?

from dbt-semantic-interfaces.