You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@airflow.apache.org by GitBox <gi...@apache.org> on 2021/09/29 06:55:12 UTC

[GitHub] [airflow] MatrixManAtYrService commented on pull request #17405: Add XCom.clear so it's hookable in custom XCom backend

MatrixManAtYrService commented on pull request #17405:
URL: https://github.com/apache/airflow/pull/17405#issuecomment-929890018


   I see that `XCom.clear` has parameters that let you know what you're clearing (`dag_id`, `task_id`, `execution_date`).  When I set out to implement a custom backend, I totally expected these--so I'm glad they're here ❤️ .
   
   What confuses me is that [the recommended approach for custom xcom backends ](https://airflow.apache.org/docs/apache-airflow/stable/concepts/xcoms.html#custom-backends) is to override `serialize_value` and `deserialize_value`, and those **don't** have parameters of that sort.
   
   So when I'm "serializing" a value, I don't know which task it's for.  I have to do something like generate a UUID or a hash of the data or something to come up with a key that won't collide with other values (this key is then used to recover the stored value while "deserializing").   So if I later want to clear that value, I can't distinguish it from its neighbors which I shouldn't clear.
   
   Am I missing something?  Or does inviting users to implement `clear` put them in a challenging place re: how they implement the other two functions?


-- 
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: commits-unsubscribe@airflow.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org