Skip generation of write privileges for already-granted <database_or_schema>.* privileges

Merge Request Checklist

  • Link to an issue
  • Include the proposed fix or feature
  • Include and update tests for the modified code
  • Include a documentation change
  • Add an entry in the Unreleased section of the CHANGELOG

This fix ensures that the table_already_granted and view_already_granted variables in the SnowflakeGrantsGenerator._generate_table_write_grants method are set consistently and accurately. This ensures that the generated SQL statements accurately reflect new privileges to grant and do not re-grant existing privileges.

A detailed description of the problem can be found here. As for the fix itself, I used the pattern found later in the method to keep things consistent. I then added a test for this in test_snowflake_grants, which required a small bit of modification so that we had more flexibility in the grants_to_role variable we passed in. (I know there was a note there to not update the grants_to_role fixture but it looked to be compatible with adding an additional role if the existing roles weren't modified. This felt preferable to me versus adding totally new methods with a lot of duplicate code, and all of the tests still pass.)

I discovered an additional bug here, where we were setting view_already_granted to the inverse of what it should be. I believe this had been masked by the fact that TestGenerateTableAndViewGrants had not been checking for the already_granted flag in the output, so I've added that in as well. I verified this by modifying the TestGenerateTableAndViewGrants test first to filter out already_granted SQL commands but not making any changes to how we set view_already_granted. This resulted in a test failure, with the expected output including two grant statements on views but those two statements missing from the actual output.

No documentation update required as this is a bug fix.

Closes #125 (closed).

Edited by William Herrmann

Merge request reports

Loading