Do not enable the proxy autoloader or cache warmer when using native lazy objects #1906
Conversation
…ity managers configuration
…lazy objects, start running tests with native lazy objects enabled
cd45f02 to
b3a1a33
Compare
| throw new LogicException( | ||
| 'Native lazy objects are not supported with your installed version of the ORM. Please upgrade to "doctrine/orm:^3.4".', | ||
| ); | ||
| } |
There was a problem hiding this comment.
This is also missing a validation that PHP 8.4 is used, otherwise error because native lazy is not supported then. This would throw the error earlier than doctrine on configuration level, otherwise it would be delayed to runtime when ORM is used.
There was a problem hiding this comment.
Why would one set enable_native_lazy_objects to true when they are not at PHP8.4?
Besides that: It checks whether the ORM config has the necessary method to handle the config-value.
I'd rather check that setting enable_native_lazy_object to true is only possible starting with PHP8.4. So even if someone sets it ti true but runs the code on 8.3 it should get set to false automatically.
WDYT?
There was a problem hiding this comment.
I don't think it should be set to false silently. Maybe it's even possible to just not define the configuration node for PHP < 8.4
There was a problem hiding this comment.
Making configuration classes conditional on the PHP version is a bad idea: it makes it a mess to document the structure of the configuration and provides non-friendly error messages to the user ("configuration setting enable_native_lazy_object does not exist.", while they will see it in the documentation).
Note also that making conditional configuration in Yaml files is not possible, so this will make it impossible to write a recipe for the bundle that turns on the feature.
There was a problem hiding this comment.
Silently setting it to false (which is the same as just ignoring it) would allow people to configure it but it would not break when running on some not-supported system.
I can think of i.e. staging running on 8.4 but prod is still on 8.3 - silently setting it to false will allow one setting for both and it would run on both without issues.
There was a problem hiding this comment.
Silently setting it to false (which is the same as just ignoring it) would allow people to configure it but it would not break when running on some not-supported system.
The option is already effectively no-op'ed for PHP 8.3 and earlier in https://github.com/doctrine/DoctrineBundle/pull/1906/files#diff-e2aeb4a501e79bc8ebab5ea93069b5bbcd3eb9168d37bd78ddd43075cddb8cc4R722 (the Configuration::enableNativeLazyObjects() method call is only made on PHP 8.4+). So the "silently setting to false" thing is already happening in the tagged 2.15 releases.
There was a problem hiding this comment.
I can think of i.e. staging running on 8.4 but prod is still on 8.3
Is that something people actually do? Pushing the same code on 2 machines with different versions of PHP? It seems risky to me, for instance if you use a php 8.4-specific feature, this setup will cause an issue that surfaces only in production. Plus it's not like they could wait until production also uses 8.4 to enable native lazy objects.
There was a problem hiding this comment.
the ORM throws an exception if you are < 8.4 and use this setting.
https://github.com/doctrine/orm/blob/3.5.x/src/Configuration.php#L668
So that is the behavior that exists and we should not "change" this behavior to be something different, because thats confusing. What we can do is surface this error earlier, which we can do by doing the check here again, moving this to a "compile time" error instead of waiting for it to happen for runtime.
There was a problem hiding this comment.
67754db adds a throw at compile time for this.
|
Thanks for this! We’re running PHP 8.4 with ORM 3.4+ and switching to |
…nsupported PHP version
03149fe to
67754db
Compare
(Builds on top of #1905 and only the second commit is relevant to this PR).
This will fully resolve #1895 by no longer enabling the deprecated proxy autoloader when native lazy objects are in use.
As well, the proxy cache warmer will no longer be registered when native lazy objects are in use as the warmer doesn't really have a use when proxies aren't in use and it errors out when not configuring the deprecated proxy options (see #1898 (comment) and follow-on comments for more here).
Lastly, some of the tests are updated to run with native lazy objects enabled where the environment supports it.
Closes #1895