Do not deprecate useResultCache #6355

New Issue

admin · 2026-01-22T15:31:39+01:00

admin commented

2026-01-22 15:31:39 +01:00

Originally created by @moxival on GitHub (Nov 29, 2019).

Do not deprecate the `AbstractQuery::useResultCache`

Q	A
New Feature	no
RFC	no
BC Break	no

Summary

Please do not deprecate the AbstractQuery::useResultCache.
Without this method the "chainability" gets broken:
$em->createQuery()->setParameters()->useResultCache($debug)->getResult()

Without the method we have no way of doing the above and honestly I do not understand the need to remove it.

Originally created by @moxival on GitHub (Nov 29, 2019). ### Do not deprecate the `AbstractQuery::useResultCache`  | Q | A |------------ | ------ | New Feature | no | RFC | no | BC Break | no #### Summary Please do not deprecate the `AbstractQuery::useResultCache`. Without this method the "chainability" gets broken: ` $em->createQuery()->setParameters()->useResultCache($debug)->getResult() ` Without the method we have no way of doing the above and honestly I do not understand the need to remove it.

admin closed this issue

2026-01-22 15:31:39 +01:00

admin commented

2026-01-22 15:31:40 +01:00

@holtkamp commented on GitHub (Nov 29, 2019):

Encountered the same situation where the "application context" determines whether caching is enabled.

$query->useResultCache($this->applicationContext->useCaching());

I do like the explicit enable and disable cache methods, but why deprecate the "useResultCache()" methods? They can all exist right?

@holtkamp commented on GitHub (Nov 29, 2019): Encountered the same situation where the "application context" determines whether caching is enabled. ```php $query->useResultCache($this->applicationContext->useCaching()); ``` I do like the explicit enable and disable cache methods, but why deprecate the "useResultCache()" methods? They can all exist right?

admin commented

2026-01-22 15:31:40 +01:00

@ilianiv commented on GitHub (Nov 29, 2019):

Same here ☹️ I have to refactor all my useResultCache() calls with an ugly ifs:

👌  Nice and smooth in ORM 2:

$res = $entityManager
  ->createQuery($dql)
  ->useResultCache($cache_enabled, $ttl)
  ->getResult();

----

🤮 Ugly in ORM 3:

$q = $entityManager->createQuery($dql);
if ($cache_enabled) {
  $q->enableResultCache($ttl);
}
$res = $q->getResult();

@ilianiv commented on GitHub (Nov 29, 2019): Same here ☹️ I have to refactor all my `useResultCache()` calls with an ugly `if`s: ``` 👌 Nice and smooth in ORM 2: $res = $entityManager ->createQuery($dql) ->useResultCache($cache_enabled, $ttl) ->getResult(); ---- 🤮 Ugly in ORM 3: $q = $entityManager->createQuery($dql); if ($cache_enabled) { $q->enableResultCache($ttl); } $res = $q->getResult(); ```

admin commented

2026-01-22 15:31:40 +01:00

@greg0ire commented on GitHub (Nov 29, 2019):

The deprecation was introduced in #7701 , cc @someniatko .

@greg0ire commented on GitHub (Nov 29, 2019): The deprecation was introduced in #7701 , cc @someniatko .

admin commented

2026-01-22 15:31:40 +01:00

@someniatko commented on GitHub (Nov 29, 2019):

@Ocramius it looks like people are complaining, milord
Should we revert the change?

@someniatko commented on GitHub (Nov 29, 2019): @Ocramius it looks like people are complaining, milord Should we revert the change?

admin commented

2026-01-22 15:31:41 +01:00

@Ocramius commented on GitHub (Nov 29, 2019):

Not really: conditionally using result cache is secondary, mostly for ORM wrappers than for end consumers, so I'd say that the new API is indeed preferable.

In practice, in development environments, replace the cache with a volatile version, rather than passing a $debug flag down by multiple layers.

@Ocramius commented on GitHub (Nov 29, 2019): Not really: conditionally using result cache is secondary, mostly for ORM wrappers than for end consumers, so I'd say that the new API is indeed preferable. In practice, in development environments, replace the cache with a volatile version, rather than passing a `$debug` flag down by multiple layers.

admin commented

2026-01-22 15:31:42 +01:00

@greg0ire commented on GitHub (Nov 30, 2019):

replace the cache with a volatile version

That's clever! @moxival @holtkamp @ilianiv are you satisifed with this?

👌  Nice and smooth in ORM 2:

$res = $entityManager
  ->createQuery($dql)
  ->useResultCache($cache_enabled, $ttl)
  ->getResult();

----

✨👌✨  Nicer and smoother in ORM 2:
// globally replace the cache with a volatile cache
// stop passing $cache_enabled through a bazillion layers

$res = $entityManager
  ->createQuery($dql)
  ->enableResultCache($ttl)
  ->getResult();

@greg0ire commented on GitHub (Nov 30, 2019): > replace the cache with a volatile version That's clever! @moxival @holtkamp @ilianiv are you satisifed with this? ``` 👌 Nice and smooth in ORM 2: $res = $entityManager ->createQuery($dql) ->useResultCache($cache_enabled, $ttl) ->getResult(); ---- ✨👌✨ Nicer and smoother in ORM 2: // globally replace the cache with a volatile cache // stop passing $cache_enabled through a bazillion layers $res = $entityManager ->createQuery($dql) ->enableResultCache($ttl) ->getResult(); ```

admin commented

2026-01-22 15:31:42 +01:00

@moxival commented on GitHub (Nov 30, 2019):

EDIT Lets make my comment less b**chy

No I am not satisfied by this, when i submitted this issue I did not ask for a lecture in "volatile cache" I asked for you guys to leave a perfectly good method (that in no way will mess the ORM code).

