(dev/core#3166) "Metadata" cache - Strictly separate by version #23148
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This addresses some symptoms identified in the discussion of 3166.
Before
------
The "metadata" cache is always stored with the name `metadata`.
If you load a newer codebase, it still reads `metadata` from the older code base (until something explicitly clears the cache).
After
-----
The "metadata" cache is always stored with the name `metadata_{version}`, eg `metadata_5_48_0`.
If you load a newer codebase (eg `5.49.0`), it will ignore the older `metadata_5_48_0` and create a new `metadata_5_49_0`.
Comments
--------
The upgrade system also clears cache, but many users rely on navigating through the site to get to the upgrader.
The change could make sense with other caches, but I only applied the change to the `metadata` cache because there is _some_ risk;
eg if some caller bypasses the cache objects. (I was also slightly concerned about the possibility the some caller relies
on `$cache->getName()` or `$cache->getPrefix()` or similar... but I haven't been able to find any methods like that...). It seems
safer to put that sort of change into a monthly update rather than minor patch.
|
(Standard links)
|
|
Before patch I could replicate dev/core#3166 After applying patch that error is solved and upgrades can proceed as 'normal'. |
|
I had a problem with civigrant again which I first thought might be related but seems to be with or without. So seems ok. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Overview
This addresses some symptoms identified in the discussion of dev/core#3166 where a recently-updated codebase generates errors due to stale cache data.
With this patch, the
metadatacache will be de-facto reset whenever you load new code.Before
The
metadatacache is always stored with the namemetadata.If you load a newer codebase, it still reads
metadatafrom the older code base (until something explicitly clears the cache).After
The
metadatacache is always stored with the namemetadata_{version}, egmetadata_5_48_0.If you load a newer codebase (eg
5.49.0), it will ignore the oldermetadata_5_48_0and create a newmetadata_5_49_0.Comments
The upgrade system also clears cache, but many users rely on navigating through the site to get to the upgrader.
The change could make sense with other caches, but I only applied the change to the
metadatacache because there is some risk; eg if some caller bypasses the cache objects. (I was also slightly concerned about the possibility the some caller relies on$cache->getName()or$cache->getPrefix()or similar... but I haven't been able to find any methods like that...). It seems safer to put that sort of change into a monthly update rather than minor patch.The discussion in 3166 touched on a few different error scenarios in a few different environments. I don't know that it helps all of them, but it helps the ones that I experienced/reproduced.