Open darckking opened 8 months ago
Filters in DoctrineORMModule configuration are passed on through to the ORM. Avoiding any work on the EntityManager before it is explicitly called, such as $entityManager->getFilters()->enable('filter')
is avoided e.g. https://www.doctrine-project.org/projects/doctrine-orm/en/2.17/reference/filters.html#disabling-enabling-filters-and-setting-parameters
I think the Laminas way to do this is to subscribe to a modules post load function to do fine-grained configuration. I think this is an interesting question.
Currently the Doctrine filters can be added to EntityManager's Configuration object by providing them in configuration array as:
However, they're disabled by default and need to be explicitly enabled by calling $entityManager->getFilters()->enable('filter-name') Usually, I'd put filters initialization in Module, that implements BootstrapListenerInterface, inside the onBootstrap() function but if application uses laminas-cli this function won't be called as laminas-cli doesn't lift the whole app.
In ideal scenario filters should be configured and enabled in one place and it should work for both web and cli. Just like it works in Doctrine Bundle for Symfony.
I looked in EntityManager internals and the $filterCollection property is initialized only on the first call of getFilters(), hence filters can be enabled only after EntityManager was instantiated.
So what's the opinion about it, should it be in scope of DoctrineORMModule to enable filters like Doctrine Bundle for Symfony does or it's up to users to enable them ?