-
Notifications
You must be signed in to change notification settings - Fork 94
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
Query parsing for custom granularities #1413
Conversation
8ffcd77
to
42c6514
Compare
c841553
to
5a9baa6
Compare
d10ad9b
to
d85c738
Compare
5a9baa6
to
82dcf53
Compare
d85c738
to
630cfe7
Compare
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.
Left some inlines. The one potential blocking question is about that new assertion. Will there always be a match? If there isn't, what used to happen? Would that fall through to some validation that returns a nicer error than the assertion will throw?
metricflow-semantics/metricflow_semantics/specs/patterns/entity_link_pattern.py
Outdated
Show resolved
Hide resolved
metricflow-semantics/metricflow_semantics/specs/patterns/entity_link_pattern.py
Show resolved
Hide resolved
metricflow-semantics/metricflow_semantics/specs/patterns/entity_link_pattern.py
Show resolved
Hide resolved
@@ -77,8 +77,9 @@ def spec_pattern(self, input_str: str, semantic_manifest_lookup: SemanticManifes | |||
) | |||
|
|||
# At this point, len(input_str_parts) >= 2 | |||
custom_granularity_names: List[str] = [] # TODO | |||
valid_granularity_names = [granularity.value for granularity in TimeGranularity] + custom_granularity_names | |||
valid_granularity_names = [granularity.value for granularity in TimeGranularity] + list( |
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.
Shall we make this a set?
) | ||
assert sorted_time_grains, "Each time dimension spec should have at least one 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.
Is that always true? We never checked this before.
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.
Yes! If you read the loop above on line 52, if we ever add a spec key to the dict, we also add its time granularity. And time dimension specs are required to have a non-null time granularity.
Also, if that weren't true, we would have previously run into a KeyError
due to the indexing on this list.
(Note - if the assertion is correct and that represents an internal problem feel free to merge.) |
82dcf53
to
d6b83dd
Compare
This will allow us to pass around custom granularity names in addition to standard granularity names, without needing the manifest context required to populate ExpandedTimeGranularity until that context is actually used.
This includes a bit of a refactor to simplify the time dimension generation code.
630cfe7
to
27e2c28
Compare
Support custom granularities in the query parser and the group by resolution DAG.
Reviewing by commit is recommended.