If you can not leave the method by all means make us fill our code with ifs and elses for much more smoothness and volatile stuff 😸

@moxival commented on GitHub (Nov 30, 2019): ***EDIT*** _Lets make my comment less b**chy_ No I am not satisfied by this, when i submitted this issue I did not ask for a lecture in "volatile cache" I asked for you guys to leave a perfectly good method (that in no way will mess the ORM code). If you can not leave the method by all means make us fill our code with ifs and elses for much more smoothness and volatile stuff 😸

admin commented

2026-01-22 15:31:42 +01:00

@greg0ire commented on GitHub (Nov 30, 2019):

Is this your way of telling us you don't understand what "volatile cache" means? If yes, there are nicer ways to do so. If not, then explain what it means to you, because when I read your last sentence , I'm under the impression that you don't… why would this cause lots of ifs and elses?

regarding your EDIT: at least you noticed you were not being very nice :P

@greg0ire commented on GitHub (Nov 30, 2019): Is this your way of telling us you don't understand what "volatile cache" means? If yes, there are nicer ways to do so. If not, then explain what it means to you, because when I read your last sentence , I'm under the impression that you don't… why would this cause lots of ifs and elses? regarding your EDIT: at least you noticed you were not being very nice :P

admin commented

2026-01-22 15:31:42 +01:00

@ilianiv commented on GitHub (Nov 30, 2019):

@Ocramius @greg0ire Lets say you want to implement an api that should handle GET parameter “nocache” that will make it hit the DB bypassing the cache. In this case replacing the cache is not so good.

I think it’ll cost you nothing to add a proxy method useResultCache() that will call one of the two new methods and everyone will be happy.

@ilianiv commented on GitHub (Nov 30, 2019): @Ocramius @greg0ire Lets say you want to implement an api that should handle GET parameter “nocache” that will make it hit the DB bypassing the cache. In this case replacing the cache is not so good. I think it’ll cost you nothing to add a proxy method useResultCache() that will call one of the two new methods and everyone will be happy.

admin commented

2026-01-22 15:31:42 +01:00

@greg0ire commented on GitHub (Nov 30, 2019):

I think it would be simpler to have a cache decorator that is aware of the request stack (assuming Symfony context) and forwards calls to either a normal cache or a null cache (such as one of those: https://github.com/ThaDafinser/psr6-null-cache/blob/master/src/Adapter/ , but for doctrine/cache, we have not yet migrated to PSRs) depending on the value of this parameter. That way it works for the whole API just like you asked, and you did not modify n repositories with n calls to useResultCache() for that.

@greg0ire commented on GitHub (Nov 30, 2019): I think it would be simpler to have a cache decorator that is aware of the request stack (assuming Symfony context) and forwards calls to either a normal cache or a null cache (such as one of those: https://github.com/ThaDafinser/psr6-null-cache/blob/master/src/Adapter/ , but for doctrine/cache, we have not yet migrated to PSRs) depending on the value of this parameter. That way it works for the whole API just like you asked, and you did not modify n repositories with n calls to `useResultCache()` for that.

admin commented

2026-01-22 15:31:43 +01:00

@moxival commented on GitHub (Nov 30, 2019):

Dear @greg0ire this issue is not about me knowing what "volatile cache" is or isn't, I may know what volatile cache is (although in all honesty violate cache is just real fancy term) 'coz I was in the field for the last 15 years or I may have no idea coz I am 15 y.o. and I am just starting up with PHP . May i remind you milord that PHP does not constrain itself to Symfony nor decorators (even less to decorators that are aware of stuff).

If it is too challenging for you to keep the useResultCache please just say so my liege we would totally understand.

I also understand that ORM 3 sounds exhilarating and you feel like you should make all your loyal subjects miserable and have them change every single bit of code but maybe, just maybe you would let us (the stupid ones that have no clue what "volatile cache" is or how to manipulate their request stack with decorators while trying to implement PSR- 35672 at no avail) this little twinkle star of hope and leave the useResultCache alone because there is literally 0 (zero) effort involved on your part in doing so 😺 (please note the emoji - that means my comment is not mean but witty and hilarious filed with warm feelings and melting caches).

@moxival commented on GitHub (Nov 30, 2019): Dear @greg0ire this issue is not about me knowing what "volatile cache" is or isn't, I may know what volatile cache is (although in all honesty violate cache is just real fancy term) 'coz I was in the field for the last 15 years or I may have no idea coz I am 15 y.o. and I am just starting up with PHP . May i remind you **milord** that PHP does not constrain itself to Symfony nor decorators (even less to decorators that are aware of stuff). If it is too challenging for you to keep the `useResultCache` please just say so _my liege_ we would totally understand. I also understand that ORM 3 sounds exhilarating and you feel like you should make all your loyal subjects miserable and have them change every single bit of code but maybe, just maybe you would let us (the stupid ones that have no clue what "volatile cache" is or how to manipulate their request stack with decorators while trying to implement PSR- 35672 at no avail) this little twinkle star of hope and leave the `useResultCache` alone because there is literally **0** (_zero_) effort involved on your part in doing so 😺 (_please note the emoji - that means my comment is not mean but witty and hilarious filed with warm feelings and melting caches_).

admin commented

2026-01-22 15:31:43 +01:00

@Ocramius commented on GitHub (Nov 30, 2019):

Closing and locking here: not worth discussing further with this tone.

@Ocramius commented on GitHub (Nov 30, 2019): Closing and locking here: not worth discussing further with this tone.

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: doctrine/archived-orm#6355

Do not deprecate useResultCache #6355

Do not deprecate the AbstractQuery::useResultCache

Summary

Do not deprecate the `AbstractQuery::useResultCache`