IMO bothvalidator.mapping.cache.apc andvalidator.mapping.cache.doctrine.apc (as it has been) should be deprecated. There is no point if providing an apc service but not any other cache driver like filesystem, redis etc. So it's better to be let developers define them themselves.

@Tobion : If we remove those services accordingly to what you say, then we should remove theserializer.mapping.cache.apc one too, or any other persistent cache layer implementation from Symfony.

The main benefit of proposing such an implementation is that it only requires the APCu php extension and allow to suggest optimizations from the Standard Edition.
If we don't,those lines should be removed, and we loose an opportunity to promote ways to improve performances.

Some refs about related discussions:

• [FrameworkBundle] Add a doctrine cache service definition for validator mapping #14429 (comment)

@ogizanagi yes I would suggest to deprecateserializer.mapping.cache.apc in 3.1 then.

The standard-edition should IMO actually configure the caching using filesystem. So if the caching is really a performance gain, just use a filesystem one by default (filesystem access required by default anyway due to logging). For this, we can use the doctrine-cache-bundle, which is a dependecy as well and then just use it's service. If somebody wants to use a different cache adapter, it's really easy to change as the template is already there for the filesystem.

@Tobion, most loggers including Monolog can be configured to log onstderr. On Heroku, LogPlex automatically catches and centralizes logs outputted that way.

IMO it's better to keep default APCu implementations as they are the best for such jobs:#16838 (comment)

@dunglas I don't see the relation to loggers?

@Tobion it was about "filesystem access required by default anyway due to logging" but I maybe I've missed something.

I see but again, I was talking about the standard-edition, which currently logs to a filesystem by default. That is why I said, we should IMO also configure filesystem caches in SE for most stuff by default as well, e.g. your property-accessor cache, validator etc. If people want to use APC or anything else, they only need to change the service definition very easily (or doctrine-cache-bundle config).

It is too late to add such deprecation in 2.8 anyway, given that 2.8 and 3.0 are already released.

@stof it's not too late because 3.0 is broken with ApcCache. See#16795

👎 we need a decent cache system in the core or it will be painful to get correct performance with many components (including - at least - Validator, Serializer, PropertyInfo and PropertyAccess) in prod. This is a regression.

Second commit removed to finally keep the the APCu cache service in 3.0.
To be eventually deprecated in 3.1 and removed in 4.0, but for now, only fix the deprecation on the wrong service.

Now that there is ApcuCache in doctrine cache (doctrine/cache#115) and ApcCache deprecated, should validator.mapping.cache.doctrine.apc becomes validator.mapping.cache.doctrine.apcu?

@layanto it will be a BC break. I'm working on APCu support. Except a PR when this one will be merged.

👍

👍

Dumb question, but since symfony requires doctrine\common and doctrine\common requires doctrine\cache, why not just retain the use of validator.mapping.cache.apc but point to DoctrineCache instead of ApcCache? Still using apc just via doctrine\cache so not really BC break? No change required from users who use apc for validator as apc will continue to work, via doctrine\cache.

Benefit of above: no change required from user, shorter and consistent naming with serializer.mapping.cache.apc which already points to DoctrineCache.

👍

In summary, this:

1. Deprecates usingapc as thecache key - you must use a service
2. Re-adds thevalidator.mapping.cache.doctrine.apc service, so you can use it for convenience (and we will discuss later if we want to deprecate this service for 4.0 removal).

After this is merged into 3.0, the ability to passapc as the key tocache can be completely removed (https://github.com/symfony/symfony/pull/16795/files#diff-5e7347edce37c5886ec67b7ba02f3a9cL439). This isnot a BC break, because it's impossible to use this already on 3.0, because using this config key gives you thevalidator.mapping.cache.apc service, which is connected with theApcCache that no longer exists in 3.0:https://github.com/symfony/symfony/pull/16795/files#diff-c2459e2c1a786adcaaab00b70630b67fL31

So, we need to:

A) merge this PR (and merge up to 3.0)
B) remove the Configuration code that allowed you to use theapc key in 3.0 (e.g. cherry-pickhttps://github.com/symfony/symfony/pull/16795/files#diff-5e7347edce37c5886ec67b7ba02f3a9cL439).

And I think we're ready to do this now.

What about@Tobion comments?

@fabpot : Those comments are "outdated" after the decisions taken in this PR &#16795 (I answered to them in first place, but then remove the commit fixing it, in order to deprecate the apc implementations in 3.1 and remove them in 4.0).

@Tobion : Can you please validate the situation ? :)

Thank you@ogizanagi.