dbt-labs / dbt-labs/dbt-adapters

[Feature] Improve relation rendering safety

Open
#286 0 comments 3 reactions 0 assignees View on GitHub
type:enhancement
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

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.