-
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
Default granularity prep #1321
Default granularity prep #1321
Changes from 3 commits
66dd77c
6e68ad6
fd57e01
7435bee
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 |
---|---|---|
|
@@ -570,6 +570,7 @@ class MetricSpec(InstanceSpec): # noqa: D101 | |
alias: Optional[str] = None | ||
offset_window: Optional[PydanticMetricTimeWindow] = None | ||
offset_to_grain: Optional[TimeGranularity] = None | ||
default_granularity: Optional[TimeGranularity] = None | ||
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 fields in the spec classes should be values that can't be inferred from the semantic manifest. From 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. Updated! |
||
|
||
@staticmethod | ||
def from_element_name(element_name: str) -> MetricSpec: # noqa: D102 | ||
|
@@ -598,7 +599,12 @@ def has_time_offset(self) -> bool: # noqa: D102 | |
|
||
def without_offset(self) -> MetricSpec: | ||
"""Represents the metric spec with any time offsets removed.""" | ||
return MetricSpec(element_name=self.element_name, filter_specs=self.filter_specs, alias=self.alias) | ||
return MetricSpec( | ||
element_name=self.element_name, | ||
filter_specs=self.filter_specs, | ||
alias=self.alias, | ||
default_granularity=self.default_granularity, | ||
) | ||
|
||
|
||
@dataclass(frozen=True) | ||
|
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 confirm - what's the expected behavior when you have a derived metric that depends on two other metrics that have different default time granularities? Based on
SetDefaultGranularityRule
, it seems that the default granularity for parent metrics are not intended to be considered.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.
That's correct. But now that you bring it up, I'm thinking I should confirm that behavior with product, so I'll post about it in #dev-metricflow and see what people think.
Thinking I can probably change this behavior on top of the stack if we decide to go that route.