-
Notifications
You must be signed in to change notification settings - Fork 98
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Consume new cumulative_type_params
fields
#1293
Conversation
cbb1d71
to
6fa4f5e
Compare
This will ensure that any window or grain_to_date set in the type_params fields will be copied into the corresponding cumulative_type_params fields.
Left some with the old structure to ensure the transformation is working as expected.
225b8ba
to
ee1b43c
Compare
metricflow-semantics/extra-hatch-configuration/requirements.txt
Outdated
Show resolved
Hide resolved
@@ -25,6 +26,7 @@ def parse_manifest_from_dbt_generated_manifest(manifest_json_string: str) -> Pyd | |||
# The serialized object in the dbt project does not have all transformations applied to it at | |||
# this time, which causes failures with input measure resolution. | |||
# TODO: remove this transform call once the upstream changes are integrated into our dependency tree | |||
# TODO: align rules between DSI, here, and MFS (if possible!) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh wow. These were all supposed to be removed ages ago but I think we just always applied them. I don't know if we can stop now, I guess we'll see.
We might want to move this to the CLI package in the future.
FROM ( | ||
-- Join Self Over Time Range | ||
-- Pass Only Elements: ['txn_revenue', 'metric_time__week', 'metric_time__day'] | ||
-- Aggregate Measures | ||
-- Compute Metrics via Expressions | ||
SELECT | ||
subq_12.metric_time__day AS metric_time__day |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wait, this doesn't look right. We're now doing the initial aggregation against WEEK instead of DAY, and then taking the average of those grouped by week, which is effectively a no-op. Is that expected?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shoot, you're right. I wonder if the column pruner got to it - investigating 🧐
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Definitely seems like an optimizer issue since the non-optimized SQL looks right.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@tlento fixed this bug in the latest 3 commits.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oops, wrong button.
The changes are reasonable but the SQL for the AVG window function type doesn't seem correct to me. I don't see how the window function ever gets more than one input row per window now.
…roup by Paul had a TODO up for this already, but this appears to be the first circumstance that made handling it necessary.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@@ -8,23 +8,19 @@ FROM ( | |||
metric_time__week | |||
, t2mr | |||
FROM ( | |||
-- Compute Metrics via Expressions |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh that's weird, but I guess it makes sense?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah I think they just get optimized in a different way with this change. But not an incorrect way...
Completes SL-2413
Consume new
cumulative_type_params
fields (window
andgrain_to_date
) instead oftype_params
cumulative fields. Eventually we will retire thetype_params
fields altogether. For now, we have a transformation that copies the fields fromtype_params
tocumulative_type_params
, if not yet set. This ensures that we only need to consume the new fields here.This is the last step needed to enable non-default granularities for cumulative metrics in MF 🥳