ashb commented on code in PR #74858: URL: https://github.com/apache/airflow/pull/74858#discussion_r4307485948
########## airflow-core/docs/core-concepts/xcoms.rst: ########## @@ -106,11 +106,15 @@ The default XCom backend, BaseXCom, stores XComs in the Airflow database, which Custom XCom Backends -------------------- -The XCom system has interchangeable backends, and you can set which backend is being used via the ``xcom_backend`` configuration option. - -If you want to implement your own backend, you should subclass :class:`~airflow.sdk.bases.xcom.BaseXCom`, and override the ``serialize_value`` and ``deserialize_value`` methods. - -You can override the ``purge`` method in the ``BaseXCom`` class to have control over purging the XCom data from the custom backend. This will be called as part of ``delete``. +The XCom system has interchangeable backends, and you can set which backend is being used via the ``xcom_backend`` configuration option. A backend is a subclass of :class:`~airflow.sdk.bases.xcom.BaseXCom`. + +A backend that keeps values outside the metadata database overrides ``store_value``, which receives an +:class:`~airflow.sdk.bases.xcom.XComCoordinate`, stores the value and returns what the XCom row holds, and +``load_value``, which turns that row value back into the value. ``XComCoordinate.build_path`` builds a storage +location that is unique per task instance, or per write when the writer cannot know the task instance. Override +``purge`` to remove the stored data when an XCom is deleted. A backend that only overrides ``serialize_value`` and Review Comment: Yeah, there are a few other cases where objects don't get deleted either (and haven't since XCom backends have been a thing) -- I will loosen the doc string. -- 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]
