-
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
[Oracle] Oracle Hook - make it possible to define a schema in the connection parameters #18664
Comments
Can I pick up this issue? Perhaps using |
would something like this work? https://airflow.apache.org/docs/apache-airflow/stable/howto/connection.html#storing-a-connection-in-environment-variables |
If I understand correctly, you can already access connections in the template. But I think the original request is the hook should automatically set that from the connection (from an agreed-upon extra key). |
The Idea was, to set the schema name in the corresponding field from UI. When Initializing Oracle Hook, the current schema should be automatically set. For example by adding a airflow/airflow/providers/oracle/hooks/oracle.py Lines 134 to 135 in 866a601
|
@mehmax i don't know what a "schema" is in oracle terminology, but in airflow's case this parameter is used to refer to the If you look at these lines of code, airflow/airflow/providers/oracle/hooks/oracle.py Lines 85 to 94 in 866a601
maybe what you're looking for can be achieved by removing the "service_name" extra arg? |
@nikochiko I am no oracle expert, but let me explain it in an example. Please refer to also to this links In my opinion it can be solved by adding the following lines
or (equivalent)
|
@eladkal @uranusjr @nikochiko |
Description
Currently the oracle hook it not setting a CURRENT_SCHEMA after connecting with the Database.
In a lot of use cases we have production and test databases with seperate connections and database schemas e.g. TEST.Table1, PROD.Table1
"Hard-coding" the database schema in SQL Scripts is not elegant due to having different Airflow Instances for developing and Production.
An Option would be to store the database schema in a airflow Variable and getting it into the sql script with JINJA.
In Large SQL files with several tables it is not elegant either, because for every table a query to the metadatabase is made.
Why not using the Schema parameter in the Airflow Connections and executing
ALTER SESSION SET CURRENT_SCHEMA='SCHEMA'
right after successfully connecting to the database?
An alternative would be to use option
Connection.current_schema
of Library cx_Oracle.https://cx-oracle.readthedocs.io/en/6.4.1/connection.html#Connection.current_schema
Use case/motivation
It makes Query development much easier by storing environment attributes directly in the Airflow Connection.
You have full flexibility without touching your SQL Script.
It makes separation of Test and Production environments and connections possible.
Related issues
No response
Are you willing to submit a PR?
Code of Conduct
The text was updated successfully, but these errors were encountered: