-
Notifications
You must be signed in to change notification settings - Fork 59
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
[CT-789] Add Grants to Materializations #212 #131
Conversation
@cla-bot check |
The cla-bot has been summoned, and re-checked this pull request! |
my_snapshot_sql = """ | ||
{% snapshot my_snapshot %} | ||
{{ config( | ||
check_cols='all', unique_key='id', strategy='check', | ||
target_database=database, target_schema=schema | ||
) }} | ||
select 1 as id, cast('blue' as {{ type_string() }}) as color | ||
{% endsnapshot %} | ||
""".strip() |
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 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.
Optionally, we could add this (slightly) more verbose version to dbt-core.
On that note, is there syntax for type-casting that we could enable for core + adapters?
I'd prefer less verbose syntax like this:
select 1 as id, {{ cast_string('blue') }} as color
over this:
select 1 as id, cast('blue' as {{ type_string() }}) as color
The former would also allow some adapters to render more pithy SQL like:
'blue'::text
rather than:
cast('blue' as text)
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.
@dbeatty10 I think we could add a cross-db {{ cast() }}
macro to dbt-core
, which returns column::type
where it's supported, or cast(column as type)
otherwise / by default.
For now, I did the simpler version in dbt-labs/dbt-core@7f499ba
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.
Awesome, I'll try the relevant update and see if it works.
Rerunning CI to account for changes in dbt-labs/dbt-core@c763601. I don't believe any code changes here are needed. |
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 work @dbeatty10
* Use development branch of dbt-core [skip ci] * Adapter-specific macro to show grants / get a list of table privileges from Redshift * Replace with tests that exist * Inherit functional tests for grants * Align `privilege_type` nomenclature with postgres adapter * Add new environment variables to CI * Add new environment variables to CI * Try hard-coded user names * Remove adapter-specific implementation of `get_revoke_sql` * Covert hard-code env vars to pull from GitHub secrets instead * Plain text rather than repo secrets * Filter out grants to the current user * Switch to branch with more tests [skip ci] * Ignore super users * Replace untyped constant with an explicit typed constant * Remove extraneous `pass` * Update CHANGELOG [skip ci] * Fix CHANGELOG [skip ci] * Inherit default tests * Update development branch * Point back to main branch for dbt-core
resolves #128
Description
Includes the tests in:
Todo before merge
DBT_TEST_USER_*
environment variables from secretsdev-requirements.txt
Checklist
CHANGELOG.md
and added information about my change to the "dbt-redshift next" section.