Orm: Do not deprecate useResultCache

[moxival]

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.

[holtkamp]

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?

[ilianiv]

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();

[greg0ire]

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

[someniatko]

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

[Ocramius]

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.

[greg0ire]

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();

[moxival]

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 😸

[greg0ire]

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

[ilianiv]

@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.

[greg0ire]

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.

[moxival]

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_).

[Ocramius]

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