Do not disable cache in dev

[teohhanhui]

Q	A
Bug fix?	no
New feature?	no
BC breaks?	no
Deprecations?	no
Tests pass?	yes
Fixed tickets	#2593 (partially)
License	MIT
Doc PR	api-platform/docs#766

With the cache enabled, changing API resource metadata in dev still works without a manual cache:clear.

[maks-rafalko]

Could you please explain what should be used instead? Or what are the defaults for prod/test environments?

It's not clear what the end user should do from the deprecation warning. Just remove and what is the alternative?

Thanks

[teohhanhui]

Yes, just remove it. The cache is enabled.

There should not be a need to disable it in most cases. I'd consider that an advanced use case, so we don't need to guide you in such a case anyway.

[maks-rafalko]

The cache is enabled.

The question is what is the adapter used for each env: dev, test, prod?

From what I have learned in previous master, the default cache adapter was cache.system, which is, in our case, APCu. And we had to enable it explicitly, by setting api_platform.metadata_cache to true. In dev mode, it was overridden with ArrayAdapter.

What are the defaults now? Will api-platform use cache.system by default, even in dev mode? If so, how it will work "without a manual cache:clear"?

Hope it will help other people that will have the same questions ;)

[teohhanhui]

What are the defaults now? Will api-platform use cache.system by default, even in dev mode?

Yes.

If so, how it will work "without a manual cache:clear"?

We've always been using the DirectoryResource so the container is automatically rebuilt when any file in the directory is modified (the directories specified in mapping > paths option of API Platform config). If I understand correctly, the cache invalidation is taken care of by Symfony. (We do have apcu enabled in api-platform/demo, which I tested with. So I think it works as intended.)

However, perhaps adding a new file would require a manual cache:clear, just like for Symfony Serializer / Validator metadata. (Not sure about this point. I'll try to verify.)

[dunglas]

LGTM

[soyuka]

Thanks @teohhanhui !