Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
There is an invalidate* functions on the cacheBackendInternface however I don't see a) it used, b) a usefulness to include this over their equivalent delete function. Is there ever a need to pull an expired cache?
May as well save the memory/database storage by deleting it over setting its expiration time and remove this api (or map it to delete*).
Comment | File | Size | Author |
---|---|---|---|
#9 | deprecate-invalidate-2234835-9-interdiff.txt | 1.21 KB | Berdir |
#9 | deprecate-invalidate-2234835-9.patch | 4.78 KB | Berdir |
#7 | deprecate-invalidate-2234835-7.patch | 3.57 KB | Berdir |
Comments
Comment #1
danblack CreditAttribution: danblack commentedComment #2
danblack CreditAttribution: danblack commentedOk. I see the get method on CacheBackendInterface takes an allow_invalid invalid argument (that no-one uses).
Comment #3
jhedstromNo patch to review.
Comment #7
Berdirhttps://md-systems.github.io/drupal-8-caching/#/6/2
I was actually wrong, there are also two calls to invalidateAll() but they're unnecessary because we don't ever use them as invalid items, it just shows that the methods are confusing.
We discussed before if we should deprecate them and I think now that we shoud, so here's a patch.
Also confused about the \Drupal\Core\Menu\MenuTreeStorage::rebuild(), why would any cache entries ever not have the cache tags?
Comment #9
BerdirThis should fix the unit test.
Comment #10
dawehnerThis patch looks sane so far, but I strongly believe we should add some
@trigger_error
statements at least onto the cache implementations in core as well as\Drupal\Core\Cache\Cache
.Comment #13
borisson_Setting to needs work based on #10.
Comment #15
gisleOfficial tag is "API clean-up" - https://www.drupal.org/node/1207020