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

Query parsing for custom granularities #1413

Merged
merged 8 commits into from
Sep 24, 2024
Merged

Conversation

courtneyholcomb
Copy link
Contributor

@courtneyholcomb courtneyholcomb commented Sep 20, 2024

Support custom granularities in the query parser and the group by resolution DAG.
Reviewing by commit is recommended.

Copy link
Contributor

@tlento tlento left a 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?

@@ -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(
Copy link
Contributor

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."
Copy link
Contributor

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.

Copy link
Contributor Author

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.

@tlento
Copy link
Contributor

tlento commented Sep 24, 2024

(Note - if the assertion is correct and that represents an internal problem feel free to merge.)

Base automatically changed from court/custom-grain-dfp-8 to main September 24, 2024 21:40
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.
@courtneyholcomb courtneyholcomb enabled auto-merge (squash) September 24, 2024 22:08
@courtneyholcomb courtneyholcomb merged commit 41e555f into main Sep 24, 2024
14 checks passed
@courtneyholcomb courtneyholcomb deleted the court/parse-custom-1 branch September 24, 2024 22:10
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