[FrameworkBundle] Added a keep-in-memory option for cache adapters #30984
Conversation
d6eae8a to
7177a42
Compare
src/Symfony/Bundle/FrameworkBundle/DependencyInjection/FrameworkExtension.php
Outdated
Show resolved
Hide resolved
src/Symfony/Bundle/FrameworkBundle/DependencyInjection/FrameworkExtension.php
Outdated
Show resolved
Hide resolved
7177a42 to
ce51023
Compare
ce51023 to
0cdfd92
Compare
|
@nicolas-grekas fixed your feedbacks, thanks |
| @@ -995,6 +995,7 @@ private function addCacheSection(ArrayNodeDefinition $rootNode) | |||
| ->info('Overwrite the setting from the default provider for this adapter.') | |||
| ->end() | |||
| ->scalarNode('clearer')->end() | |||
| ->booleanNode('keep_in_memory')->defaultFalse()->end() | |||
There was a problem hiding this comment.
Could you please add an info() tag?
| } | ||
|
|
||
| unset($tags[0]['keep_in_memory']); | ||
|
|
||
| if (!empty($tags[0])) { | ||
| throw new InvalidArgumentException(sprintf('Invalid "%s" tag for service "%s": accepted attributes are "clearer", "provider", "name", "namespace", "default_lifetime" and "reset", found "%s".', $this->cachePoolTag, $id, implode('", "', array_keys($tags[0])))); |
There was a problem hiding this comment.
the new attribute should be listed here
|
Shouldn’t this feature be enabled by default, with an option to opt out? |
chaining can introduce subtle desynchronization effects because the upper pools don't know when the items in lower pools are invalidated. That's true for the remaining expiration time but also for tag-based invalidation. An idea could be to default to using a 1s local cache when tags are not used. This makes me think we should forbid using tags+keep-in-memory together, and that we should make keep-in-memory an integer, that would default to 1, which would set the number of seconds the local pool keeps items when the real expiration date is unknown. |
|
What if the cache pool is already using the ArrayAdapter? Then enabling the option does not make sense and should probably throw an error. |
|
Thank you for this PR. This PR is just a shortcut for creating an ChainAdapter. I agree that it is super tricky to understand how to actually create a ChainAdapter. I just submitted a PR to the docs to fix the broken example. (That I created a few months ago...) I fear that this PR will only make configuration more complex and harder to understand. I vote 👎 because I think we should promote "the proper way" instead of adding shortcuts. |
…y providing several adapters (nicolas-grekas) This PR was merged into the 4.4 branch. Discussion ---------- [FrameworkBundle] Allow creating chained cache pools by providing several adapters | Q | A | ------------- | --- | Branch? | 4.4 | Bug fix? | no | New feature? | yes | BC breaks? | no | Deprecations? | no | Tests pass? | yes | Fixed tickets | - | License | MIT | Doc PR | - Replaces #30984, follows symfony/symfony-docs#11813 This PR allows defining several adapters for one pool. When doing so, this defines a chain pool. The benefit is that all chained pools get automatic namespace and lifetime, so things are transparent: ```yaml pools: my_chained_pool: default_lifetime: 12 adapters: - cache.adapter.array - cache.adapter.filesystem - {name: cache.adapter.redis, provider: 'redis://foo'} ``` (see fixtures for example of PHP/XML config) /cc @Nyholm @pborreli FYI Commits ------- 29ba091 [FrameworkBundle] Allow creating chained cache pools by providing several adapters
Adding a
keep-in-memoryoption for cache adapters which is basically a shortcut using ChainAdapter with ArrayCache as first adapter.