Repository navigation
#67 - Tag a Symfony cache pool directly as a cache adapter, without an adapter class - #68
Merged
Merged
Conversation
…n adapter class A service implementing the AdapterInterface of the Cache component (a Symfony adapter or a pool defined with "parent") can be tagged cleverage.cache.adapter with a code: RegisterAdaptersPass wraps it in an Adapter with this code, loaded lazily. A tagged service implementing neither interface fails the compilation. Tests, documentation and CHANGELOG updated. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
This file contains hidden or 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
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.
Description
Fixes #67.
RegisterAdaptersPass: a service taggedcleverage.cache.adapterwith acodewhose class implementsSymfony\Component\Cache\Adapter\AdapterInterfacebut not theAdapterInterfaceof the bundle is wrapped in anAdapterwith this code (private.cleverage_cache_process.adapter.<code>service), still loaded lazily from the locator. The class is read from the definition, or from itsparent(pools defined as services, as the FrameworkBundle ones), parameters resolved.AdapterInterfaceof the bundle are registered unchanged; a service whose class cannot be loaded is registered as is (checked when fetched, as before).code(the deprecated registration withoutcodeis unchanged).framework.cache.poolscannot be tagged by the application (their definitions are created by the FrameworkBundle): the documentedAdapterservice wrapping them stays the way to use them.ArrayAdapterand a poolparent: cache.adapter.filesystem, notes), the "share data between branches" cookbook no longer needs a PHP class. CHANGELOG.Tests:
RegisterAdaptersPassTest(pool and pool with a parent wrapped, lazily, one pool for two codes, unknown class or no class registered as is, neither interface → compilation error);KernelTest(anArrayAdapterand aparent: cache.adapter.array+cache.poolservice in a real application).Checked in the container (PHP 8.5): 82 tests, 100 % of the lines, no risky test (pcov coverage), also with
--prefer-lowest. PHPStan, PHP-CS-Fixer and Rector OK. In the demo (vendor patched temporarily), theMemoryAdapterclass replaced by aparent: cache.adapter.arraypool tagged directly:lint:containerOK and thedemo.cache.*processes give the same results.Requirements
Breaking changes
None: the services already tagged keep working; a tagged service implementing neither interface failed when used (
addAdapter()typed in the released versions, check of the registry since #53).🤖 Generated with Claude Code