DDC-2981: Multi get for second level cache (Doctrine Cache related) #3710

Closed
opened 2026-01-22 14:25:54 +01:00 by admin · 7 comments
Owner

Originally created by @doctrinebot on GitHub (Feb 13, 2014).

Originally assigned to: @Ocramius on GitHub.

Jira issue originally created by user goetas:

Hi every body!

I'm developing an application that is highly based on doctrine second-level cache feature.
Using memcache or redis as cache back-end, doctrine have to query thousand times for the cached values (especially on one-to-many and many-to-many associations).
This introduces a lot of latency (and network traffic)...

I'm thinking to add to Doctrine\Common\Cache\Cache interface a method fetchMulti(array $keys) that fetches multiple items in one call. In this way doctrine orm can ask for many items with just one call (for example, here https://github.com/doctrine/doctrine2/blob/master/lib/Doctrine/ORM/Cache/DefaultCollectionHydrator.php#L84 this feature can be very useful).

I have made some real-world tests and it can reduce highly the number of total queries (my app runs 190 cache requests instead of 900 cache requests)

Many vendors (memcache, redis, apc ecc) already offer this functionality, but with doctrine-cache we can't use it...

I'm going to implement this feature. Can it be accepted as a pull request?

It may be BC breaking:

  • it can be implemented adding a method inside Doctrine\Common\Cache\Cache interface (more BC breaking but more clean and elegant)
  • it can be implemented adding an interface Doctrine\Common\Cache\MultiCache and later CacheProvider can implement it (less BC breaking)
Originally created by @doctrinebot on GitHub (Feb 13, 2014). Originally assigned to: @Ocramius on GitHub. Jira issue originally created by user goetas: Hi every body! I'm developing an application that is highly based on doctrine second-level cache feature. Using memcache or redis as cache back-end, doctrine have to query thousand times for the cached values (especially on one-to-many and many-to-many associations). This introduces a lot of latency (and network traffic)... I'm thinking to add to `Doctrine\Common\Cache\Cache` interface a method `fetchMulti(array $keys)` that fetches multiple items in one call. In this way doctrine orm can ask for many items with just one call (for example, here https://github.com/doctrine/doctrine2/blob/master/lib/Doctrine/ORM/Cache/DefaultCollectionHydrator.php#L84 this feature can be very useful). I have made some real-world tests and it can reduce highly the number of total queries (my app runs 190 cache requests instead of 900 cache requests) Many vendors (memcache, redis, apc ecc) already offer this functionality, but with doctrine-cache we can't use it... I'm going to implement this feature. Can it be accepted as a pull request? It may be BC breaking: - it can be implemented adding a method inside `Doctrine\Common\Cache\Cache` interface (more BC breaking but more clean and elegant) - it can be implemented adding an interface `Doctrine\Common\Cache\MultiCache` and later `CacheProvider` can implement it (less BC breaking)
admin added the Improvement label 2026-01-22 14:25:54 +01:00
admin closed this issue 2026-01-22 14:25:55 +01:00
Author
Owner

@doctrinebot commented on GitHub (Feb 13, 2014):

@doctrinebot commented on GitHub (Feb 13, 2014): - is referenced by [DDC-2982: [GH-954] Multi Get support for Second Level Cache](http://www.doctrine-project.org/jira/browse/DDC-2982)
Author
Owner

@doctrinebot commented on GitHub (Feb 13, 2014):

Comment created by @ocramius:

Adding a method to Doctrine\Common\Cache\Cache is not viable because of BC - a new interface would be ok

@doctrinebot commented on GitHub (Feb 13, 2014): Comment created by @ocramius: Adding a method to `Doctrine\Common\Cache\Cache` is not viable because of BC - a new interface would be ok
Author
Owner

@doctrinebot commented on GitHub (Feb 13, 2014):

Comment created by goetas:

ok, i agree with you.
But this forces me to check always here https://github.com/doctrine/doctrine2/blob/master/lib/Doctrine/ORM/Cache/Region/DefaultRegion.php#L95 if $this->cache is instance of MultiCache

@doctrinebot commented on GitHub (Feb 13, 2014): Comment created by goetas: ok, i agree with you. But this forces me to check always here https://github.com/doctrine/doctrine2/blob/master/lib/Doctrine/ORM/Cache/Region/DefaultRegion.php#L95 if `$this->cache` is instance of `MultiCache`
Author
Owner

@doctrinebot commented on GitHub (Feb 13, 2014):

Comment created by @ocramius:

[~goetas] or you build a MultiCacheRegion

@doctrinebot commented on GitHub (Feb 13, 2014): Comment created by @ocramius: [~goetas] or you build a `MultiCacheRegion`
Author
Owner

@doctrinebot commented on GitHub (Feb 13, 2014):

Comment created by goetas:

It can be a good approach. I will try it.
I'm thinking to provide a default implementation of fetchMulti directly inside CacheProvider that internally loops over each key and call CacheProvider::fetch($id) to fetch its value.
Later i will overwrite this behavior inside vendor specific driver (ApcCache, RedisCache...)

@doctrinebot commented on GitHub (Feb 13, 2014): Comment created by goetas: It can be a good approach. I will try it. I'm thinking to provide a default implementation of `fetchMulti` directly inside `CacheProvider` that internally loops over each key and call `CacheProvider::fetch($id)` to fetch its value. Later i will overwrite this behavior inside vendor specific driver (`ApcCache`, `RedisCache`...)
Author
Owner

@doctrinebot commented on GitHub (Jan 17, 2015):

Comment created by @ocramius:

Solved in DDC-2982

@doctrinebot commented on GitHub (Jan 17, 2015): Comment created by @ocramius: Solved in [DDC-2982](http://www.doctrine-project.org/jira/browse/DDC-2982)
Author
Owner

@doctrinebot commented on GitHub (Jan 17, 2015):

Issue was closed with resolution "Fixed"

@doctrinebot commented on GitHub (Jan 17, 2015): Issue was closed with resolution "Fixed"
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: doctrine/archived-orm#3710