Deserialize pickles in a asyncio executor + converted db functions reader() and IWriter.serialize() to async#1171
Deserialize pickles in a asyncio executor + converted db functions reader() and IWriter.serialize() to async#1171
Conversation
Codecov Report
@@ Coverage Diff @@
## master #1171 +/- ##
========================================
+ Coverage 94.6% 94.6% +0.1%
========================================
Files 377 377
Lines 32650 32658 +8
========================================
+ Hits 30873 30881 +8
Misses 1777 1777
|
vangheem
left a comment
There was a problem hiding this comment.
I've always thought about this.
Making the reader interface async will also allow for more flexibility if you need to hook into anything else during object reading.
async is like an infection though -- the number of interfaces this affects is a shame...
IMO, this is a breaking change. Lots of interfaces that are potentially used.
We could make the interface optionally async. Use https://github.com/plone/guillotina/blob/master/guillotina/utils/misc.py#L126 to not cause breaking change
| return getattr(self._obj, "__partition_id__", 0) | ||
|
|
||
| def serialize(self): | ||
| async def serialize(self): |
There was a problem hiding this comment.
I didn't add the same logic as in the deserialization function (because it's expensive to know if a python object it's big or small) but I changed the function to async just in case someone wants to use a custom logic to decide when to run_async. For example:
async def serialize(obj):
if isinstance(obj, BigObject):
return await run_async(pickle.dumps, obj)
else:
return pickle.dumps(obj)There was a problem hiding this comment.
But if we feel it's not necessary I can revert this part
OK, agree
I'm ok with this change but third-party applications using the guillotina IWriter will still break so maybe we should update the minor version? |
Yes, I agree. |
I measured that big objects >50kB take a lot of time to deserialize, about 50, 100, 200ms depending on the size.. This change avoids blocking all requests in the process during deserialization.
I'm not sure if we should consider this a breaking change or if it's ok as a patch version