potiuk commented on issue #51821:
URL: https://github.com/apache/airflow/issues/51821#issuecomment-3715321612
Surely it can:
```pythom
def set_xcom(ti, value):
ti.xcom_push(key="my_xcom", value=value)
def print_xcom(ti, task_id):
logging.info(ti.xcom_pull(key="my_xcom"), task_ids=[task_id])
def print_xcom_task1(ti):
print_xcom(ti, "dag1_task1")
def print_xcom_task2(ti):
print_xcom(ti, "dag2_task1")
with DAG(dag_id="dag_1") as dag_1:
write = PythonOperator(task_id="dag1_task1", value="a",
python_callable=set_xcom)
read = PythonOperator(task_id="print", python_callable=print_xcom_task1)
with DAG(dag_id="dag_2") as dag_2:
write = PythonOperator(task_id="dag2_task1", value="b",
python_callable=set_xcom)
read = PythonOperator(task_id="print", python_callable=print_xcom_task1)
```
This is the beauty of having pythom that you can extract common parts of
what you want to use (DRY) and make a specific call by passing it parameters.
The problem with the use you had before is that it was using and implicit
and ambiguous behaviour that worked "accidentally" - it was not intentional,
had no defined semantics, and it could behave differently depending on database
used, sequence of things executing and the like - your code above is brittle
and is prone to huge problems if you expand the usage to case where one dag can
produce multiple matching tasks - and while it can work in simple cases, it is
(unlike your code that is possible to be modified) to bring it back as a
feature, because it has undefined semantics. We cannot even specify what should
be returned by this call in case of more complex cases, so we simply "cannot"
implement it.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
