You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
15:07:37 Running with dbt=1.6.1
15:07:37 Registered adapter: snowflake=1.6.2
15:07:38 PydanticMetric revenue_growth_mom has multiple identical input measures specifications for measure revenue. This might be hiding a semantic error. Input measure specification: name='revenue' filter=None alias=None.
The issue here is we are running the input measures validator on derived metrics without accounting for the fact that a derived metric is made up of multiple metrics which might themselves be sourced from shared measures.
There's nothing a user can do to fix this or act upon it. Indeed, nothing is even broken - in this case the user wants to compute some expr based on a transformation of the same input metric. That transformation and alias will naturally apply to the measure input on the metrics, but we can't detect that at this level, so we raise the validation warning about shared input measures (duh) with a baffling "alias: None" in there (because the input measures don't have aliases set).
Expected Behavior
We would expect this to pass validation cleanly, as nothing is wrong.
More generally, derived metric input validation should not be validating input measures. It should be validating input metrics.
Steps To Reproduce
Define a derived metric that relies on two distinct transformations of the same input metric (offset or filter) with aliases properly set and run the validation in a mode that will print warnings.
Relevant log output
No response
Environment
- OS:
- Python:
- dbt:
- dbt-semantic-interfaces:
Additional Context
No response
The text was updated successfully, but these errors were encountered:
Is this a new bug in dbt-semantic-interfaces?
Current Behavior
Running validation on a model with a metric specified like so:
Prints this warning:
The issue here is we are running the input measures validator on derived metrics without accounting for the fact that a derived metric is made up of multiple metrics which might themselves be sourced from shared measures.
There's nothing a user can do to fix this or act upon it. Indeed, nothing is even broken - in this case the user wants to compute some expr based on a transformation of the same input metric. That transformation and alias will naturally apply to the measure input on the metrics, but we can't detect that at this level, so we raise the validation warning about shared input measures (duh) with a baffling "alias: None" in there (because the input measures don't have aliases set).
Expected Behavior
We would expect this to pass validation cleanly, as nothing is wrong.
More generally, derived metric input validation should not be validating input measures. It should be validating input metrics.
Steps To Reproduce
Define a derived metric that relies on two distinct transformations of the same input metric (offset or filter) with aliases properly set and run the validation in a mode that will print warnings.
Relevant log output
No response
Environment
Additional Context
No response
The text was updated successfully, but these errors were encountered: