dbt-labs / dbt-labs/dbt-adapters
[Feature] Improve relation rendering safety
- Dominant language
- Python
- Stars
- 233
- Forks
- 362
- Avg merge
- 3d 22h
- Merged PRs (30d)
- 9
Description
### Is this your first time submitting a feature request?
- [X] I have read the [expectations for open source contributors](https://docs.getdbt.com/docs/contributing/oss-expectations)
- [X] I have searched the existing issues, and I could not find an existing issue for this feature
- [X] I am requesting a straightforward extension of existing dbt-adapters functionality, rather than a Big Idea better suited to a discussion
### Describe the feature
This is a follow up to #257
Having added `{{ relation.render() }}` everywhere we are now discovering the wide world of custom materializations and macros that people have created. In many of these a `relation` is not of type `Relation` but is actually a string, as a result when we call `.render()` an exception is raised (ex `'str object' has no attribute 'render'`).
To support these use case we should be more defensive and replace all instances of `{{ relation.render() }}` with a new macro function that first checks the type and only calls `.render` if it's supported.
Something like:
```
{%- macro safe_render_relationl(relation) -%}
{% if relation is string%}
return {{ relation }}
return {{ relation.render() }}
{%- endmacro -%}
```
or in python:
```
def safe_render_relation(relation Union[Relation, str]) -> str:
... something similar
```
### Describe alternatives you've considered
_No response_
### Who will this benefit?
_No response_
### Are you interested in contributing this feature?
_No response_
### Anything else?
_No response_
Contributor guide
Assessment
This issue has not been assessed yet.