More consistent results from get_columns_in_relation #355
Conversation
There was a problem hiding this comment.
This looks good to me for:
- establishing full parity between the
get_columns_in_relationmacro andadapter.get_columns_in_relation.
My understanding is that once this PR is merged, then dbt-labs/dbt-core#5232 can be merged.
|
@dbeatty10 Thanks for the quick review! Both of these PRs solve the issue independently. We could say that this PR renders dbt-labs/dbt-core#5232 unnecessary, but I'd still prefer the consistency there, too, around how we call this method in our internal macros. |
* More consistent results from get_columns_in_relation * Not dispatched, full name * Add changelog entry
* More consistent results from get_columns_in_relation * Not dispatched, full name * Add changelog entry
| @@ -168,11 +168,15 @@ | |||
| {%- endcall -%} | |||
| {% endmacro %} | |||
|
|
|||
| {% macro spark__get_columns_in_relation(relation) -%} | |||
| {% call statement('get_columns_in_relation', fetch_result=True) %} | |||
| {% macro spark__get_columns_in_relation_raw(relation) -%} | |||
There was a problem hiding this comment.
@jtcohen6 Is it possible to make it dispatch pattern? We might want to override this. Thanks.
There was a problem hiding this comment.
I submitted a PR #365, could you take a look at it? Thanks!
There was a problem hiding this comment.
Thank you @ueshin -- utilizing the dispatch pattern makes good sense. 👍
resolves #354
Description
Context in the issue. Changes here:
get_columns_in_relationmacro toget_columns_in_relation_rawget_columns_in_relationmacro that just returnsadapter.get_columns_in_relationThis should also fix CI, parallel to the change in dbt-labs/dbt-core#5232 (being tested in #353)
Checklist
CHANGELOG.mdand added information about my change to the "dbt-spark next" section.