-
-
Notifications
You must be signed in to change notification settings - Fork 755
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
Rough autofix for L028 #2757
Rough autofix for L028 #2757
Conversation
Codecov Report
@@ Coverage Diff @@
## main #2757 +/- ##
=========================================
Coverage 100.00% 100.00%
=========================================
Files 163 163
Lines 12232 12264 +32
=========================================
+ Hits 12232 12264 +32
Continue to review full report at Codecov.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not had too much of a look at the code, as I've a more fundamental question on the new attribute and whether it's even needed.
Love the fact you support STRUCTS
now for this rule!
fail_str: SELECT bar FROM my_tbl WHERE foo | ||
fix_str: SELECT my_tbl.bar FROM my_tbl WHERE my_tbl.foo |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ohh interesting that it affects WHERE
clause too! Did it always do that? Do we need a simple "pass" test for that?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is some clever stuff about managing self references in certain dialects.
Redshift can ref a created column.
That said
SELECT
a,
b,
a + b AS col_created_right_here,
col_created_right_here + 1 AS sub_self_ref
FROM tbl
Is also valid in Redshift, Snowflake and BQ
So.....
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ahhh that actually could be quite a large problem.
SELECT
tbl.a,
tbl.b,
tbl.a + tbl.b AS col_created_right_here,
col_created_right_here + 1 AS sub_self_ref -- noqa: disable=L028
FROM tbl
This noqa: is very much intentional (I normally want qualified but this is actually a self ref and I know it), will it be correctly respected ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we recently discovered that noqa
doesn't work in the YAML files.
My original comment was we have a fail
and fix
test case for WHERE
reference, but no pass
test case. Should we have one? In theory fail
/fix
should be sufficient but I always like to have a pass
test case in these instances too.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Still wonder if we should have a simple pass_str
test for this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Re: noqa
in YAML tests. This should now work correctly for the usual YAML tests (test/rules/yaml_test_cases_test.py::test__rule_test_case
). Until recently, pass
tests used a weird code path that skipped parts of the linter. As of a couple weeks ago, everything should work.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ill add a test for this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Test added. for fail and pass w/ noqa.
Later I'd like to revisit this / make another rule for lateral column references - they cause huge problems.
Rule like lateral self references must begin with __self_
then there would be some interaction with this and other rules.
@OTooleMichael what's your thoughts on this change and v0.11.0? Think we're ready to go on that but happy to hold off if you think you'll get this finished out in next day or so? |
More
I'll fix this in under 12 hours from now. |
Cool. Will hold off for this then. And that other one! |
e879234
to
ef74a8d
Compare
This should be ready |
00f287b
to
1c06f0c
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks pretty good to me now, but have some more comments for you.
@barrywhart could you give it a review too since you know the rules code better than me.
src/sqlfluff/rules/L028.py
Outdated
structs which trigger false positives. It can be enabled with the | ||
``force_enable = True`` flag. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since you now support structs in this rule do we still need this note?
And the force_enable
flag?
Also nit but if keeping it, can we update text to "This rule is disabled by default for BigQuery, Hive and Redshift due to their use of"
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To what should we change the text?
I'd probably leave force enabled flag for now (issue for a bigger release) its a more serious change that could be breaking and probably outside the thought level I can give this before pushing out 0.11.1
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sounds good.
At the moment the text just mentions BigQuery, but it's three dialects this affects so think we should mention the other two: "This rule is disabled by default for BigQuery, Hive and Redshift due to their use of..."
Or alternatively should say "This rule is disabled by default for dialects like BigQuery due to their use of..." to avoid having to keep it in sync in future, but do think listing all three is more friendly to users.
fail_str: SELECT bar FROM my_tbl WHERE foo | ||
fix_str: SELECT my_tbl.bar FROM my_tbl WHERE my_tbl.foo |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Still wonder if we should have a simple pass_str
test for this?
6acc997
to
60cb096
Compare
This adds fixing L028
However L028 is maybe flawed from the bottom up? The changes are subject to opinion and maybe not all are wanted/needed
fix_inconsistent_to
setting for fix inconsistent to either unqualified or qualified when encountereda.struct_value FROM tbl_name
must be a struct asa
is not the table reference. If a is intended to be the table this code will not run. If we assume its valid code and "fix" it, it will not change its runnableness (valid code will remain valid [but now linted], in valid code will remain invalid).fix_inconsistent_to
also works on struct dialectSELECT schema.table.col1, table.col2 FROM schema.table
is consistent and qualified.Are there any other side effects of this change that we should be aware of?
Fixes catches and understands structs better but also differently.
Pull Request checklist
Please confirm you have completed any of the necessary steps below.
Included test cases to demonstrate any code changes, which may be one or more of the following:
.yml
rule test cases intest/fixtures/rules/std_rule_cases
.Notes:
references = list(sc.recursive_crawl("object_reference"))
have methods likeis_qualified
but are typed asList[BaseSegment]
. We can't run any sensible guard statement likeassert isintanceof(ref, (A,B,C))
causeObjectRefs
are reimplmented in various dialects directly fromBaseSegment
Rule_L028(Rule_L020)
- in this particular case it serve very little other than to make things hard to read and to make method/call signatures weirdprobably setting up an fn is more reusable. Also on a side note
get_select_statement_info
might be a good candidate for memo'ing