Centralize CollectionCacheKey instantiation and make it easy to override #6991

New Issue

admin · 2026-01-22T15:42:42+01:00

admin commented

2026-01-22 15:42:42 +01:00

Originally created by @umpirsky on GitHub (Jun 14, 2022).

Feature Request

Q	A
New Feature	no
RFC	no
BC Break	no

Summary

There are cases when running different PHP versions, or caching library versions on different servers (multi server environment). This is during the upgrades when you need to update servers one by one. And they are sharing the same cache, which sometimes lead to incompatibility issues.

In this case, it is beneficial to be able to separate caches (cache keys) depending on the PHP version or whatever you find important and conflicting.

If we look at new CollectionCacheKey instantiation, we can see that it's spread across multiple services which makes it hard to override.

Do you think this is something that is worth centralizing, or there are smarter approaches to separating this caches?

Thanks.

Originally created by @umpirsky on GitHub (Jun 14, 2022). ### Feature Request | Q | A |------------ | ------ | New Feature | no | RFC | no | BC Break | no #### Summary There are cases when running different PHP versions, or caching library versions on different servers (multi server environment). This is during the upgrades when you need to update servers one by one. And they are sharing the same cache, which sometimes lead to incompatibility issues. In this case, it is beneficial to be able to separate caches (cache keys) depending on the PHP version or whatever you find important and conflicting. If we look at [new CollectionCacheKey](https://github.com/doctrine/orm/search?q=new+CollectionCacheKey) instantiation, we can see that it's spread across multiple services which makes it hard to override. Do you think this is something that is worth centralizing, or there are smarter approaches to separating this caches? Thanks.

admin commented

2026-01-22 15:42:43 +01:00

@derrabus commented on GitHub (Jun 14, 2022):