Add support for PHP 8.4 to version 6

[visto9259]

Feature Request

What

Support for PHP 8.4 should be added to version 6 of this package

Why

PHP 8.4 is now publicly available.
Lack of PHP 8.4 support prevents Laminas based projects using this component from upgrading to PHP 8.4

How

• Update composer.json to add PHP 8.4 in the platform requirements.
• Update other dependencies on Laminas components as some may not be required or included in other dependenccies. For example, laminas-mvc includes already many dependencies that may not need to be explicitely defined.
• This can only be achieved once all the Laminas dependencies have also added support for PHP 8.4 (in progress)

[driehle]

@visto9259

Unfortunately, v6 of DoctrineORMModule cannot support PHP 8.4. We will need to make a new major release, probably including BC breaks.

The reason is as follow: Many of the Laminas packages relevant to this module (including forms, inputfilter, mvc and view) do not yet support laminas-servicemamager v4 and rely still on v3. Therefore, we cannot got for servicemamager v4 yet. Besides, laminas-cache v3 does not support PHP 8.4. The Laminas-cache v4 does, but that one again need servicemamager v4, which we cannot go for, as explained. Hence, while requiring laminas-cache we are stuck to PHP 8.3.

My preferred solution is to get rid of laminas-cache, by replacing it with symfony/cache. The symfony package fits the Doctrine ecosystem quite well. After switching to symfony/cache, we could support PHP 8.4. However, we would need to make a new major of DoctrineModule, as changing the cache would change it's implementation from the Laminas interfaces to PSR-6.

Let me know what you think.

[visto9259]

@driehle
You should not attempt to require service-manager v4 until the Laminas project figures out how to use v4 in MVC related components and this is one of them.

If it is really laminas-cache v3 not supporting PHP 8.4 that is the issue, that can be fixed on Laminas's side and I can work with the team to release a version of laminas-cache v3 that runs on PHP 8.4.

No one should be forced into a major upgrade because of PHP 8.4.

[visto9259]

and BTW, when the Doctrine project decides to create a v7 of this component, it should best avoid having one huge package that provides Doctrine support for many Laminas components all at once. It would be better to have separate packages for Form, Validator, Paginator, etc.
It would be more work but it would make the upgrade easier.
I am sure that we can find people with Laminas knowledge like me to help out.
Maybe start a new organization dedicated to that if the Doctrine project finds that this is too much work that steers focus away from the main objective.

[driehle]

@visto9259

You should not attempt to require service-manager v4 until the Laminas project figures out how to use v4 in MVC related components and this is one of them.

Agree, the time for Doctrine(ORM)Module to got for service-manager v4 has not yet come IMO.

If it is really laminas-cache v3 not supporting PHP 8.4 that is the issue, that can be fixed on Laminas's side and I can work with the team to release a version of laminas-cache v3 that runs on PHP 8.4.

I do, however, thinkg that switching from laminas-cache to symfony/cache is benefitial for DoctrineModule, for the following reasons:

1. At the current time, laminas-cache is hindering DoctrineModule from supporting PHP 8.4. It is the only dependency which does so. While this could be solved on the end of laminas-cache, as you mention, there are further reasons for switching to symfony/cache.
2. The idea of DoctrineModule is to bring everything you need to run Doctrine, either ORM or ODM. They will always need a cache. So a cache setup should be included. Laminas makes this quite comlex, as the adapters are shipped with different packages. Can we just ship the configuration in our end? The configuration then will not work for the end user, without installing additional packages. Having all adapters in the symfony/cache packages makes configuration and usage much easier.
3. symfony/cache has ~250 million installs on Packagist, while laminas-cache has only ~5 million installes. That makes symfony/cache the much more popular package, having a much greater chance to be maintained in the long run.
4. In the Doctrine ecosystem, it is very common to cache metadata (i.e. ORM metadata) in the filesystem. Especially the laminas-cache adapter filesystem has a serious drawback: For caching objects, it requires laminas-serializer, a package which is abandoned. I did not find a way to get laminas filesystem cache running without laminas-serializer. While a future version might release this constraint, the constraint currently still exists.
5. Doctrine, at least ORM, requires cache adapters of PSR-6, which are not supported by laminas-cache v3. I am aware that laminas-cache v4 brings PSR-6, but as mentioned before, going for service-manager v4 is not (yet) an option. So we will be stuck with a non-PSR-6 cache. Currently, this is solved by wrapping the laminas-cache in a doctrine/cache object, but using doctrine/cache is deprecated from the side of doctrine/orm. The new ORM v3 has dropped these interfaces, requiring PSR-6. Hence, if we want to support ORM v3 in near future, we will need a pure PSR-6 library, which laminas-cache (in v3) is not.

Alltogether, arguments for switching to symfony/cache are overwhelming.

when the Doctrine project decides to create a v7 of this component, it should best avoid having one huge package that provides Doctrine support for many Laminas components all at once. It would be better to have separate packages for Form, Validator, Paginator, etc.

I am not a fan of such an option. First of all, I am currently the only maintainer for the Laminas integrations in the Doctrine team. Maintaining a few more projects is simply not feasible.

