Skip to content

CollectionDataProviderInterface does not play well with generators #1422

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
greg0ire opened this issue Oct 12, 2017 · 1 comment
Closed

CollectionDataProviderInterface does not play well with generators #1422

greg0ire opened this issue Oct 12, 2017 · 1 comment

Comments

@greg0ire
Copy link
Contributor

greg0ire commented Oct 12, 2017

I tried implementing it with generators, and it worked just fine... until... I implemented a second.

The problem is here:

public function getCollection(string $resourceClass, string $operationName = null)
{
foreach ($this->dataProviders as $dataProvider) {
try {
return $dataProvider->getCollection($resourceClass, $operationName);
} catch (ResourceClassNotSupportedException $e) {
continue;
}
}
}
}

Here is what my implementation looks like:

    public function getCollection(string $resourceClass, string $operationName = null)
    {
        if ($resourceClass !== Person::class) {
            throw new ResourceClassNotSupportedException();
        }

       yield $aPerson;

The ChainCollectionDataProvider will loop over my providers, and will immediatly return the generator returned by the first data provider because no code is executed until the generator is used inside a foreach, which happens later in the code, outside the try / catch block.

The solution would be to introduce a supports method in the interface.

greg0ire pushed a commit to greg0ire/core that referenced this issue Oct 12, 2017
This should make the collection data provider generator-friendly,
because it will allow deferring code execution to the piece of code
where the generator is iterated over instead of requiring it to be
executed inside the try/catch block.
Fixes api-platform#1422
greg0ire pushed a commit to greg0ire/core that referenced this issue Oct 12, 2017
This should make the collection data provider generator-friendly,
because it will allow deferring code execution to the piece of code
where the generator is iterated over instead of requiring it to be
executed inside the try/catch block.
Fixes api-platform#1422
greg0ire pushed a commit to greg0ire/core that referenced this issue Oct 12, 2017
This should make the collection data provider generator-friendly,
because it will allow deferring code execution to the piece of code
where the generator is iterated over instead of requiring it to be
executed inside the try/catch block.
Fixes api-platform#1422
greg0ire pushed a commit to greg0ire/core that referenced this issue Oct 12, 2017
This should make the collection data provider generator-friendly,
because it will allow deferring code execution to the piece of code
where the generator is iterated over instead of requiring it to be
executed inside the try/catch block.
Fixes api-platform#1422
greg0ire pushed a commit to greg0ire/core that referenced this issue Oct 12, 2017
This should make the collection data provider generator-friendly,
because it will allow deferring code execution to the piece of code
where the generator is iterated over instead of requiring it to be
executed inside the try/catch block.
Fixes api-platform#1422
greg0ire pushed a commit to greg0ire/core that referenced this issue Oct 12, 2017
This should make the collection data provider generator-friendly,
because it will allow deferring code execution to the piece of code
where the generator is iterated over instead of requiring it to be
executed inside the try/catch block.
Fixes api-platform#1422
greg0ire pushed a commit to greg0ire/core that referenced this issue Oct 13, 2017
This should make the collection data provider generator-friendly,
because it will allow deferring code execution to the piece of code
where the generator is iterated over instead of requiring it to be
executed inside the try/catch block.
Fixes api-platform#1422
greg0ire pushed a commit to greg0ire/core that referenced this issue Oct 19, 2017
This should make the collection data provider generator-friendly,
because it will allow deferring code execution to the piece of code
where the generator is iterated over instead of requiring it to be
executed inside the try/catch block.
Fixes api-platform#1422
greg0ire pushed a commit to greg0ire/core that referenced this issue Oct 19, 2017
This should make the collection data provider generator-friendly,
because it will allow deferring code execution to the piece of code
where the generator is iterated over instead of requiring it to be
executed inside the try/catch block.
Fixes api-platform#1422
greg0ire pushed a commit to greg0ire/core that referenced this issue Oct 19, 2017
This should make the collection data provider generator-friendly,
because it will allow deferring code execution to the piece of code
where the generator is iterated over instead of requiring it to be
executed inside the try/catch block.
Fixes api-platform#1422
@meyerbaptiste
Copy link
Member

Fixed by #1429.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants