Taragolis commented on PR #35844: URL: https://github.com/apache/airflow/pull/35844#issuecomment-1826743579
There is couple of solution already exists, note this not end of list, I believe there is also exist couple solution, so this list not final **Solution 1**: one of the, is Jinja templates, some complex better to solve with `params`, d not to be confused with `parameters`, and files instead of single string. **Solution 2**: As I mentioned XCom via upstream task, usual Python Operator / task flow **Solution 3**: Custom operator **Solution 4**: Task Flow operator + Hook --- What I don't like about the PR's proposed solution: limited only for one field in one of operator and there is no arguments / context provided to the callable itself. However if add additional parameters and context there would be no different with python operator. There also was attempt to add this approach to new LLM based providers, however final decision was use builtin Airflow abilities instead of additional 3 parameters for replace one argument. --- One benefit with callable in Operator if compare to put/get result via XCom and upstream task, is has less overhead for create new task, which usually depend on Executor type. But in this case I think better resolve it globally rather than on one specific operator. For example it could be some specific type, which would call callable during rendering fields, e.g. same approach as implemented for [LiteralValue](https://github.com/apache/airflow/pull/35017) -- 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]