Second, looking at what is happening to laminas-cache, I am in general not a big fan of splitting things into too many small pieces. The Laminas project is clearly suffering from a lack of contributions, partly - so do I think - because the ecosystem has grown to be too complex. Let's keep it simple and try to keep things together where they belong.

I am sure that we can find people with Laminas knowledge like me to help out.

The greatest help you could probably provide currently is in adding support to laminas-servicemanager v4 to the remaining components. These are, in no specific order:

• laminas-filter
• laminas-i18n
• laminas-inputfilter
• laminas-mvc
• laminas-router
• laminas-view

[visto9259]

@driehle
I looked at laminas-cache v3 and to add support for PHP 8.4 will be quite a chore. Since I am not an expert at caching, your opinion on using Symfony/cache should be the right one. If the use of caching is "hidden" to the users of DoctrineORMModule, then this is probably the best course of action.

The ServiceManager v4 upgrade is a real pain for MVC components. It's the plugin manager that has changed between V3 and V4, and the versions are not backward compatible. Therefore any component that uses a plugin manager needs to create a new major version. laminas-mvc itself needs a major uplift and it is not getting much attention from the Laminas Project as everyone in the team is more focused on Mezzio. Lack of maintainers on the project has been and continues to be a major issue. Doing maintenance work is not as interesting as working on new stuff for many people. Lack of maintenance makes an ecosystem less interesting which in turn makes it less interesting for people to contribute.

[froschdesign]

@driehle

Laminas makes this quite comlex, as the adapters are shipped with different packages. Can we just ship the configuration in our end? The configuration then will not work for the end user, without installing additional packages. Having all adapters in the symfony/cache packages makes configuration and usage much easier.

I think something has been overlooked here: laminas-cache follows the idea of Composer who describes himself like this: "A Dependency Manager for PHP". And APCu, Memcached or Redis are dependencies, therefore it is correct to list these dependencies in the Composer configuration. But if all extensions in one package are required, you can hardly install the package. Therefore the satellite packages for the different adapters.
symfony/cache ignores the Composer here and moves the check for extensions to the runtime of an application instead of checking during installation.
From the user's point of view, I would say that neither solution is optimal or without hurdles.

---

With the background that this package is a module for Laminas and Mezzio, I think other questions should be asked:

• Does the laminas-mvc or Mezzio user really want to use symfony/cache or another library instead of laminas-cache?
• Or does the laminas-mvc or Mezzio user really want to use two cache libraries?
• Why should not the user have a free choice? (nette/caching is not bad and has a smaller footprint than symfony/cache)
• Is ignoring PSR a good idea here?

[driehle]

@froschdesign

I get your point, yet I disagree. Are you considering that the caches provided by DoctrineModule are not primarily intented to be used by the end user but rather needed for the configuration of Doctrine?

In 2.x, Doctrine provides Configuration::setMetadataCacheImpl(\Doctrine\Common\Cache\Cache $cache) and Configuration::setMetadataCache(\Psr\Cache\CacheItemPoolInterface $cache). The first one is deprecated, as the whole doctrine/cache library is deprecated, and has been removed in 3.x.

So to get Doctrine running and having at least a metadata cache set up (I consider this mandatory), we need a PSR-6 cache if we want to support Doctrine ORM v3 in the near future. I think nette/caching (have never used it) is only providing PSR-16, if I scaned the docs correctly? laminas-cache, besides the issues with servicemanager mentioned previously, is quite limited in terms of PSR-6, only the adapters Dba, Filesystem, Memory and Session support this (according to the docs). With Dba beeing abandoned and Session not being of any use for caching Doctrine stuff, only Filesystem and Memory remain.

I think that DoctrineModule should provide a setup of Doctrine ORM/ODM that works out of the box and that would at least include a metadatacache.

[froschdesign]

…is quite limited in terms of PSR-6, only the adapters Dba, Filesystem, Memory and Session support this (according to the docs).

The documentation says:

The PSR-6 specification requires that the underlying storage support time-to-live (TTL), which is set when the item is saved. For this reason the following adapters cannot be used: Dba, Filesystem, Memory and Session. The XCache adapter calculates TTLs based on the request time, not the time the item is actually persisted, which means that it also cannot be used.

https://www.php-fig.org/psr/psr-6/#definitions

[driehle]

Ok, my fault. Misread it, but that makes it worse. Filesystem cache is very essential and common for Doctrine's metadata.

[froschdesign]

…we need a PSR-6 cache if we want to support Doctrine ORM v3 in the near future.

I didn't know that before, thanks for the hint. It's definitely important that there is PSR support.

I think that DoctrineModule should provide a setup of Doctrine ORM/ODM that works out of the box and that would at least include a metadatacache.

This makes sense but I would still allow a choice. Maybe different configurations can be supplied or CLI commands, but I wouldn't pin it down to a specific library – by this I also explicitly mean laminas-cache.

…but that makes it worse. Filesystem cache is very essential and common for Doctrine's metadata.

The Filesystem adapter of laminas-cache fully supports PSR-6 and PSR-16! (I will update the documentation.)

---

Please do not get me wrong, I am not saying that laminas-cache should be used here, but I am pointing out that the laminas-cache component is already present in a laminas-mvc based application.