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
dbt currently calls render() on already-compiled SQL in statement blocks. This render usually is a no-op -- if the SQL is already compiled, then calling render() on it should be a no-op. Sometimes though, compiled code contains valid jinja statements. This can happen if:
the source code contains a {% raw %} block
a user-supplied configuration is provided which contains uncompiled jinja code (the culprit in this issue)
Steps To Reproduce
Given a model like:
-- models/debug.sql
{% raw %}
select '{{ 1 + 1 }}' as debug
{% endraw %}
The resulting query that dbt runs should be:
create view "analytics"."demo_schema"."debug__dbt_tmp" as (
select '{{ 1 + 1 }}' as debug
);
Instead, it is:
create view "analytics"."demo_schema"."debug__dbt_tmp" as (
select '2' as debug
);
System information
This bug affects all supported database. It was reproduced on 0.14.0 and later, but this particular line of code has existed in dbt for quite a bit longer than that.
The text was updated successfully, but these errors were encountered:
Describe the bug
dbt currently calls render() on already-compiled SQL in statement blocks. This render usually is a no-op -- if the SQL is already compiled, then calling
render()
on it should be a no-op. Sometimes though, compiled code contains valid jinja statements. This can happen if:{% raw %}
blockSteps To Reproduce
Given a model like:
The resulting query that dbt runs should be:
Instead, it is:
System information
This bug affects all supported database. It was reproduced on 0.14.0 and later, but this particular line of code has existed in dbt for quite a bit longer than that.
The text was updated successfully, but these errors were encountered: