You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The Doctrine\ODM\MongoDB\Configuration::AUTOGENERATE_FILE_NOT_EXISTS configuration option should prevent the proxy generator from generating a given proxy file if it already exists, but actually the proxy file is regenerated on each request.
Current behavior
Even though Configuration::setAutoGenerateProxyClasses() is called with Configuration::AUTOGENERATE_FILE_NOT_EXISTS the proxy generator regenerates each affected proxy file once per request.
How to reproduce
Make sure document proxies are generated. Then in a separate process use DocumentManager::getReference() with a document that is not in the identity map - it will causes proxies to be regenerated.
Expected behavior
Generated proxy file should not change?
If you take a look here at what this configuration option in fact does when set, it turns out it simply changes proxy generator strategy. And inspecting the set FileWriterGeneratorStrategy and the FileLocator it uses, it can be seen that there is no file_exists check in place (and it seems it has never existed, which means this never worked?).
I guess a custom decorator for \ProxyManager\GeneratorStrategy\GeneratorStrategyInterface, that would check the existence of the file and wrap the original strategy would solve the issue. However, this would probably mean that proxies are no longer automatically regenerated for dev/debug environments in projects using this library. Which would mean that proxies do not contain up-to-date metadata for document classes that were edited until they are manually regenerated or unless some alternative tracking method is introduced.
What should be the course of action here?
The text was updated successfully, but these errors were encountered:
After some discussion, this is somewhat expected: the documentation recommends registering an autoloader for production, which doesn't happen. In this case, we'd expect the framework integration (e.g. doctrine/mongodb-odm-bundle) to take care of this. I've created doctrine/DoctrineMongoDBBundle#519 to track this in the bundle.
For users that aren't using the bundle, we'll need to add this bit to the documentation. I'm leaving this issue open to track that. Thanks for investigating this!
Since the autoloader coming with ProxyManager is quite naïve, this is best left to the composer autoloader, if build and run steps can be clearly separated.
Bug Report
Summary
The
Doctrine\ODM\MongoDB\Configuration::AUTOGENERATE_FILE_NOT_EXISTS
configuration option should prevent the proxy generator from generating a given proxy file if it already exists, but actually the proxy file is regenerated on each request.Current behavior
Even though
Configuration::setAutoGenerateProxyClasses()
is called withConfiguration::AUTOGENERATE_FILE_NOT_EXISTS
the proxy generator regenerates each affected proxy file once per request.How to reproduce
Make sure document proxies are generated. Then in a separate process use
DocumentManager::getReference()
with a document that is not in the identity map - it will causes proxies to be regenerated.Expected behavior
Generated proxy file should not change?
If you take a look here at what this configuration option in fact does when set, it turns out it simply changes proxy generator strategy. And inspecting the set FileWriterGeneratorStrategy and the FileLocator it uses, it can be seen that there is no
file_exists
check in place (and it seems it has never existed, which means this never worked?).I guess a custom decorator for
\ProxyManager\GeneratorStrategy\GeneratorStrategyInterface
, that would check the existence of the file and wrap the original strategy would solve the issue. However, this would probably mean that proxies are no longer automatically regenerated for dev/debug environments in projects using this library. Which would mean that proxies do not contain up-to-date metadata for document classes that were edited until they are manually regenerated or unless some alternative tracking method is introduced.What should be the course of action here?
The text was updated successfully, but these errors were encountered: