-
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
Handle ambiguous metric_time
filters in YAML definitions
#1342
Conversation
dbe9a2f
to
99d27b0
Compare
metric_time
filters in YAML definitionsmetric_time
filters in YAML definitions
5c31d3a
to
ab5ba75
Compare
ab5ba75
to
33c9852
Compare
filter: "{{ TimeDimension('metric_time') }} < '2012-12-20'" | ||
--- | ||
metric: | ||
name: bookings_dec_19_2019 |
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.
Should this be something like bookings_between...
? Also feel like there can be a more "friendly" metric that we could create for these tests, but I don't have any good ideas.
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.
Yeah, it's a weird use case but I figured it's really the SQL that matters here, not the usefulness of the metric. Will update the name!
b0f3528
to
25c02ba
Compare
Handle ambiguous
metric_time
filters in metric YAML definitions. The expected behavior for an ambiguousmetric_time
filter in a metric's YAML definition is that it will use the default time granularity for the metric where the filter is defined. This means that if a filter is defined on a derived metric's input metric, that filter will use the derived metrics time granularity, not the input metric's time granularity.Aside from that change, this adds tests for other types of ambiguous
metric_time
YAML filters.