-
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
Enable granularities for derived metrics with time offset #726
Changes from all commits
41fc5a3
3fd699a
5ad2e92
9a31896
02eb0bf
f7a9f32
92bc655
214bddc
90df131
baa8c40
2db9e05
3a40ec1
45bece3
31caec6
d747632
5aee90e
0afb86c
d574875
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,6 @@ | ||
kind: Fixes | ||
body: Update dataflow plan to support different granularities with time offset metrics | ||
time: 2023-08-15T18:11:53.376909-07:00 | ||
custom: | ||
Author: courtneyholcomb | ||
Issue: "726" |
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -718,6 +718,7 @@ class JoinToTimeSpineNode(Generic[SourceDataSetT], BaseOutput[SourceDataSetT], A | |
def __init__( | ||
self, | ||
parent_node: BaseOutput[SourceDataSetT], | ||
metric_time_dimension_spec: TimeDimensionSpec, | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Do we want this here? Previously, the granularity was sourced from the parent node for making the time spine dataset, which contained all of the available granularities. Now it's coming in from the query parameters. Now it's getting threaded through from the callsite, and what we're doing at the callsite is taking one of the potentially many query instances and wiring it through this node. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The parent dataset will no longer be narrowed down to only the requested
I'll definitely need to update the logic to handle case #1, but not sure about #2. Thoughts on that one? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Actually, after some noodling on this I understood more what you meant. Ended up going back to inheriting the lowest granularity available from the parent dataset after all. So you can ignore this thread! |
||
time_range_constraint: Optional[TimeRangeConstraint] = None, | ||
offset_window: Optional[MetricTimeWindow] = None, | ||
offset_to_grain: Optional[TimeGranularity] = None, | ||
|
@@ -726,6 +727,7 @@ def __init__( | |
|
||
Args: | ||
parent_node: Node that returns desired dataset to join to time spine. | ||
metric_time_dimension_spec: Metric time dimension requested in query. Used to determine granularity. | ||
time_range_constraint: Time range to constrain the time spine to. | ||
offset_window: Time window to offset the parent dataset by when joining to time spine. | ||
offset_to_grain: Granularity period to offset the parent dataset to when joining to time spine. | ||
|
@@ -736,6 +738,7 @@ def __init__( | |
offset_window and offset_to_grain | ||
), "Can't set both offset_window and offset_to_grain when joining to time spine. Choose one or the other." | ||
self._parent_node = parent_node | ||
self._metric_time_dimension_spec = metric_time_dimension_spec | ||
self._offset_window = offset_window | ||
self._offset_to_grain = offset_to_grain | ||
self._time_range_constraint = time_range_constraint | ||
|
@@ -746,6 +749,11 @@ def __init__( | |
def id_prefix(cls) -> str: # noqa: D | ||
return DATAFLOW_NODE_JOIN_TO_TIME_SPINE_ID_PREFIX | ||
|
||
@property | ||
def metric_time_dimension_spec(self) -> TimeDimensionSpec: # noqa: D | ||
"""Time dimension spec to use when creating time spine table.""" | ||
return self._metric_time_dimension_spec | ||
|
||
@property | ||
def time_range_constraint(self) -> Optional[TimeRangeConstraint]: # noqa: D | ||
"""Time range constraint to apply when querying time spine table.""" | ||
|
@@ -795,9 +803,10 @@ def with_new_parents( # noqa: D | |
assert len(new_parent_nodes) == 1 | ||
return JoinToTimeSpineNode[SourceDataSetT]( | ||
parent_node=new_parent_nodes[0], | ||
metric_time_dimension_spec=self.metric_time_dimension_spec, | ||
time_range_constraint=self.time_range_constraint, | ||
offset_window=self._offset_window, | ||
offset_to_grain=self._offset_to_grain, | ||
offset_window=self.offset_window, | ||
offset_to_grain=self.offset_to_grain, | ||
) | ||
|
||
|
||
|
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.
This might not be the correct spec for metric_time - as far as I can tell, the queried_linkable_specs may include a variety of metric_time granularities. We probably want the smallest granularity one, 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.
Interesting point. What if the query included two incompatible granularities like week and month? We might need to take a list of
metric_time_specs
in the time spine builder!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.
To wrap up this thread - I ended up implementing the logic to handle multiple metric time dimensions in the dataflow to SQL logic, not the time spine builder.