Skip to content
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

EntityManagerDecorator's repositories use EntityManager #5820

Open
anton-kotik opened this issue May 11, 2016 · 8 comments
Open

EntityManagerDecorator's repositories use EntityManager #5820

anton-kotik opened this issue May 11, 2016 · 8 comments

Comments

@anton-kotik
Copy link

anton-kotik commented May 11, 2016

Repositories created by Doctrine\ORM\Decorator\EntityManagerDecorator use EntityManager instead of EntityManagerDecorator:

use Doctrine\ORM\EntityManager;
use Doctrine\ORM\Decorator\EntityManagerDecorator;

$entityManager = EntityManager::create($dbParams, $config);
$entityManager->getRepository('entity')->getEntityManager();
// returns: Doctrine\ORM\EntityManager

class TestDecorator extends EntityManagerDecorator 
{
    // ...
}

$decorator = new TestDecorator($entityManager);
$decorator->getRepository('entity')->getEntityManager();
// returns: Doctrine\ORM\EntityManager
// expected: TestDecorator ?

This behavior may be unexpected for custom repositories using decorator object.

@Majkl578
Copy link
Contributor

Hello, I'm afraid this is not something we can fix. Since we're talking about decorator pattern, inner EM instance has no knowledge about being decorated. One possible solution would be using RepositoryFactory that is created for your decorator, not for inner EM by default.

@Isinlor
Copy link
Contributor

Isinlor commented Mar 28, 2018

Just to give people reading this a well visible notice.

There is a similar issue to this one with transactional method: #7161

@stof
Copy link
Member

stof commented Apr 27, 2018

The difference is that #7161 can workaround it, while this one cannot

@stof
Copy link
Member

stof commented Apr 27, 2018

I think event objects will also have the inner EM (as well as any place receiving the EM from the EM itself as $this)

@Isinlor
Copy link
Contributor

Isinlor commented Apr 27, 2018

Actually it does have a workaround:

class CustomDecorator extends EntityManagerDecorator {

    protected $repositoryFactory;

    // In Symfony 2.* $config can be injected with @doctrine.orm.default_configuration
    public function __construct(EntityManagerInterface $wrapped, Configuration $config)
    {
        $this->repositoryFactory = $config->getRepositoryFactory();
        parent::__construct($wrapped);
    }


    /**
     * Gets the repository for an entity class.
     *
     * Fixes: https://github.com/doctrine/doctrine2/issues/5820
     *
     * @param string $entityName The name of the entity.
     *
     * @return \Doctrine\ORM\EntityRepository The repository class.
     */
    public function getRepository($entityName)
    {
        return $this->repositoryFactory->getRepository($this, $entityName);
    }

}

@githoober
Copy link

githoober commented May 22, 2018

And then you find that SQLBuilder also has a wrapped entity manager instance, you fix that, only to find that all collections also have the wrapped instance embedded. In the end, there is no point in using a decorated entity manager because of that because it's impossible to make it work.

@andrews05
Copy link
Contributor

Any workaround for getting the decorator in lifecycle callbacks?

@lxmltj
Copy link

lxmltj commented Jul 13, 2021

class CustomDecorator extends EntityManagerDecorator {

    /**
     * {@inheritDoc}
     */
    public function createQueryBuilder()
    {
        return new QueryBuilder($this);
    }

}

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

No branches or pull requests

7 participants