Skip to content

Conversation

@theyostalservice
Copy link
Contributor

@theyostalservice theyostalservice commented Oct 2, 2025

Depends on #1876

Upstream PR bumps the dsi version, implicitly updating tests to using the default ruleset from dsi. We can't do that for production MF rn because MF uses an extra transformation internally, so this PR adds all the newer built in PRs from dsi to metricflow-semantics/metricflow_semantics/model/dbt_manifest_parser.py to be used in real circumstances.

(If time was less limited before coalesce, I'd prefer to move the rule upstream if possible, but I don't want to pick up extra work before code freeze.)

Edit: There's also a rule (AddInputMeasuresToMetrics) that only works in dsi. It probably merits a refactor/rewrite later to clean up the usage code here, but I'd rather prioritize getting this updated here for now.

@cla-bot cla-bot bot added the cla:yes label Oct 2, 2025
@github-actions
Copy link

github-actions bot commented Oct 2, 2025

Thank you for your pull request! We could not find a changelog entry for this change. For details on how to document a change, see the contributing guide.

Copy link
Contributor Author

theyostalservice commented Oct 2, 2025

This stack of pull requests is managed by Graphite. Learn more about stacking.

@theyostalservice theyostalservice force-pushed the patricky/get-mf-using-new-transformations branch from edd4e74 to a48c2f4 Compare October 2, 2025 19:59
@theyostalservice theyostalservice force-pushed the patricky/bump-dsi-version-hooray branch from 3bc07c3 to ec37377 Compare October 2, 2025 19:59
@theyostalservice theyostalservice changed the base branch from patricky/bump-dsi-version-hooray to graphite-base/1877 October 2, 2025 20:01
@theyostalservice theyostalservice force-pushed the patricky/get-mf-using-new-transformations branch from a48c2f4 to 50c1434 Compare October 2, 2025 23:45
@theyostalservice theyostalservice changed the base branch from graphite-base/1877 to patricky/bump-dsi-version-hooray October 2, 2025 23:45
@theyostalservice theyostalservice force-pushed the patricky/get-mf-using-new-transformations branch from 50c1434 to 1bb321e Compare October 3, 2025 00:13
@theyostalservice theyostalservice force-pushed the patricky/bump-dsi-version-hooray branch from bdcdd56 to 0fd70d9 Compare October 3, 2025 00:13
@theyostalservice theyostalservice force-pushed the patricky/get-mf-using-new-transformations branch from 1bb321e to 68f8985 Compare October 3, 2025 15:03
@theyostalservice theyostalservice changed the base branch from patricky/bump-dsi-version-hooray to graphite-base/1877 October 3, 2025 15:08
theyostalservice added a commit that referenced this pull request Oct 3, 2025
Version BUUUUUUUMP

This PR is just here to pull in the new transformations and such from dsi.  Early commits in this PR will be pinned to commits while I'm working on feeding dbt-labs/dbt-semantic-interfaces#436 to the merge-asaurus.

Snapshot updates reflect the fact that now(*) we produce more metrics to replace measures, reflecting the changes in structure for the new user YAML.

(*) "now" is true, but ONLY IN TESTS.  Because of a transformation rule that exists only in MF right now, we don't use the list of transformations directly from dsi.  See upstack #1877 for the PR that brings these changes to prod.  OTH, tests DO run on the default list of metric transformations from dsi, so the snapshots needed more immediate updating.
@theyostalservice theyostalservice force-pushed the patricky/get-mf-using-new-transformations branch from 68f8985 to c718dfe Compare October 3, 2025 15:08
@graphite-app graphite-app bot changed the base branch from graphite-base/1877 to main October 3, 2025 15:09
@theyostalservice theyostalservice force-pushed the patricky/get-mf-using-new-transformations branch from c718dfe to d0c497e Compare October 3, 2025 15:09
Comment on lines +37 to +42
# These individual rules come from rule_set.convert_legacy_measures_to_metrics_rules, but
# dsi requires AddInputMetricMeasuresRule, and metricflow requires that we do NOT run that rule
# as it is incompatible with a parser like dbt-core that pre-populates input measures.
CreateProxyMeasureRule(),
FlattenSimpleMetricsWithMeasureInputsRule(),
ReplaceInputMeasuresWithSimpleMetricsTransformationRule(),
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if we're properly motivated, I can refactor this in dsi to make this cleaner here, but for now, I'd really like to get this in and working today.

@theyostalservice theyostalservice marked this pull request as ready for review October 3, 2025 15:50
@theyostalservice theyostalservice requested a review from a team as a code owner October 3, 2025 15:50
Copy link
Contributor

@courtneyholcomb courtneyholcomb left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

curious what happened with AddInputMetricMeasuresRule / if that's an issue? But this looks good

Copy link
Contributor Author

theyostalservice commented Oct 3, 2025

It took me a bit of digging to figure this out, but here's what I know about the current situation:

  • In DSI, it does what it says, but if the name is hard to parse for you (it was for me!), it looks at all the measures a metric relies on and then fills up its input_measures parameter recursively, i.e. it will look at a derived metric and get the measures for the metrics that belong to that metric.
    • If at metric has any values for input_metrics when this rule starts to run, it fails and throws exceptions. (This is what completely breaks things if we keep it in.)
  • In metricflow, this was already disincluded because in core, we already fill the input_metrics fields.

So, imo, the most reasonable clean-up outcomes we could pursue here:

  1. Make AddInputMetricMeasuresRule a bit smarter, so it only throws if the node has measures that are wrong. This is the ultimate compromise choice, avoiding any disruption in expected dsi behavior around measures.
  2. Remove AddInputMetricMeasuresRule from the pydantic rules list. This seems nice because it gets rid of cruft we just don't need at all.

@theyostalservice theyostalservice merged commit 82ed4b4 into main Oct 3, 2025
18 checks passed
@theyostalservice theyostalservice deleted the patricky/get-mf-using-new-transformations branch October 3, 2025 18:31
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants