Skip to content
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

Merged
merged 13 commits into from
Jun 20, 2024

Conversation

courtneyholcomb
Copy link
Contributor

@courtneyholcomb courtneyholcomb commented Jun 18, 2024

Completes SL-2413

Consume new cumulative_type_params fields (window and grain_to_date) instead of type_params cumulative fields. Eventually we will retire the type_params fields altogether. For now, we have a transformation that copies the fields from type_params to cumulative_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 🥳

Copy link

linear bot commented Jun 18, 2024

@cla-bot cla-bot bot added the cla:yes label Jun 18, 2024
@courtneyholcomb courtneyholcomb force-pushed the court/cumulative-type-params branch 4 times, most recently from cbb1d71 to 6fa4f5e Compare June 19, 2024 00:52
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.
@courtneyholcomb courtneyholcomb force-pushed the court/cumulative-type-params branch from 225b8ba to ee1b43c Compare June 20, 2024 19:53
@courtneyholcomb courtneyholcomb marked this pull request as ready for review June 20, 2024 20:37
@courtneyholcomb courtneyholcomb added the Run Tests With Other SQL Engines Runs the test suite against the SQL engines in our target environment label Jun 20, 2024
@@ -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!)
Copy link
Contributor

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
Copy link
Contributor

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?

Copy link
Contributor Author

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 🧐

Copy link
Contributor Author

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.

Copy link
Contributor Author

@courtneyholcomb courtneyholcomb Jun 20, 2024

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.

Copy link
Contributor

@tlento tlento left a 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.
@courtneyholcomb courtneyholcomb requested a review from tlento June 20, 2024 23:23
@courtneyholcomb courtneyholcomb added Run Tests With Other SQL Engines Runs the test suite against the SQL engines in our target environment and removed Run Tests With Other SQL Engines Runs the test suite against the SQL engines in our target environment labels Jun 20, 2024
@courtneyholcomb courtneyholcomb temporarily deployed to DW_INTEGRATION_TESTS June 20, 2024 23:29 — with GitHub Actions Inactive
@courtneyholcomb courtneyholcomb temporarily deployed to DW_INTEGRATION_TESTS June 20, 2024 23:29 — with GitHub Actions Inactive
@courtneyholcomb courtneyholcomb temporarily deployed to DW_INTEGRATION_TESTS June 20, 2024 23:29 — with GitHub Actions Inactive
@courtneyholcomb courtneyholcomb temporarily deployed to DW_INTEGRATION_TESTS June 20, 2024 23:29 — with GitHub Actions Inactive
@github-actions github-actions bot removed the Run Tests With Other SQL Engines Runs the test suite against the SQL engines in our target environment label Jun 20, 2024
Copy link
Contributor

@tlento tlento left a comment

Choose a reason for hiding this comment

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

ted lasso let's give it a shot

@@ -8,23 +8,19 @@ FROM (
metric_time__week
, t2mr
FROM (
-- Compute Metrics via Expressions
Copy link
Contributor

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?

Copy link
Contributor Author

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...

@courtneyholcomb courtneyholcomb merged commit 6c5f94f into main Jun 20, 2024
30 checks passed
@courtneyholcomb courtneyholcomb deleted the court/cumulative-type-params branch June 20, 2024 23:39
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.

2 participants