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

Use MetricTimeDefaultGranularityPattern to resolve metric_time granularity #1332

Merged
merged 4 commits into from
Jul 16, 2024

Conversation

courtneyholcomb
Copy link
Contributor

Resolve metric time using new spec pattern in group by and filter nodes. This is a change from defaulting to the minimum time granularity for metric_time. Now we will use the max default granularity for the requested metrics.

Note the snapshot updates. These reflect another behavior change in which we don't error if metric_time is queried for metrics with two different default granularities. Instead, we choose the larger of the two, which is guaranteed to work for both metrics.

@courtneyholcomb courtneyholcomb requested a review from plypaul July 12, 2024 16:09
@cla-bot cla-bot bot added the cla:yes label Jul 12, 2024
@dbt-labs dbt-labs deleted a comment from github-actions bot Jul 12, 2024
@courtneyholcomb courtneyholcomb force-pushed the court/default-granularity1.5 branch from 7ba1065 to 8cdb31f Compare July 15, 2024 02:43
Base automatically changed from court/default-granularity1.5 to main July 15, 2024 02:47
@courtneyholcomb courtneyholcomb force-pushed the court/default-granularity-2 branch 2 times, most recently from 8e2d601 to 2a0bcb2 Compare July 15, 2024 02:54
Copy link
Contributor

@plypaul plypaul left a comment

Choose a reason for hiding this comment

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

Changes look good, but I am wondering about the behavior change for how the default now allows for what was previously an error condition. From what I remember, we wanted to error out to make it easier to see from the configs what the granularity for a time dimension was. Has that thought changed from the product side?

@courtneyholcomb
Copy link
Contributor Author

Changes look good, but I am wondering about the behavior change for how the default now allows for what was previously an error condition. From what I remember, we wanted to error out to make it easier to see from the configs what the granularity for a time dimension was. Has that thought changed from the product side?

@plypaul this is my understanding of the behavior change (mentioned in the PR description!). This scenario occurs if you query multiple metrics or a derived metric with different agg_time_dimensions. That means there are multiple default granularities for those metrics/input metrics.

  • Previously, we would error out in this scenario and force the user to specify a grain.
  • Now, we don't error. Instead we choose the larger of the default granularities, since that is guaranteed to be supported by all of the metrics. (Previously that might not have been true since cumulative metrics had granularity restrictions, but they don't anymore.) This behavior change was agreed upon by product.

These reflect a behavior change in which we don't error if metric_time is queried for metrics with two different default granularities. Instead, we choose the larger of the two, which is guaranteed to work for both metrics.
@courtneyholcomb courtneyholcomb force-pushed the court/default-granularity-2 branch from 2a0bcb2 to 425080e Compare July 15, 2024 17:36
Copy link
Contributor

@plypaul plypaul left a comment

Choose a reason for hiding this comment

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

This behavior change was agreed upon by product.

That's what I was inquiring about. Thanks!

@courtneyholcomb courtneyholcomb merged commit e46af9a into main Jul 16, 2024
15 checks passed
@courtneyholcomb courtneyholcomb deleted the court/default-granularity-2 branch July 16, 2024 01:29
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