-
-
Notifications
You must be signed in to change notification settings - Fork 821
Support identifier clause for Databricks #6377
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
Support identifier clause for Databricks #6377
Conversation
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 you've redefined a couple of objects unnecessarily - otherwise this looks good 👍 .
Thanks for the contribution
class DatabaseReferenceSegment(ObjectReferenceSegment): | ||
"""A reference to a database.""" | ||
|
||
type = "database_reference" | ||
|
||
|
||
class TableReferenceSegment(ObjectReferenceSegment): | ||
"""A reference to an table, CTE, subquery or alias.""" | ||
|
||
type = "table_reference" | ||
|
||
|
||
class SchemaReferenceSegment(ObjectReferenceSegment): | ||
"""A reference to a schema.""" | ||
|
||
type = "schema_reference" |
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 don't think these need redefining? I can't see any edits vs the classess created in the ansi dialect, so no need to redefine. Unless I've missed something?
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.
These were needed to inherit changes to ObjectReferenceSegment
which has been updated, just tested and without these lines the tests fail.
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.
iiiiiineresting. Good catch. Not super helpful from a development point of view, but I guess that's what it is right now.
Thanks for the contribution!
Coverage Results ✅
|
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.
LGTM
Provides support for IDENTIFIER clause.
Brief summary of the change made
Supports IDENTIFIER(string or string expression) in stead of database, schema, table or view names as per [documentation].(https://docs.databricks.com/en/sql/language-manual/sql-ref-names-identifier-clause.html)
Are there any other side effects of this change that we should be aware of?
Not that I am aware of apologies if I have missed something as this is my first PR.
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
..sql
/.yml
parser test cases intest/fixtures/dialects
(note YML files can be auto generated withtox -e generate-fixture-yml
).test/fixtures/linter/autofix
.Added appropriate documentation for the change.
Created GitHub issues for any relevant followup/future enhancements if appropriate.