Enable different granularities for metrics with time offset #426
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
courtneyholcomb
commented
Feb 6, 2023
| @@ -209,7 +209,7 @@ metric: | |||
| - txn_revenue | |||
| --- | |||
| metric: | |||
| name: "every_two_days_bookers" # because the bookings test data only spans 3 days | |||
There was a problem hiding this comment.
No longer true
courtneyholcomb
commented
Feb 6, 2023
| @@ -197,34 +197,15 @@ def _make_time_spine_data_set( | |||
|
|
|||
| # If the requested granularity is the same as the granularity of the spine, do a direct select. | |||
| if metric_time_dimension_instance.spec.time_granularity == time_spine_source.time_column_granularity: | |||
| return SqlDataSet( | |||
There was a problem hiding this comment.
Removed some redundant code here
plypaul
requested changes
May 19, 2023
There was a problem hiding this comment.
As per discussion, there are some uncertainties on how the feature should work (from a product perspective), and we haven't prioritized a resolution. Since I'm using github to manage my review queue, marking this is Request Changes so that it's not on my list.
|
PR outdated; new one here #726 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
With the current placement of the
JoinToTimeSpineNodein the dataflow plan, we filter down to time columns with the requested granularity BEFORE joining to time spine. Since joining to time spine expects an unaggregated time column, this means queries with any granularity besidesDAYdon't return expected results. Here, we move the time spine join to happen before time column aggregation.For cumulative metrics, we also needed to change the order of the dataflow plan, from
FilterElementsNode -> JoinOverTimeRangeNode(both required) toJoinOverTimeRangeNode (optional, only used if a time dimension is requested) -> JoinToTimeSpineNode (optional, only used for offset metrics) -> FilterElementsNode. This ensures we'll have the columns needed when joining to time spine.Unrelated to time offset, this change also removes the unnecessary
JoinOverTimeRangeNodestep for a cumulative metric queried without a time dimension, which 1) does nothing in SQL and 2) might result in inaccurate costing for that query.