mirror of
https://github.com/doctrine/orm.git
synced 2026-03-23 22:42:18 +01:00
Data hydration caching #5217
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @ostrolucky on GitHub (Aug 14, 2016).
Originally assigned to: @Ocramius on GitHub.
Doctrine's hydration becomes bottleneck when database returns lot of data. We're reluctant to enable query result cache, because our queries spit out results quick enough and we would have to manage cache invalidation.
Instead, I propose to implement caching in hydrateRowData() (or somewhere around this place). Just generate hash of the array returned from the database and use it as cache id. Then deserialize the data from the cache. Great thing about this approach is that as long as entity class has not been changed, we don't have to worry about cache invalidation. Correct me if I'm wrong.
@Koc commented on GitHub (Aug 14, 2016):
Looks like you are talking about second level cache that already implemented
@ostrolucky commented on GitHub (Aug 14, 2016):
No, current implementation of second level cache generates hash of input sql query. Cache I'm talking about generates hash of database output. It doesn't skip database call. Purpose of that is to speed up specifically this process:
@gsdevme commented on GitHub (Aug 19, 2016):
Interesting idea, hashing the SQL does mean if the data changes you are stale. Hashing the output from the database scalar only means the hydration process is out of date (which likely won't change without code change).
Im not sure how possible this is, but sounds like a good performance increase for those who do not want/cant cache the database query.
@kimhemsoe commented on GitHub (Aug 19, 2016):
Ocramius Have already played around with some ideas for making hydration faster,
if want a look at where doctrine maybe will heading.
https://ocramius.github.io/blog/doctrine-orm-optimization-hydration/
https://github.com/Ocramius/GeneratedHydrator
@Ocramius commented on GitHub (Aug 19, 2016):
The fact that hydration is a bottleneck is a known fact. We cannot fix it now, but we are trying to come up with solutions for 3.x (or later, depending on what we will be able to do).
As @kimhemsoe said, research on this is already happening.
For 2.x, this is not going to change. You can use the hydration cache at your own risk though:
31a0c02b06/lib/Doctrine/ORM/AbstractQuery.php (L479-L519)Meanwhile, a glimpse of what is going to happen (hopefully):
Note that hydration will always remain an
O(n)or greater operation: what we can do is just reduce the cost of every single operation.Closing here. No resolution path until we figured out all the bits.