-
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
Tests for Metric.time_granularity
#1325
Conversation
f9793a9
to
5091b26
Compare
ce71955
to
8666f5c
Compare
aa64a98
to
454613d
Compare
8e2d601
to
2a0bcb2
Compare
454613d
to
08f159b
Compare
2a0bcb2
to
425080e
Compare
7e7120b
to
2f0cdc0
Compare
2f0cdc0
to
72e1986
Compare
Following what you noted in the description - are you planning to add more items to this PR or has that already been done? |
@plypaul planning to add them in a separate PR! |
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.
Gotcha. In that case:
- Is there a specific reason why the default granularity was updated for those metrics? It has resulted in a number of snapshot changes, so I am wondering if there's an interaction between those metrics and default granularity that's important to check.
- For testing resolution, tests of the form in (
metricflow/metricflow-semantics/tests_metricflow_semantics/query/test_ambiguous_entity_path.py
Line 23 in a55c402
def test_resolvable_ambiguous_entity_path( # noqa: D103 test_query_parser.py
. - Does the DSI version bump need to go in this PR or can it be done in a separate PR?
I chose to add
Sure, I can add some tests there! |
default_granularity
Metric.time_granularity
b794754
to
cd211c6
Compare
cd211c6
to
ec2a052
Compare
@plypaul moved those query parser tests, and separated out the version bump into a new PR. |
It was more that I was wondering whether there as any particular interaction between the default granularity and the fill configuration option. |
@@ -92,3 +92,31 @@ metric: | |||
metrics: | |||
- name: monthly_metric_0 | |||
filter: "{{ TimeDimension('metric_time') }} = '2020-01-01'" | |||
--- | |||
metric: | |||
name: simple_metric_with_time_granularity |
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.
More like ...with_default_time_granularity
?
@@ -51,6 +51,10 @@ | |||
expr: "1" | |||
agg: sum | |||
create_metric: true | |||
- name: monthly_bookings |
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 can be removed now?
Nope, there shouldn't be. Just happened to be that the metrics I added a time granularity to were used in those tests. |
Adds
default_granularity
tests for query parsing, SQL rendering, query output, and check query tests.Also cleans up a couple of comments due to product decisions that changed the expected implementation of this feature.
I will add more tests once we finalize the expected behavior for more specific scenarios.