We’re storing parameterized cache builders using hash lists using HSET and access specific caches using HGET. This reduces the top level keys which probably was the motivation at some point.
However, this causes a problem when there is a cache both without and with parameters because the cache key is the same. One such example can be found with the trophies:
|
$this->trophies = TrophyCacheBuilder::getInstance()->getData(); |
|
$this->enabledTrophies = TrophyCacheBuilder::getInstance()->getData(['onlyEnabled' => 1]); |
The second cache will always be an implicit cache miss because the key is already set as a string. Trying to access offsets using HSET fails with a WRONGTYPE error which never surfaced because all errors are implicitly suppressed by not checking $redis->getLastError().
Following the example above, this will trigger 2 Redis errors (one for the lookup and one for the attempt to set it) that go unnoticed plus one extra SELECT query for the second cache.
We’re storing parameterized cache builders using hash lists using
HSETand access specific caches usingHGET. This reduces the top level keys which probably was the motivation at some point.However, this causes a problem when there is a cache both without and with parameters because the cache key is the same. One such example can be found with the trophies:
WCF/wcfsetup/install/files/lib/data/trophy/TrophyCache.class.php
Lines 41 to 42 in e33bc1e
The second cache will always be an implicit cache miss because the key is already set as a string. Trying to access offsets using
HSETfails with aWRONGTYPEerror which never surfaced because all errors are implicitly suppressed by not checking$redis->getLastError().Following the example above, this will trigger 2 Redis errors (one for the lookup and one for the attempt to set it) that go unnoticed plus one extra
SELECTquery for the second cache.