Skip to content
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] Improve relation rendering safety #286

Open
3 tasks done
colin-rogers-dbt opened this issue Aug 23, 2024 · 0 comments
Open
3 tasks done

[Feature] Improve relation rendering safety #286

colin-rogers-dbt opened this issue Aug 23, 2024 · 0 comments
Labels
enhancement New feature or request

Comments

@colin-rogers-dbt
Copy link
Contributor

colin-rogers-dbt commented Aug 23, 2024

Is this your first time submitting a feature request?

  • I have read the expectations for open source contributors
  • I have searched the existing issues, and I could not find an existing issue for this feature
  • 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

@colin-rogers-dbt colin-rogers-dbt added enhancement New feature or request triage and removed triage labels Aug 23, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant