-
Notifications
You must be signed in to change notification settings - Fork 99
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
Implemented date_part in where filter #852
Conversation
95cec32
to
acae8fa
Compare
0f19319
to
8d9c031
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.
This looks like two PRs in one. Is there something wonky in the underlying branch, or should this be split up?
I fixed it now. I'm sorry about that. |
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.
Looks great, thanks! I'll hold this open until after 0.203.0 is out (unless that drags past Monday, in which case maybe we just merge this).
self.time_granularity_name: Optional[str] = None | ||
|
||
@property | ||
def time_dimension_spec(self) -> TimeDimensionSpec: |
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.
Ah, so this returns a TimeDimension with DEFAULT_TIME_GRANULARITY if neither grain nor date_part are set. Interesting. I think that makes the most sense with where we're heading with time dimension expressions.
("{{ TimeDimension('metric_time', 'WEEK', date_part_name='year') }} = '2020'"), | ||
("{{ Dimension('metric_time').date_part('year').grain('WEEK') }} = '2020'"), | ||
("{{ Dimension('metric_time').grain('WEEK').date_part('year') }} = '2020'"), |
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.
I hope these aren't case-sensitive. I may add some additional tests on after we merge.
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.
I had fixed the case sensitivity here dbt-labs/dbt-semantic-interfaces#207. So, date_part was case-sensitive as of this PR, but that change to DSI fixes it.
Description
This PR allows users to specify
date_part
in the where filter. This is useful for the Jinja syntax as well as integrations such as Tableau.