-
Notifications
You must be signed in to change notification settings - Fork 157
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
case insensitive check on partition matching #888
Conversation
or (conf_partition.time_ingestion_partitioning and table_field is not None) | ||
) and table_granularity == conf_partition.granularity | ||
) and table_granularity.lower() == conf_partition.granularity.lower() |
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.
Op's table actually didn't have the granularity
key set:
-- models/foo_sans_granularity.sql
{{
config(
partition_by={
"field": "updated_at",
"data_type": "date",
}
)
}}
select id, updated_at, updated_at_utc from sources.raw
Do we need to account for 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.
Daily partitioning is the default for all column types.
My understanding from the dbt docs was that the default granularity is day-partitioned.
Is this where the default is set?
https://github.com/dbt-labs/dbt-bigquery/blob/main/dbt/adapters/bigquery/impl.py#L77
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, there is a default so it should be safe
Thanks for the triage @dbeatty10 ! Could you enable the OK to test to run the ITs too? |
Re-opening to make the |
@mikealfare it looks like both this PR & #866 are failing over |
@github-christophe-oudar rerunning tests to see if it was ci/cd. |
It's still failing on those tests and I don't know why 🤔 |
892e28f
to
02b19bd
Compare
@github-christophe-oudar great work on this. |
* case insensitive check on partition matching * Review change --------- Co-authored-by: Christophe Oudar <[email protected]>
Great! Thanks for the swift turnaround on this bugfix 🙌 |
* case insensitive check on partition matching * Review change --------- Co-authored-by: Christophe Oudar <[email protected]> Co-authored-by: Christophe Oudar <[email protected]>
resolves #886
Problem
The API returns sometimes upper cased fields such
timePartitioning.type
and in case the user config has also a different casing, we should do a case insensitive check on partition matching.Solution
It introduce a proper case insensitive check on partition field matching
Checklist