[X] I have searched the existing issues, and I could not find an existing issue for this feature
[X] I am requesting a straightforward extension of existing dbt-snowflake functionality, rather than a Big Idea better suited to a discussion
Describe the feature
Python models should log to the account's event table like any other stored procedure. Snowflake supports altering the logging level (LOG_LEVEL) at three points. However, there are difficulties with all three of these approaches.
Account level
Setting LOG_LEVEL at the account level requires permissions that are typically not available for many users. It also has the effect of impacting everyone on the account, which is generally not desirable. This is currently the only available workaround.
Object level
Setting LOG_LEVEL on the stored procedure would minimize the impact of the setting change. However, the stored procedure only exists during the dbt run; it's created and then dropped as part of running the model (after pre-hooks and before post-hooks). Since the user has no entry point between the model being created and the model running, they cannot apply these permissions. Additionally, since the default behavior of dbt-snowflake is to use a temporary stored procedure, this approach would only apply to the non-default path.
Session level
Setting LOG_LEVEL for the session feels like the correct approach. This approach supports both the default and the non-default methods for implementing python models. Since the change is bound to the session, it also doesn't affect the state of the warehouse after the dbt run completes. This can be implemented as a pre-hook or it can be added as a one-liner before calling the stored procedure. The pre-hook is something that a user can implement on their own, but it's required overhead.
Who will this benefit?
This benefits dbt-snowflake users who want logging for python models.
Is this your first time submitting a feature request?
Describe the feature
Python models should log to the account's event table like any other stored procedure. Snowflake supports altering the logging level (
LOG_LEVEL) at three points. However, there are difficulties with all three of these approaches.Account level
Setting
LOG_LEVELat the account level requires permissions that are typically not available for many users. It also has the effect of impacting everyone on the account, which is generally not desirable. This is currently the only available workaround.Object level
Setting
LOG_LEVELon the stored procedure would minimize the impact of the setting change. However, the stored procedure only exists during the dbt run; it's created and then dropped as part of running the model (after pre-hooks and before post-hooks). Since the user has no entry point between the model being created and the model running, they cannot apply these permissions. Additionally, since the default behavior ofdbt-snowflakeis to use a temporary stored procedure, this approach would only apply to the non-default path.Session level
Setting
LOG_LEVELfor the session feels like the correct approach. This approach supports both the default and the non-default methods for implementing python models. Since the change is bound to the session, it also doesn't affect the state of the warehouse after the dbt run completes. This can be implemented as a pre-hook or it can be added as a one-liner before calling the stored procedure. The pre-hook is something that a user can implement on their own, but it's required overhead.Who will this benefit?
This benefits
dbt-snowflakeusers who want logging for python models.Additional information
This feature is a result of #846.