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

(#1717) fix for re-rendering in statement calls #1719

Merged
merged 1 commit into from
Sep 4, 2019

Conversation

drewbanin
Copy link
Contributor

@drewbanin drewbanin commented Sep 3, 2019

Fixes #1717
Fixes #1108

This PR removes the call to render() in statement blocks. For most applications of dbt, this shouldn't change anything at all. I had to amend the run_hooks macro to render hooks, as they previously relied on statement blocks to be rendered. While I was in there, I added a check to skip queries for empty hooks, which should fix #1108.

We should think hard about if there are any other built-in parts of the dbt codebase which rely on statements re-rendering queries - I don't believe there are, but if they do exist, they're probably not explicitly tested. We should also add a note to the release notes / migration guide describing this change in behavior, as it could be very breaking for some dbt projects out there.

@cla-bot cla-bot bot added the cla:yes label Sep 3, 2019
@drewbanin drewbanin force-pushed the fix/dont-rerender-in-statements branch from 7b7c13f to d1a49d3 Compare September 3, 2019 22:55
Copy link
Contributor

@beckjake beckjake left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The hooks part is pretty unfortunate, but I don't see a good way around it that doesn't break important parts of dbt, and the rest of this is really important.

Nice find! I can't believe how long this sat around causing fishy-looking behavior with nobody noticing...

@drewbanin
Copy link
Contributor Author

drewbanin commented Sep 3, 2019

I actually feel great about this hooks change. Hooks were previously kind of magic - I didn't realize that they only worked because they went through statements! I feel really good about making that particular interaction explicit, rather than implicit.

Super glad we're fixing this - just saw a similar (unrelated to hooks) issue pop up in Slack. Looks like there's a nonzero incidence of folks using code like:

{{ config(target_schema='{{ some jinja here }}') }}

which fails in terrible and confusing ways! After this change, it should fail in a single, easy to debug way haha

Copy link
Contributor

@beckjake beckjake left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry Drew, I thought I approved this before!

@drewbanin drewbanin merged commit 19f052e into dev/louisa-may-alcott Sep 4, 2019
@drewbanin drewbanin deleted the fix/dont-rerender-in-statements branch September 4, 2019 13:22
@blisteringherb
Copy link

@drewbanin If we're trying to use the {{ config(target_schema='{{ env_var('SOME_ENV_VAR') }}') }} syntax, what's the proper way to use that? I'm running into errors with every permutation I can think of.

@drewbanin
Copy link
Contributor Author

@blisteringherb that would be

{{ config(target_schema=env_var('SOME_ENV_VAR')) }}

You generally don't want to "nest" curly brackets the way you've shown in your example.

@blisteringherb
Copy link

Thank you for your help! @drewbanin

@gshank gshank mentioned this pull request Jan 10, 2023
6 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
3 participants