[
https://issues.apache.org/jira/browse/AIRFLOW-915?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17002333#comment-17002333
]
Paul Rhodes commented on AIRFLOW-915:
-------------------------------------
This is a very old card, but is still very relevant to people who tend to use
custom operators a lot.
I would suggest that any change to the pre_execute() endpoint is likely to
result in some of the existing operators exhibiting new behaviours. An
alternate approach would be to introduce a pre_render() method
(which by default does 'pass' in BaseOperator) to allow for context changes to
be ring fenced.
The the task_instance.py code might look something like this:
{code:java}
task_copy.pre_render(context=context)
self.render_templates(context=context)
task_copy.pre_execute(context=context) {code}
> Allow task context to be modified by pre_execute hook
> -----------------------------------------------------
>
> Key: AIRFLOW-915
> URL: https://issues.apache.org/jira/browse/AIRFLOW-915
> Project: Apache Airflow
> Issue Type: Improvement
> Components: operators
> Affects Versions: 1.8.0
> Reporter: Jeremiah Lowin
> Priority: Minor
>
> Currently, Operators do two things that prevent the pre_execute hook from
> modifying the jinja context:
> 1. the Operator templates are rendered immediately BEFORE calling pre_execute
> 2. even though a context was already generated for the operator, the context
> is regenerated for template rendering, meaning that modifications to the
> operator context wouldn't matter anyway.
> The proper course of events should be:
> 1. generate operator context
> 2. pass context to pre_execute where it could (potentially) be modified
> 3. use that context to render operator templates
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
