Skip to content

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

Merged
merged 53 commits into from
Aug 14, 2024

Conversation

LucaCappelletti94
Copy link
Contributor

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

@alamb
Copy link
Contributor

alamb commented Jul 25, 2024

fyi @lovasoa

@coveralls
Copy link

coveralls commented Jul 25, 2024

Pull Request Test Coverage Report for Build 10372520650

Details

  • 447 of 505 (88.51%) changed or added relevant lines in 5 files are covered.
  • 1 unchanged line in 1 file lost coverage.
  • Overall coverage decreased (-0.005%) to 89.047%

Changes Missing Coverage Covered Lines Changed/Added Lines %
src/ast/data_type.rs 0 1 0.0%
src/ast/mod.rs 40 48 83.33%
src/ast/trigger.rs 29 39 74.36%
src/parser/mod.rs 101 120 84.17%
tests/sqlparser_postgres.rs 277 297 93.27%
Files with Coverage Reduction New Missed Lines %
src/ast/mod.rs 1 81.58%
Totals Coverage Status
Change from base Build 10370172981: -0.005%
Covered Lines: 28082
Relevant Lines: 31536

💛 - Coveralls

@git-hulk
Copy link
Member

git-hulk commented Jul 26, 2024

@LucaCappelletti94 Would you mind fixing format issues and test failures found in CI?

@LucaCappelletti94
Copy link
Contributor Author

Yeah, will get started shortly.

@LucaCappelletti94
Copy link
Contributor Author

@alamb, @git-hulk I need another GitHub Action run to be approved please.

@git-hulk
Copy link
Member

cc @alamb


#[test]
fn parse_create_trigger() {
for referencing in [
Copy link
Contributor

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.

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"
Copy link
Contributor

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...

Copy link
Contributor Author

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.

Copy link
Contributor Author

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.

Copy link
Contributor

@lovasoa lovasoa Jul 30, 2024

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 fors 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));

Copy link
Contributor Author

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.

Copy link
Contributor

@lovasoa lovasoa Jul 31, 2024

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.

Copy link
Contributor Author

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.

Comment on lines 1 to 177
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,
)
}
}
Copy link
Contributor

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.

Copy link
Contributor Author

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.

Copy link
Contributor

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.

@alamb

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok!

Copy link
Contributor

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)

Copy link
Contributor

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

Copy link
Contributor Author

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.

@LucaCappelletti94
Copy link
Contributor Author

I am not sure why the linter screams about that trait, it is definitely being used.

@lovasoa
Copy link
Contributor

lovasoa commented Aug 9, 2024

@LucaCappelletti94 , it doesn't seem to be used in tests/test_utils/mod.rs where it's imported

Copy link
Contributor

@lovasoa lovasoa left a 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 !

Copy link
Contributor

@alamb alamb left a 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

@@ -4442,6 +4442,184 @@ fn test_table_unnest_with_ordinality() {
}
}

fn possible_trigger_referencing_variants() -> Vec<Vec<TriggerReferencing>> {
Copy link
Contributor

@alamb alamb Aug 13, 2024

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!

Copy link
Contributor Author

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.

@alamb
Copy link
Contributor

alamb commented Aug 13, 2024

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

@alamb
Copy link
Contributor

alamb commented Aug 13, 2024

I plan to wait a day or two so @iffyio has time to review if they would like prior to merge

Copy link
Contributor

@iffyio iffyio left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@alamb alamb merged commit b072ce2 into apache:main Aug 14, 2024
10 checks passed
@alamb
Copy link
Contributor

alamb commented Aug 14, 2024

Thanks again everyone -- this was some nice teamwork

ayman-sigma pushed a commit to sigmacomputing/sqlparser-rs that referenced this pull request Nov 19, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants