-
Notifications
You must be signed in to change notification settings - Fork 505
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
Star macro is not supporting SQLFluff when columns are not present #802
Comments
Would it be possible to prioritize this issue? It's causing problems in our slim CI setting, where the |
FYI I have been able to force sqlfluff to have a "compile" flag by adding the following line in this file from sqlfluff: which: Optional[str] = "compile" The class would be: # From sqlfluff-templater-dbt/sqlfluff_templater_dbt/templater.py
@dataclass
class DbtConfigArgs:
"""Arguments to load dbt runtime config."""
project_dir: Optional[str] = None
profiles_dir: Optional[str] = None
profile: Optional[str] = None
target: Optional[str] = None
threads: int = 1
single_threaded: bool = False
# dict in 1.5.x onwards, json string before.
vars: Optional[Union[Dict, str]] = None if DBT_VERSION_TUPLE >= (1, 5) else ""
which: Optional[str] = "compile" With this I am able to get this output: I may open an issue on SQLFluff to understand if this is normal that we do not set the [EDIT] We have the flag.WHICH = run because in this sqlfluff file, from the dbt_templater that defines the flags used in the templater, it calls the function # From dbt-core/core/dbt/flags.py
def set_from_args(args: Namespace, user_config):
global GLOBAL_FLAGS
from dbt.cli.main import cli
from dbt.cli.flags import Flags, convert_config
# we set attributes of args after initialize the flags, but user_config
# is being read in the Flags constructor, so we need to read it here and pass in
# to make sure we use the correct user_config
if (hasattr(args, "PROFILES_DIR") or hasattr(args, "profiles_dir")) and not user_config:
from dbt.config.profile import read_user_config
profiles_dir = getattr(args, "PROFILES_DIR", None) or getattr(args, "profiles_dir")
user_config = read_user_config(profiles_dir)
# make a dummy context to get the flags, totally arbitrary
ctx = cli.make_context("run", ["run"]) ----------> HERE
flags = Flags(ctx, user_config)
for arg_name, args_param_value in vars(args).items():
args_param_value = convert_config(arg_name, args_param_value)
object.__setattr__(flags, arg_name.upper(), args_param_value)
object.__setattr__(flags, arg_name.lower(), args_param_value)
GLOBAL_FLAGS = flags # type: ignore The line # make a dummy context to get the flags, totally arbitrary
ctx = cli.make_context("run", ["run"]) set a dummy context with a run CLI command which causes the |
Thanks for investigating, @moreaupascal56! I've subscribed to sqlfluff/sqlfluff#4965 as well. |
hey @katieclaiborne, it should be good with the new release of sqlfluff (version 2.1.3). If you can confirm on an your side it would be perfect :) |
Done! I rendered a previously failing model with the new version of SQLFluff, and confirmed that the star macro was indeed following the happy path. The model now also passes
Thanks for your work on this, @moreaupascal56! I will close the issue. |
Describe the bug
Based on @vperron's investigation in #732, it appears that SQLFluff is not following the flags.WHICH == 'compile' path in the star macro, which is intended to keep it happy when
get_filtered_columns_in_relation
returns no columns.Instead, SQLFluff's rendered query follows the star macro's else condition, which results in a parsing error.
Steps to reproduce
See @dbeatty10's comment here.
Expected results
We expected the macro to return the
*
in line 19.Actual results
Instead, it returns the comment in line 26.
Screenshots and log output
See Doug's comment.
System information
The contents of your
packages.yml
file:Which database are you using dbt with?
The output of
dbt --version
:Additional context
Doug suggested that we coordinate with SQLFluff maintainers on a path forward.
If I had to guess, I'd say that means understanding the actual value of
flags.WHICH
in this scenario, then updating the star macro and/or SQLFluff's behavior to produce the safe output.Are you interested in contributing the fix?
Yes, although I'd likely need some hand-holding!
The text was updated successfully, but these errors were encountered: