Jira issue originally created by user nazin:
According to documentation expireResultCache, should force cache to update but it's not working... Why? Because functionality is not implemented. You can set _expireResultCache variable, but there is no place where this variable is being checked.
Comment created by @ocramius:
A cache profile can be set and cleaned. I suppose that expireResultCache is an old piece of code that survived the refactoring. Should just be removed and documented accordingly
Comment created by mdwyer415:
My understanding was that expireResultCache would ignore the cache, execute the query, and then save the result to cache. I'm not sure how accomplish that same thing by manipulating the cache profile, unless I created a result cache driver that always returned false on fetch, and used it for these occasions.
Am I missing something or is that a use case that shouldn't happen?
Thanks,
Mike
Hello,
I was reading the source code, and I've got the feeling that this problem is not yet solved.
This is a documented functionality :
edit : do not confond it with expireQueryCache who is well implemented, it is used here :
// Doctrine\ORM\Query
/**
* Parses the DQL query, if necessary, and stores the parser result.
*
* Note: Populates $this->_parserResult as a side-effect.
*
* @return \Doctrine\ORM\Query\ParserResult
*/
private function _parse()
{
//...
$cached = $this->_expireQueryCache ? false : $queryCache->fetch($hash);
//...
}
it seems that the implementation could be as simple as :
/**
* Load from second level cache or executes the query and put into cache.
*
* @param ArrayCollection|array|null $parameters
* @param integer|null $hydrationMode
*
* @return mixed
*/
private function executeUsingQueryCache($parameters = null, $hydrationMode = null)
{
//...
if ($this->getExpireResultCache()) {
$result = null;
} else {
$result = $queryCache->get($queryKey, $rsm, $this->_hints);
}
//...
}
note I replace the $result = $queryCache->get($queryKey, $rsm, $this->_hints); by the if
@bruno-ds can you please send a test that confirms that this is not really working?
Hello,
I'm rather new to symfony, so I don't know how to write the requested test.
But looking at the code, it is obvious : as said in the original issue, getExpireResultCache (and the protected $_expireResultCache) are not used in the code except in the getter/setter.
@bruno-ds lucky you it's not Symfony but Doctrine :P Jokes aside, maybe look at the concerned class and look for a test case using it. You may find a test case related to it where you may find some lead to implement the requested test :)
I just forked, cloned and search in the tests... but I'm lost... I think that the test should be Doctrine\Tests\ORM\Cache\*. But I don't even understand those tests, and similar function are not tested (ie : setResultCacheLifetime, setResultCacheId, ...)
@bruno-ds those tests are related to L2-cache (second level cache). You can create a funcional test (based on https://github.com/doctrine/doctrine2/blob/2c5e76c96187b512b3b51c14b68ec64c8c2dd857/tests/Doctrine/Tests/ORM/Functional/Ticket/GH5762Test.php for example).
thank you, I tried to create a test, but I don't know how to run it, so I created a PR : https://github.com/doctrine/doctrine2/pull/6390
@bruno-ds thanks for the PR I'll review it soon and find a way to have it properly fixed.
Just one thing, based on the PR I'd recommend you to check L2-cache since it handles cache invalidation automatically http://docs.doctrine-project.org/projects/doctrine-orm/en/latest/reference/second-level-cache.html
thank you,
just for information, my use case is : I have to count the unread notifications for each user, I compute this only by advance & store it in a lifetime 0 cache.
since expireResultCache(true) do not work, when this counter has to change, I ended up creating myself the id, it permits me to delete it in redis, but the code is obviously more complex.
Since the result I cache is a count, I don't think that the second level cache would help.
You're right, L2C won't help you with counts but theoretically the timestamp region of an entity might help to know when you need to invalidate that result set
Implemented in #6417 - will land in 2.6
Most helpful comment
Implemented in #6417 - will land in
2.6