Support filter parameters in Configuration

[jmikola]

Based on work done in doctrine/mongodb-odm#908

My understanding is that this makes it easier to setup filters at boot time, instead of having to fetch them from the collection later on.

For added context, the related PR from MongoDB ODM's Symfony bundle is doctrine/DoctrineMongoDBBundle#255

[doctrinebot]

Hello,

thank you for creating this pull request. I have automatically opened an issue
on our Jira Bug Tracker for you. See the issue link:

http://www.doctrine-project.org/jira/browse/DDC-3200

We use Jira to track the state of pull requests and the versions they got
included in.

[stof]

I would just use class

[jmikola]

I concur. Will make the change in ODM as well.

[Koc]

@jmikola what about adding possibility to disable/attaching filter per query?

[stof]

@Koc you can already enable or disable filters by using the FilterCollection.

the goal of this PR is to preset some filter parameters in the config

[Koc]

Of course this PR has other goal. Just if Jeremy starts working on improvements of filters maybe he can add some changes.

By the way, code like

$em->getFilters()->disable('ololo_filter');
// my query
$em->getFilters()->enable('ololo_filter');

looks ugly for me. And sometimes it non-acceptable. When you building dynamic query in several application layers, for example.

[jmikola]

@Koc: I have no plans to make additional filter improvements (too much on my plate already). This PR is just to ensure that ORM and ODM remain in sync.

/cc @lsmith77 in case you'd like this for PHPCR ODM.

[lsmith77]

i dont think we have filters at all in PHPCR ODM

/cc @dbu

[dbu]

no, we do not have filters in the SQL2 part of phpcr-odm. sounds like a potentially interesting feature eventually.

[Ocramius]

I think the correct solution here would be to pass in a new instance of a filter, which also removes this auto-instantiation thing, but there's also the fact that filters should not be THAT flexible. Ping @asm89

[jmikola]

@Ocramius: I don't see how we could do that without breaking BC, though. Unless $className was changed to conditionally accept an object (in which FilterCollection only needs getFilterClassName() for times when an object wasn't provided).

[Ocramius]

Need @asm89 to look at it to know why this was designed this way in first place

[Ocramius]

@asm89 ping?

[hanovruslan]

Sorry folks, i know this is not proper place for my issue but ...
i found that disabled filter with auto mapping also disabled causes error for this filter's parameters

doctrine:
    dbal:
        driver: %database_driver%
        host: %database_host%
        port: %database_port%
        dbname: %database_name%
        user: %database_user%
        password: %database_password%
        charset: %database_charset%
        server_version: %database_server_version%
        options:
            20: true #PDO::ATTR_EMULATE_PREPARES
    orm:
        auto_generate_proxy_classes: %kernel.debug%
        default_entity_manager: default
        entity_managers:
            default:
                metadata_cache_driver: apc
                query_cache_driver: apc
                result_cache_driver: apc
                naming_strategy: doctrine.orm.naming_strategy.underscore
                filters:
                    some_filter:
                        class: SomeNameSpace\SomeFilter
                        enabled: false
                        parameters:
                            name: value

will throw

\InvalidArgumentException("Parameter '" . $name . "' does not exist.");

for enabled by default filter it is ok

doctrine:
#
    orm:
#
        entity_managers:
            default:
#
                filters:
                    some_filter:
#
                        enabled: true

should i make PR with specific tests for this case or what?

Thanks!

[hanovruslan]

Sorry, any progress on this ?

[derrabus]

Please use https://github.com/doctrine/orm/discussions for support questions.