-
Notifications
You must be signed in to change notification settings - Fork 496
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
Feature: use adapter.dispatch #267
Conversation
Thank you! I also think we should fully deprecate |
Agree! I think there's a number of older deprecation warnings that we could actually deprecate soon. We've talked about doing this for dbt deprecations in v0.19 or v0.20. |
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 all LGTM.
My only thoughts are:
- Do we want to document how to override a macro? I'm still not fully sure who wants to use this behavior, but it must be supported for a reason, right?
- Do we want to add something to the
contributing
section of the readme about adapter macros? or nah? We probably need to write better docs on contributing that cover testing / what we do and don't support etc, so maybe that's part of a bigger project. - Also, pls update
changelog.md
:D
|
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 forgot to submit the comment lol
{%- do exceptions.warn(error_message) -%} | ||
|
||
{{ return(dbt_utils.get_relations_by_pattern(schema_pattern, table_pattern, exclude='', database=target.database)) }} |
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.
So this was some bad code that I merged previously. However, I think this is a breaking change, the previous get_tables_by_pattern
returned SQL (here)
{{ return(dbt_utils.get_relations_by_pattern(schema_pattern, table_pattern, exclude='', database=target.database)) }} | |
{{ return(dbt_utils.get_tables_by_pattern_sql(schema_pattern, table_pattern, exclude='', database=target.database)) }} |
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.
Given that:
- the only place that the
get_tables_by_prefix
macro was used is inget_relations_by_pattern
macro - AND, I doubt anyone was using
get_tables_by_prefix
independently ofget_relations_by_pattern
I'd be happy to just straight-out remove the get_tables_by_prefix
macro
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.
If you want to remove it, we can do so in #268
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 let's do it
This is a:
main
)Description & motivation
adapter_macro
withadapter.dispatch
dbt_utils_dispatch_list
, whereby end users can provide a list of other package namespaces that will dispatch to beforedbt_utils
, whenever adbt_utils
macro is called_is_ephemeral
to support plugins with custom ephemeral prefixes (see Feature: adapter cte generation dbt-core#2712)date_spine
on postgresget_relations_by_prefix
andget_relations_by_pattern
since there was a lot of duplicated code, and the tests for the latter were failing on BQChecklist