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
We want this to return a boolean, not a string, and a jinja native env would help us do that.
This is a big big change, and i think it will make 95% of people really happy and 5% of people sad. We should verify that there's a sane upgrade path here, so if you have some currently working code like:
some_field: "{{ 'True' }}
you still have a recourse for rendering this as a string, rather than a boolean, once this change is live.
Describe alternatives you've considered
Make configs type-aware and coerce stringy input into an expected type.
Additional context
I have not yet completely wrapped my head around the exact nature of the jinja native environment behavior. Here are some things that I want to be true, that I would love to verify before we start working on this:
-- this should return a boolean True value
my-config: "{{ true }}"
-- this should return a string value [??]
my-config: "{{ 'True' }}"
-- this should return a string value
my-config: "{{ 'true' }}"
-- this should return an integer value
my-config: "{{ 123 }}"
-- this should return a string value [??]
my-config: "{{ '123' }}"
The lines marked [??] are places where I am presently unsure of the jinja native env behavior. We should think really really hard about the implications of this change.
As beneficial as I think this change will be, I don't know that we can ship it if there's no ability to return a stringy value like "True" or "123" in this context. As long as there's some sane way to do that, then I'm all for making getting a PR to address this issue merged.
Who will this benefit?
Dynamic models configurers
The text was updated successfully, but these errors were encountered:
Describe the feature
dbt should default to using a jinja native environment for parsing jinja-rendered fields out of .yml files. This includes:
Jinja's native environment will help coerce string values to their native types (int, float, boolean, etc). The most obvious immediate use-case is:
We want this to return a boolean, not a string, and a jinja native env would help us do that.
This is a big big change, and i think it will make 95% of people really happy and 5% of people sad. We should verify that there's a sane upgrade path here, so if you have some currently working code like:
you still have a recourse for rendering this as a string, rather than a boolean, once this change is live.
Describe alternatives you've considered
Make configs type-aware and coerce stringy input into an expected type.
Additional context
I have not yet completely wrapped my head around the exact nature of the jinja native environment behavior. Here are some things that I want to be true, that I would love to verify before we start working on this:
The lines marked
[??]
are places where I am presently unsure of the jinja native env behavior. We should think really really hard about the implications of this change.As beneficial as I think this change will be, I don't know that we can ship it if there's no ability to return a stringy value like
"True"
or"123"
in this context. As long as there's some sane way to do that, then I'm all for making getting a PR to address this issue merged.Who will this benefit?
Dynamic models configurers
The text was updated successfully, but these errors were encountered: