Thanks for pushing this forward.
I'm wondering: does the filesystem storage benefit from the change in terms of performance?
Can you post a blackfire comparison maybe for both adapters?

I'm wondering: does the filesystem storage benefit from the change in terms of performance?
Can you post a blackfire comparison maybe for both adapters?

It does make a noticeable difference. If you still want blackfire profile I can look into rebuilding docker env for that, but even just with web debug toolbar; if we take a demo install of eZ Platform EE(v2, Symfony 3.4LTS, dev mode, using server:start), without some other ongoing optimizations:

• Default "cache.app" which uses files system: ~950ms total time, Cache calls 6078 in ~310ms
• FileSystemTagAwareAdapter: ~730ms total time, Cache calls 3048 in ~135ms

Those 6078 cache calls results in 17,639 filesystem stat calls:

• Where 11,462 are cache misses(tags with no expiry yet), which PHP does not have stat cache for
  • =>These are eliminated completely with FileSystemTagAwareAdapter
• And hits, unlike Opcache or APC cache, results in a actual disk read with fopen once initial cached stat call with file_exists() is done(however fixing that is outside of scope here)

On Redis the benefit is larger, taking the total time down from 3 to 2 seconds(and further down to <1sec with other optimizations on eZ side), where about 1.5-2 seconds are spent connecting Redis(Redis as a local docker container over TCP using Predis). I expect Redis over network to producebigger difference.

Tests added, both optimized TagAware Adapters fail on these:

• ::testTagsAreCleanedOnSave
• :::testTagsAreCleanedOnDelete

Edit: I’ll add fixes for those two failures, shouldn’t be to hard, might allow me to cleanup some things here while at it.

@nicolas-grekas What are you missing here before this can be moved out of draft besides that?

I'd like to test this PR in my project (currently on 4.2.4). I do not get how to select this PR (what is the branch name??) in my composer.json (or symfony.lock) file. Can you help me ?

@flaushi 👍you'll need to add something like this incomposer.json:

{"repositories": [        {"type":"vcs","url":"https://github.com/andrerom/symfony"        }    ],"require": {"symfony/symfony":"dev-tagaware_adapters as 4.3.x-dev"    }}

@andrerom Any news on this one? How can we move forward?

@fabpot /@nicolas-grekas /@OskarStark Cache tests passing. I found a way to simplify doSave() approach, so this is ready for review from my side now.

Thanks for working on this@andrerom, awesome stuff! I'd like to ask for a bit more detail regarding the implementation. So as far as I could see from a quick review, these are additional tag aware adapters alongside the existingTagAwareAdapter, right?
So I have a few questions here:

• Nobody will benefit from these changes by just updating to the new version. Did you think about an alternative? Were there some blockers we don't know about?
• You've introduced a newAbstractTagAwareAdapter but the existingTagAwareAdapter does not use this. Seems a bit strange to me, any reason for this?

Also in general: I'm not sure about the support forpredis/predis (seepredis/predis#524). At least the decision should be in line with the Redis support for the Messenger component (#30917) where there's currently nopredis/predis support planned (also likely not going to happen because it needs at least version 5 of Redis andpredis/predis is not compatible and we don't know if it ever will be).

@Toflar I can answer your question I think:

Nobody will benefit from these changes by just updating to the new version. Did you think about an alternative? Were there some blockers we don't know about?

The code here is a totally new strategy to store the tags. It does not replace the existing one but completes it when one wants to use it. Both have valid use cases, with advantages and drawbacks.

TagAwareAdapter does not use AbstractTagAwareAdapter

sure, it shouldn't:TagAwareAdapter invalidates tags using versioning, andAbstractTagAwareAdapter is the base for adapters that invalidate using relations.

Also in general: I'm not sure about the support for predis/predis

support for predis is already backed into the component since a long time. Messenger is just catching up, and anyway, it's a separate component, with its own need (eg v5)

Very good, all questions answered. Then it's just a matter of documentation so that people choose the right strategy. I'll happily help out writing them 😄 👍

Updated, all review points fixed and back to green.

@nicolas-grekas two things I'd like to add here:

1. Handle case where people switch adapters. Suggested handling for going from plain to TagAware inddac001, but maybe we should handle other way around also?
2. Consider that we should throw on invalidation if Redis server is older then 3.2, to make people more aware of requirements. If so I'll want to be able to reuse get hosts logic inRedisTrait::doClear by moving it to own method.

Handle case where people switch adapters

The logic looks great for robustness - there is a missing\is_array($value) somewhere btw, isn't it?
An additional measure could be to generate a different namespace.CachePoolPass::getNamespace() could add the class of the adapter to the hash, don't you think?

Consider that we should throw on invalidation if Redis server is older then 3.2

would be a contracts break -invalidateTags() should return false and when a logger is provided to the adapter, this should be logged for sure

The logic looks great for robustness - there is a missing \is_array($value) somewhere btw, isn't it?
An additional measure could be to generate a different namespace. CachePoolPass::getNamespace() could add the class of the adapter to the hash, don't you think?

that would be an alternative, and probably cleaner. Any prefs besides what you wrote?
This is actually not an issue for FilesystemAdapters as they usestatic::class ingetFile()

Consider that we should throw on invalidation if Redis server is older then 3.2

would be a contracts break - invalidateTags() should return false and when a logger is provided to the adapter, this should be logged for sure

hmm, silently fail then. Maybe this is a feature request to requirements handling for symfony, to not have to look that up on runtime?

any prefs?

Doing both :)

silently fail then.

The constructor can throw

Doing both :)

ok with the namespace thing as separate PR?

The constructor can throw

I'd rather not do the requirement check with server lookup on every request, this is why I proposed to align with doClear and do it on demand on call todoInvalidate().

@nicolas-grekas Updated

EDIT: Added test for the namespace being seeded by adapter name.

Thank you@andrerom.

Just to make clear, to be able to run this code on Platform.sh (eZ Cloud/Symfony Cloud) you have following options:

1. PHP7.3: which comes with redis4.3.0
2. PHP7.2: disable redis extension (3.1.2) and installpredis/predis. And this option might be not very obvious.

@SerheyDolgushev It's needed for sPOP support which was added in 3.1.3:https://github.com/symfony/symfony/pull/30370/files#diff-410efc18de675a67676caaf96a22be12R174

So this, and Redis 3.2+ is a hard requirement for the RedisTagAwareAdapter.

If you are not able to get platform.sh to update the extension they use on PHP 7.1-72, then either use PHP 7.3, predis or FileSystemTagAwareAdapte(skip this option if you run cluster like Platform.sh Enterprise PE-6+. Professional and PE-[X]XL however is fine as they only run one web server at a time).

Do you see anything that could have been more clear in the exception to make this even more clear?