-
Notifications
You must be signed in to change notification settings - Fork 605
Adding support for parsing CREATE TRIGGER and DROP TRIGGER statements #1352
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
Conversation
fyi @lovasoa |
Pull Request Test Coverage Report for Build 10372520650Details
💛 - Coveralls |
@LucaCappelletti94 Would you mind fixing format issues and test failures found in CI? |
Yeah, will get started shortly. |
cc @alamb |
tests/sqlparser_postgres.rs
Outdated
|
||
#[test] | ||
fn parse_create_trigger() { | ||
for referencing in [ |
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.
The combinatorial loop is primarily the source of complexity in my mind and would ideally be flattened in order to simplify it.
Co-authored-by: Ifeanyi Ubah <[email protected]>
… table name in CREATE TRIGGER
Cargo.toml
Outdated
@@ -40,6 +40,7 @@ sqlparser_derive = { version = "0.2.0", path = "derive", optional = true } | |||
simple_logger = "5.0" | |||
matches = "0.1" | |||
pretty_assertions = "1" | |||
itertools = "0.13" |
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'm not a huge fan of adding a new dependency...
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.
It was either that or a much uglier Cartesian product. I agree that I would prefer to not add dependencies, but I was asked to try and clean the combinatorial for loop used to test the CREATE TRIGGER statement. I thought that with this being a dev-dependency
of a well-known crate, it may be okay. Do let me know which other solution you would prefer to go for.
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.
In the meantime, I will rewrite it without the use of itertools. Do let me know which variant you prefer.
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.
@iffyio might disagree, but I think the nested for
s are clearer than the itertools version.
The various arrays should be defined separately, but then I have not problem with
for var1 in arr1 {
for var2 in arr2 {
for var3 in arr3 {
assert!(some_function(var1, var2, var3));
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 have removed the itertools dependency and tried to make a version as clean as possible in commit d8db70e. Do let me know your opinion.
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 would have written nested for loops, but I think your version is okay.
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.
Ok! I find the flattened for-loops a bit easier to read, as otherwise, it gets to a very high level of indentation. Do let me know whether you have any more notes on the PR.
tests/test_utils/extend_tuple.rs
Outdated
fn extend_tuple(self, to_extend: (T1, T2, T3, T4, T5, T6, T7)) -> Self::Output { | ||
( | ||
to_extend.0, | ||
to_extend.1, | ||
to_extend.2, | ||
to_extend.3, | ||
to_extend.4, | ||
to_extend.5, | ||
to_extend.6, | ||
self, | ||
) | ||
} | ||
} | ||
|
||
impl<T1, T2, T3, T4, T5, T6, T7, T8, T9> ExtendTuple<(T1, T2, T3, T4, T5, T6, T7, T8)> for T9 { | ||
type Output = (T1, T2, T3, T4, T5, T6, T7, T8, T9); | ||
|
||
fn extend_tuple(self, to_extend: (T1, T2, T3, T4, T5, T6, T7, T8)) -> Self::Output { | ||
( | ||
to_extend.0, | ||
to_extend.1, | ||
to_extend.2, | ||
to_extend.3, | ||
to_extend.4, | ||
to_extend.5, | ||
to_extend.6, | ||
to_extend.7, | ||
self, | ||
) | ||
} | ||
} | ||
|
||
impl<T1, T2, T3, T4, T5, T6, T7, T8, T9, T10> ExtendTuple<(T1, T2, T3, T4, T5, T6, T7, T8, T9)> | ||
for T10 | ||
{ | ||
type Output = (T1, T2, T3, T4, T5, T6, T7, T8, T9, T10); | ||
|
||
fn extend_tuple(self, to_extend: (T1, T2, T3, T4, T5, T6, T7, T8, T9)) -> Self::Output { | ||
( | ||
to_extend.0, | ||
to_extend.1, | ||
to_extend.2, | ||
to_extend.3, | ||
to_extend.4, | ||
to_extend.5, | ||
to_extend.6, | ||
to_extend.7, | ||
to_extend.8, | ||
self, | ||
) | ||
} | ||
} | ||
|
||
impl<T1, T2, T3, T4, T5, T6, T7, T8, T9, T10, T11> | ||
ExtendTuple<(T1, T2, T3, T4, T5, T6, T7, T8, T9, T10)> for T11 | ||
{ | ||
type Output = (T1, T2, T3, T4, T5, T6, T7, T8, T9, T10, T11); | ||
|
||
fn extend_tuple(self, to_extend: (T1, T2, T3, T4, T5, T6, T7, T8, T9, T10)) -> Self::Output { | ||
( | ||
to_extend.0, | ||
to_extend.1, | ||
to_extend.2, | ||
to_extend.3, | ||
to_extend.4, | ||
to_extend.5, | ||
to_extend.6, | ||
to_extend.7, | ||
to_extend.8, | ||
to_extend.9, | ||
self, | ||
) | ||
} | ||
} | ||
|
||
impl<T1, T2, T3, T4, T5, T6, T7, T8, T9, T10, T11, T12> | ||
ExtendTuple<(T1, T2, T3, T4, T5, T6, T7, T8, T9, T10, T11)> for T12 | ||
{ | ||
type Output = (T1, T2, T3, T4, T5, T6, T7, T8, T9, T10, T11, T12); | ||
|
||
fn extend_tuple( | ||
self, | ||
to_extend: (T1, T2, T3, T4, T5, T6, T7, T8, T9, T10, T11), | ||
) -> Self::Output { | ||
( | ||
to_extend.0, | ||
to_extend.1, | ||
to_extend.2, | ||
to_extend.3, | ||
to_extend.4, | ||
to_extend.5, | ||
to_extend.6, | ||
to_extend.7, | ||
to_extend.8, | ||
to_extend.9, | ||
to_extend.10, | ||
self, | ||
) | ||
} | ||
} |
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.
This is, in my opinion, worse than a bunch of nested for loops... But I wonldn't prevent merging over that. I think this PR is ok.
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.
Yeah, these are quite ugly - I can wrap them in macros to remove at least the redundancy.
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 feel like that would be worth it. A few nested for loops are better than :
- adding a new dependency
- creating a new trait that will be used just in one test case
- creating a new trait AND a macro to implement that trait
We are talking about a single test. No need to overcomplicate things.
Even the principle of testing all possible combinations of syntaxes sounds a bit overkill to me.
I don't think we should delay merging that PR for longer. I would have preferred simpler tests, but the current state is okay. We can merge this now, I think.
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.
Ok!
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'm not in favor of merging this (I think its too much machinery/code for a test case). The previous version with the combinatorial for loops I'd rather not either but I don't feel as strongly against merging that one at least so I'm defo OK with doing that if everyone's fine with it. (doesn't mean we can't merge this either ofc, merely my preference)
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 agree with @iffyio
Let's keep the code / tests simpler even if it reuires some additional redundancy
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 have replaced the complete CreateTrigger test suite with some selected test cases in commit 459dae1, as I believe the request was. I am not sure whether this was what was requested.
I am not sure why the linter screams about that trait, it is definitely being used. |
@LucaCappelletti94 , it doesn't seem to be used in tests/test_utils/mod.rs where it's imported |
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.
great, good for me !
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.
Thank you @LucaCappelletti94 @git-hulk @lovasoa and @iffyio
This is one of the most well documented PRs I have seen in a long time.
I have one more question about some dead looking code, but I also think we could remove this as a follow on PR
tests/sqlparser_postgres.rs
Outdated
@@ -4442,6 +4442,184 @@ fn test_table_unnest_with_ordinality() { | |||
} | |||
} | |||
|
|||
fn possible_trigger_referencing_variants() -> Vec<Vec<TriggerReferencing>> { |
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 functions don't seem to be used anywhere 🤔 I would have expected clippy to complain about unused code
Update; it did!
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.
Dead code removed, I am not sure why clippy didn't say anything.
I took the liberty of merging up from main and pushing a small test fix to this branch 0182a50 -- I also think that by doing so the CI should run automatically on this PR from now on |
I plan to wait a day or two so @iffyio has time to review if they would like prior to merge |
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.
Thanks @LucaCappelletti94!
Thanks again everyone -- this was some nice teamwork |
…apache#1352) Co-authored-by: hulk <[email protected]> Co-authored-by: Ifeanyi Ubah <[email protected]> Co-authored-by: Andrew Lamb <[email protected]>
This pull request starts from what was left off from this other closed pull request from two years ago. @zidaye had already made a considerable effort, I have primarily updated the PR so that it works with the code base two years later and extended the testing for its methods.
Looking forward to see it merged so I may be able to add support for TRIGGER in GlueSQL