Skip to content
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

Add method 'callproc' on Oracle hook #20072

Merged
merged 3 commits into from
Dec 13, 2021
Merged

Conversation

malthe
Copy link
Contributor

@malthe malthe commented Dec 6, 2021

This adds a new method:

OracleHook.callproc(identifier: str, parameters: Optional[Union[Dict, List]] = None)

(In the actual code, the parameters argument are assigned a type variable ParameterType since the return type of the method is determined by the type of the parameters argument).

The call mirrors the Cursor.callproc() method provided by the driver except:

  1. An alternative mechanism is used to provide OUT parameters; instead of needing the cursor object (which is not available to us using the DB API hook abstraction), the user must instead pass a Python type reference (e.g., int) as the value of the parameter.
  2. The return value is the "unwrapped" bindvars (basically the OUT parameters as you would expect). This follows from (1) since we do not use cursor.var to create a bind variable in the first place.

In addition, an optional procedure argument has been added to OracleOperator. This can be used instead of sql to call a stored procedure directly from the operator.

This functionality builds on #15581.

@malthe malthe changed the title Add method 'call_stored_proc' on Oracle hook Add method 'callproc' on Oracle hook Dec 6, 2021
hook = OracleHook(oracle_conn_id=self.oracle_conn_id)
hook.run(self.sql, autocommit=self.autocommit, parameters=self.parameters)
if self.sql:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think these should be two separate operators- one for running SQL statements and one for calling procedures.

Copy link
Contributor Author

@malthe malthe Dec 6, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@mik-laj it does perhaps make sense considering that autocommit (see also #20085) is disabled in the operator that runs SQL statements while for calling stored procedures – in the context of an Airflow operator – it makes sense to autocommit (given that the stored procedure itself runs inside a subtransaction).

That is, for a stored procedure operator I would have autocommit enabled as the default setting.

(Probably even for the SQL statement operator, but such defaults are not easily changed.)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@mik-laj I have split the functionality now, introducing a new operator OracleStoredProcedureOperator. This always has autocommit enabled – because that's really what makes sense.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants