Doctrine filters

[djoos]

Hi there,

when implementing a Doctrine filter (eg. UserAware), the results get filtered correctly (hydra:member), however the paginator's query doesn't seem to pick up the filter, so the hydra:totalItems and hydra:view are incorrect...

    "hydra:member": [],
    "hydra:totalItems": 61,
    "hydra:view": {
        "@id": "/foos?page=1",
        "@type": "hydra:PartialCollectionView",
        "hydra:first": "/foos?page=1",
        "hydra:last": "/foos?page=6",
        "hydra:next": "/foos?page=2"
    }

I'll dig deeper into the issue, but any heads up is appreciated - thanks in advance!

Kind regards,
David

[soyuka]

My first though was that extension priorities are wrong, but it looks fine (filters are applied before the pagination). To look further you'd need to inspect what's going on here.

Lmk how this turns out. We may want to start with a behat test too see if bug there is.

[djoos]

A quick update - after picking this up just now again...

I spotted in the PartialConnectionViewNormalizer that $data looked like:

Array
(
    [@context] => /contexts/Project
    [@id] => /projects
    [@type] => hydra:Collection
    [hydra:member] => Array
        (
        )

    [hydra:totalItems] => 61
)

So, hydra:member is correct while hydra:totalItems is incorrect.

Digging deeper, I spotted in the CollectionNormalizer that the $object->getTotalItems() differs from count($object): 61 (incorrect) vs. 0 (correct)

The paginator object used to instantiate the Paginator carries the issue with it already, as the $paginator->getQuery() doesn't respect the Doctrine filter, so the count($paginator) returns an incorrect (as in: unfiltered) count, causing the issues further downwards.

Not sure yet where the src/Bridge/Doctrine/Orm/Paginator-object gets instantiated, but that'll be my next step.

TBC!

[djoos]

The instantiation of the Paginator happens in the PaginationExtension.

The CollectionDataProvider lists the following extensions:

ApiPlatform\Core\Bridge\Doctrine\Orm\Extension\EagerLoadingExtension
ApiPlatform\Core\Bridge\Doctrine\Orm\Extension\FilterExtension
ApiPlatform\Core\Bridge\Doctrine\Orm\Extension\FilterEagerLoadingExtension
ApiPlatform\Core\Bridge\Doctrine\Orm\Extension\OrderExtension
ApiPlatform\Core\Bridge\Doctrine\Orm\Extension\PaginationExtension

...so, including the PaginationExtension, which kicks in and whose getResult-method is oblivious to the Doctrine filter.
That brings me back to the CollectionDataProvider where the query builder is instantiated...

TBC!

[djoos]

Some further inspection shows that the Doctrine filter is executed for pagination purposes before my Configurator is called (which sets the annotation reader as well as the field + value to filter upon), hooked up on kernel.request. Obviously the filter returns rather than adding the filter query as required data is not set - when I, instead of letting the Configurator do this upon kernel.request, hard-code values in the filter, the pagination is fixed and everything is ok.

So, why is the Doctrine filter called for pagination purposes in API Platforms' PaginationExtension before kernel.request? kernel.request which is documented as:
"The REQUEST event occurs at the very beginning of request dispatching. This event allows you to create a response for a request before any other code in the framework is executed." #puzzled

[djoos]

Aha!

API Platform's ReadListener kicks off the ChainCollectionDataProvider > CollectionDataProvider -> PaginationExtension -> Paginator upon kernel.request, with priority 4.

The Doctrine filter's configurator is also tagged with kernel.request, but without using any priority parameter. So, when using Doctrine filters you need to make sure to have it kick in prior to the API Platform's ReadListener: I've upped the priority to > 4 and... voila: the pagination is correct now!

tags:
    - { name: kernel.event_listener, event: kernel.request, priority: 5 } # priority > 4

Result:

    "hydra:member": [],
    "hydra:totalItems": 0,

And "hydra:view" is omitted, as expected.

Hope this helps someone in the future when dealing with Doctrine filters!

[Simperfit]

Thanks for this @djoos do you mind creating a PR on the docs about this ?

[djoos]

Sure, no problem!

[soullivaneuh]

Should not this priority be automatically set if not specified?

It would be error-less than a line on the doc, in my opinion.