webfactory / webfactory-visibility-filter-bundle Goto Github PK

Currently, the filtering will only be activated per request, due to the GetResponseEvent that OnRequestDependencyInjector listens to. Maybe there is a way to activate it for console commands, too.

This bundle is useful when you want to apply the same filter rule to multiple entitities but want to filter based on different columns per entitity.

In simpler use cases, you might as well just use a Doctrine filter.

In more complicated use cases (e. g. multiple columns or filtering that is not based on columns at all), you need a different solution.

Class ValueInField has a self-built logic to format the literals of the value. Doctrine should have a functionality for this that works independently from the underlying DBMS.

Zum Punkt

The filter class needs to be registered manually.

# src/config.yml
doctrine:
    orm:
        filters:
            visibility: Webfactory\VisibilityFilterBundle\Filter\StrategyConsideringSQLFilter

Aus der README:

Muss man das im Projekt schreiben? Geht das nicht über z.B. einen CompilerPass (idk!)? Falls man die Config wirklich braucht, sollte sie dann nicht im Bundle leben und man hier nur die Bundle-Config einbinden müssen? Dann müsste man z.B. auch nicht auf den Namen Acht geben/den erklären?

This project still has to support projects that run on 3.4. However, the testing infrastructure already depends on Symfony 4.4, and it's not worth porting it back to Symfony 3.4 as support for 3.4 ends in a few months.

To not make false promises, Symfony 3.4 support should be removed as soon as we don't have any projects depending on it any more.

Sometimes, different entities have different visibility strategies. However, most of the time multiple entities still share one strategy. There should be a way for mapping different entities to filter strategies. Maybe through the data type of the visibility column?

Giving examples for other visibility strategies - like many visibility grades, or date based visibility - could help making the value of this Bundle more clear.

Annotation reading and reflection can be expensive. Currenty, it is likely that the same annotation will be read even multiple times per request, but as Annotations don't change between deployments, the results of VisibilityColumnRetriever::getVisibilityColumn could be cached for the whole duration of a deployment.

The VisibilityColumnConsideringSQLFilterTest is currently built as a heavy integration test, with a simulated Symfony Kernel and stuff. This on the one hand complicates the setup process - we need to simulate a request to get the filter activated. It also obscures the exact testing conditions, e.g. which FilterStrategy is used.

Also, working around the Doctrine caching could be solved by porting it to our webfactory/doctrine-orm-test-infrastructure.

Also, each test performing multiple assertions could be split.

Also, OneToOne-Relationships are currently only tested with EAGER-Loading - this detail is not visible from the Test case, but hidden in the test entity. Different tests for EAGER and LAZY for documenting the different effects the visibility filter has on each one of them would be helpful.