-
Notifications
You must be signed in to change notification settings - Fork 14.3k
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
Apache Airflow SqlSensor DbApiHook Error #25274
Comments
Thanks for opening your first issue here! Be sure to follow the issue template! |
Please use the "Common-sql" sensor for that. Instead of This is one of the unforeseen effects of "common-sql" introduction. Unfortunately, other than documenting it, we cannot do much about it. Please let me know @vlcheong if it fixed your problem. if it does, I will make sure to add appropriate documentation about it. |
Mybe I will find another solution for that in the future as well - I will think and dig a bit deeper. |
Yeah. I found a solution that will make it works also if you use legacy SqlSensor (will be released in the next common.sql provider) |
See #25293 |
The legacy Airflow SqlSensor, rejects working wiht comon.sql providers eve if they are perfectly fine to use. While users could switch to the common.sql sensor (and it should work fine). we should not force the users to switch to it. We are implementing "fake" class hierarchy in case the provider is installed on Airflow 2.3 and below. In case of Airflow 2.4+ importing the old DbApiHook will fail, because it will cause a circular import - in such case our new DbApiHook will derive (as it was originally planned) from BaseHook. But In case of Airflow 2.3 and below such import will succeed and we are using the original DbApiHook from airflow.hooks.dbapi as base class - this way any "common.sql" hook on Airflow 2.3 and below will also derive from the airlfow.hooks.dbapi.DbApiHook - thus it will be possible to use it by the original SqlSensor. Fixes: apache#25274
The legacy Airflow SqlSensor, rejects working wiht comon.sql providers eve if they are perfectly fine to use. While users could switch to the common.sql sensor (and it should work fine). we should not force the users to switch to it. We are implementing "fake" class hierarchy in case the provider is installed on Airflow 2.3 and below. In case of Airflow 2.4+ importing the old DbApiHook will fail, because it will cause a circular import - in such case our new DbApiHook will derive (as it was originally planned) from BaseHook. But In case of Airflow 2.3 and below such import will succeed and we are using the original DbApiHook from airflow.hooks.dbapi as base class - this way any "common.sql" hook on Airflow 2.3 and below will also derive from the airlfow.hooks.dbapi.DbApiHook - thus it will be possible to use it by the original SqlSensor. Fixes: #25274
Apache Airflow version
2.3.3 (latest released)
What happened
I trying to make SqlSensor to work with Oracle database, I've installed all the required provider and successfully tested the connection. When I run SqlSensor I got this error message
ERROR - Failed to execute job 32 for task check_exec_date (The connection type is not supported by SqlSensor. The associated hook should be a subclass of
DbApiHook. Got OracleHook; 419)
What you think should happen instead
No response
How to reproduce
No response
Operating System
Ubuntu 20.04.4 LTS
Versions of Apache Airflow Providers
apache-airflow-providers-common-sql==1.0.0
apache-airflow-providers-ftp==3.0.0
apache-airflow-providers-http==3.0.0
apache-airflow-providers-imap==3.0.0
apache-airflow-providers-oracle==3.2.0
apache-airflow-providers-postgres==5.1.0
apache-airflow-providers-sqlite==3.0.0
Deployment
Other
Deployment details
Run on Windows Subsystem for Linux
Anything else
No response
Are you willing to submit PR?
Code of Conduct
The text was updated successfully, but these errors were encountered: