-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
improve strict undefined #1559
improve strict undefined #1559
Conversation
@beckjake how does that global flag interact across threads? if we are running an RPC server where one thread is in "parse mode" and the other is in "compile mode", what happens? (same question for |
The RPC server runs dbt in processes, not threads, so globals aren't shared! (technically it's a thread that starts a process, but that's not important) |
Yep, ok, makes sense. But it's also true to say that this adds to the list of things that we would have to change if we wanted to switch from processes to threads in the future, right? (I don't know that we'd want to do that, just curious) |
Yeah. I think at this point threads are pretty infeasible, honestly - just from a control standpoint, you can't kill a thread (yes, there is pthread_kill, never ever use it). I also realized that when parsing this branch does not set PARSE_MODE=True when it's parsing RPC-provided macros - I'll add that. |
I think something funky happens when recording the name of the macro where the warning is generated:
This generates the following warnings on
I'd expect the second warning to say |
add tests remove some weird and wrong test logging Cache warning messages and make sure we only log them once
I also realized we don't need to clear the warning cache on-fork on windows because it starts empty
520b647
to
d69dace
Compare
Let's just revert this feature |
Fixes #1389
results
andschemas
to their context.