Platform param in the connection params results in not evicting cache entries #8890
Conversation
|
@piowin The Second Level Cache was introduced a few years after the query result cache. The "problem" with second level cache is that we currently have no one in the team that understands it anymore :-) With its extra complexity I am reluctant to deprecate the query result cache in favor of SLC. |
|
Nonetheless, the bug is real. A BC solution would be to create a decorator (a different instance of it for every query) of the Result Cache Driver. Every time the fetch method is called the decorator checks if a flag is set to be true and if so it evicts the result (the key is the parameter of the fetch method - that's the way we get it, instead of generate ourself), otherwise the decorator would simply forward to the Result Cache Driver. In this way a query wouldn't have to know how to generate cache keys to evict a result and depend on the inner logic of the DBAL's Connection. But it seems to be quite inelegant. |
|
There hasn't been any activity on this pull request in the past 90 days, so it has been marked as stale and it will be closed automatically if no further activity occurs in the next 7 days. |
The Query code tries to repeat the logic of the creation of query result cache keys, therefore it depends on that logic.
This leads to the bug presented in the PR, namely:
Doctrine\DBAL\Connection::executeCacheQuery() unsets the platform param before it creates the query result cache key:
However, Doctrine\ORM\Query::evictResultSetCache() doesn't unset the platform param when creating the query result cache key.
Therefore, when the platform param is present, the cached results are not being evicted from the cache and the Doctrine\Test\ORM\Query\QueryTest::testResultCacheEviction() test fails as the old result is still retrieved from the cache.
As an ad hoc solution we could unset the platform param as in Doctrine\DBAL\Connection::executeCacheQuery(), but it doesn't solve the architectural issue which results from breaking the Single Responsibility Principle and coupling the two modules.
Should the query result cache in that form exist at all? Shouldn't it be like in Hibernate where the query result cache is connected with the second level cache? Actually, what is called "query result caching" in Hibernated is already implemented in Doctrine (it is query caching in second level caching).