You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Let's use the adapter macro pattern to implement dbt's core schema tests. This will allow package maintainers to override the mechanics of the SQL for their plugin if need be.
Describe alternatives you've considered
Change macro loading precedence to allow plugin maintainers to override the macros directly? That feels worse.
Who will this benefit?
helpful for community contributed plugin maintainers
The text was updated successfully, but these errors were encountered:
The thing that will be less good about this—until we have a better answer (#2301, #2302)—is that it wouldn't be possible to override a builtin schema test from the root project.
The ability to change the behavior of the unique test by creating a local macro test_unique is something we mention frequently, especially when teaching about Jinja + dbt. That's not to say we couldn't teach it differently.
@jtcohen6 I think you still could! The macro from the project can just override the base macro name. This issue is only a problem for plugins, because plugin macros live in the dbt namespace.
Oh, you're right! So even though you couldn't override default__test_unique, or (e.g.) sqlserver__test_unique, you could just override test_unique itself. Objection withdrawn.
Describe the feature
Let's use the adapter macro pattern to implement dbt's core schema tests. This will allow package maintainers to override the mechanics of the SQL for their plugin if need be.
Describe alternatives you've considered
Change macro loading precedence to allow plugin maintainers to override the macros directly? That feels worse.
Who will this benefit?
The text was updated successfully, but these errors were encountered: