-
Notifications
You must be signed in to change notification settings - Fork 14.5k
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
Adding generic SqlToSlackOperator #24663
Conversation
Co-authored-by: eladkal <[email protected]>
Co-authored-by: eladkal <[email protected]>
ad4159c
to
4f67dc1
Compare
Rebased to fix selective check problem from #24665 after it's merged. |
@alexkruc please check test failures |
…ow into add_sql_to_slack_operator
Just an idea: #24660 (comment) make sending to slack more generic Might be some side effect and multiple inheritance required in some cases or not. |
@eladkal let's keep track here
I would suggest more generic way, If we have something that I mentioned before: base class in slack-provider It could help to build not only |
Additional benefits you need to test implementation how actually works part with sending DataFrame in If any bugs appear in slack part, we need need to fix it Again, just an idea and I only talk about benefits without negative part of this idea. |
yes we can, but this is a further enhancement. If alex wants to handle this as well he is more than welcome :) |
Totally agree that it should be further enhancement, otherwise it easily took ages to implements SqlToSlackOperator, and deprecate in Snowflake and Presto. I will look on this PR more close on Monday. Probably I would suggest something that I've already found during SnowflakeToSlack enhancement. |
'webhook_token' attribute needs to be specified in the 'Extra' JSON field against the slack_conn_id.py | ||
Mutually exclusive with 'slack_conn_id' |
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.
webhook_token
in Extra marked as Deprecated
airflow/airflow/providers/slack/hooks/slack_webhook.py
Lines 103 to 111 in b678dc2
extra = conn.extra_dejson | |
web_token = extra.get('webhook_token', '') | |
if web_token: | |
warnings.warn( | |
"'webhook_token' in 'extra' is deprecated. Please use 'password' field", | |
DeprecationWarning, | |
stacklevel=2, | |
) |
def _get_hook(self) -> DbApiHook: | ||
self.log.debug("Get connection for %s", self.sql_conn_id) | ||
conn = BaseHook.get_connection(self.sql_conn_id) | ||
hook = conn.get_hook(hook_params=self.sql_hook_params) |
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.
@potiuk need your advise on this one.
The hook_params
was added in #18718 / #19849 which were released on 2.3.0
The Slack provider min version is 2.2.0 so I think this code line should have cause failures?
2.2.0:
https://github.com/apache/airflow/blob/2.2.0/airflow/models/connection.py#L292
2.3.0:
https://github.com/apache/airflow/blob/2.3.0/airflow/models/connection.py#L321
I wonder how it make sense that the CI is green?
@alexkruc in any case we don't need the hook_params
here.. the goal is just to check if the hook has the needed function, the user params are not required for that.
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.
@alexkruc I think we have two options here.
- backport the
get_hook
function into the operator code (temporarily, we will remove it once the provider will be Airflow>=2.3 compatible) - Leave the
PrestoToSlackOperator
SnowflakeToSlackOperator
code as is with just a deprecation warning, in that solution we should also check Airflow version when using the operator as it works only with 2.3 (you can checkfrom airflow.version import version
)
I think option 1 is prefered as otherwise it means only users of Airflow>=2.3 will be able to use this new operator.
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.
Yep. 1) is preferred.
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.
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.
Reader as in myself? ;)
I'll take a look, will love to get familiar a bit with the pre-commit flow :)
I'll update here if I'll get stuck or something.
I just thought that checking for versions and matching will be easier to read for future operator maintainers, and also it's easier to deprecate later (just remove the if block), I think that using the generic methods (as in conn.get_hook(hook_params=....)
) as much as possible is the better way here :)
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.
Cool! That's what I meant. One small NIT: since you made a "generic" exclusion - let's make it # ignore airflow compat check
, We have some 2.2, some 2.3 and some 2.4 checks already foreseen to be there for quite some time.
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.
BTW. Pre-comits are SUPER easy :D
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! thanks for the comment :) I changed it here - efd07a5
BTW. Pre-comits are SUPER easy :D
I agree! and besides being easy, they are also kinda fun 😄 The thing is, that as a user, and as a young contributor, I'm not often exposed to this, so it's nice learning something new about the Airflow eco-system ;)
# For supporting Airflow versions < 2.3, we backport "get_hook()" method. This should be removed | ||
# when "apache-airflow-providers-slack" will depend on Airflow >= 2.3. Git reference: | ||
# https://github.com/apache/airflow/blob/main/airflow/providers/slack/provider.yaml#L38 | ||
hook = _backported_get_hook(conn) |
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.
Shouldn't we pass the sql_hook_params
as well? this is the whole reason for backporing the function isn't it?
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.
your'e right :) fixed it :)
…ow into add_sql_to_slack_operator
Co-authored-by: eladkal <[email protected]>
Co-authored-by: eladkal <[email protected]>
Needs rebase :( |
…ow into add_sql_to_slack_operator
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.
LGTM
This PR is adding a generic
SqlToSlackOperator
, meaning everything that usesDbApiHook
and implementsget_pandas_df
will now be able to send the results to Slack.As part of this PR, I've also deprecated the current
PrestoToSlackOperator
andSnowflakeToSlackOperator
- they now inherit fromSqlToSlackOperator
.closes: #24243
reference: existing
PrestoToSlackOperator
andSnowflakeToSlackOperator
, and the genericSqlToS3Operator
.