Right now the CacheFlushCommand does not clear all providers. By also registering those to the command when building the application, the providers also will get cleared when calling

bin/console cache:flush all

This MR also outputs info about what cache types have been flushed:

[dev@devint www]$ bin/console cache:flush
Do you want to clear all cache? [N] Y
 // Clearing cache for built in type 'annotation"
 // Clearing cache for built in type 'doctrine"
 // Clearing cache for built in type 'serializer"
 // Clearing cache for built in type 'session"
 // Clearing cache for built in type 'router"
 // Clearing cache for built in type 'validation"
 // Clearing cache for provider 'cache.provider.chain"
 // Clearing cache for provider 'cache.provider.file"
 // Clearing cache for provider 'cache.provider.redis"

 // Clearing the cache for the dev environment with debug true

 [OK] Cache for the "dev" environment (debug=true) was successfully cleared.

Hi guys,

The lowest supported PHP version in composer.json is PHP 5.5 but CacheFlushCommand is using array constants which aren't supported until PHP 5.6.

This PR adds a fix.

Introducing the support for cache proxies instead for messing around with different types of recording pools like we did.

This will create a proxy file that extends the original pool. It is only used in development of course.

We need a way to disable the data collector as during development our app regularly runs out of memory because of how much data it collects. In our particular case we use a lot of annotations and doctrine is caching those in memcache. We end up running over our memory limit.

We don't get much value from the data collector so the option to disable solves the problem for us.

This will fix the issue with the RecorderCachePool (used for Symfony data collection) implements TaggableCache. If the underlying cache implemnation (like apc cache) does not support tagging we have to decorate the implementation with TaggablePSR6PoolAdapter. But that causes trouble when using a ChainPool.

This PR introduce a Factory that choose a RecordingPool that implements the same interfaces as the CachePool.

Please review this. Im not too sure this is a good solution. The problem occurs when we are using a pool that do not support tagging, say APC. In debug we put the APC pool in the recording pool because we want to use the WebToolbar. The recording pool is always a Taggable pool. That's why we get errors like this: https://github.com/php-cache/issues/issues/50

Warning: call_user_func_array() expects parameter 1 to be a valid callback, class 'Cache\Adapter\Apc\ApcCachePool'

This solution makes sure we are always dealing with a Taggable pool.

Should the SymfonyValidatorBridge be in a separate package? Pros:

• It can be resused
• It is similar to the DoctrineCacheBridge

Cons:

• Nobody wants to reuse it
• It is dead simple to write

add reset method, which implement Symfony\Component\HttpKernel\DataCollector\DataCollectorInterface and solve deprication

User Deprecated: Implementing "Symfony\Component\HttpKernel\DataCollector\DataCollectorInterface" without the "reset()" method is deprecated since Symfony 3.4 and will be unsupported in 4.0 for class "Cache\CacheBundle\DataCollector\CacheDataCollector".

I use the PHPUnit\Framework\TestCase notation instead of PHPUnit_Framework_TestCase while extending our TestCases. This will help us migrate to PHPUnit 6, that no longer support snake case class names.

PS: I won't apply this StyleCI changes. There are not related to this PR :sweat_smile: