bolkedebruin commented on PR #32319:
URL: https://github.com/apache/airflow/pull/32319#issuecomment-1826883406

   Hey @Joffreybvn thanks for responding and apologies for being late to the 
game and being a bit rough. It isn't required to return the same during 
deserialization as is provided through serialization. In other words it is fine 
if you serialize a `pyodbc.Row` and deserialize to a `NamedTuple`. 
   
   @potiuk All XCom serialization and deserialization goes through `serde.py`. 
So if you put something into XCom and you want to have it returned it goes 
through there. The original issue's stack trace said:
   
   ```
   Traceback (most recent call last):
     File "/opt/app-root/lib64/python3.9/site-packages/airflow/utils/json.py", 
line 91, in default
       return serialize(o)
     File 
"/opt/app-root/lib64/python3.9/site-packages/airflow/serialization/serde.py", 
line 171, in serialize
       raise TypeError(f"cannot serialize object of type {cls}")
   TypeError: cannot serialize object of type <class 'pyodbc.Row'>
   ```
   
   By dropping a serializer/deserializer into serializers for `pyodbc.Row` (and 
one for DataBricks maybe) this could have been fixed. `_make_serializable` 
seems to create an intermediate format at the moment which imho seems 
unnecessary.
   
   BUT if you intention is to have a **common** "flattened" format, that by 
specification is serializable by the backend (not just JSON btw), then a 
renaming of the method might make sense. Then maybe the solution is then 
renaming the method and changing the description of the method 
`_make_serializable`.
   
   I realize that I might be overzealous and misreading due to all the 
'serialize' here, but I did not see any consideration going into implementing 
this in the framework that is available for this (`serde`). My question is can 
this not be solved a lot simpler and without the need for a change to the 
Operators. `serde` handles XCom for you. Why is the common `_make_serializable` 
method required?
   
   
   


-- 
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]

Reply via email to