Allow usage of different entity managers/connections in CLI

[Ocramius]

It may be interesting to provide a helper (or custom Symfony Application) that replaces the EntityManager or DBAL Connection helpers based on a provided parameter such as --em=name_of_em_service

[jamiehannaford]

Was there anything fundamentally wrong with brettalewis' solution in commit 62d5592f3d9312c20ee3525b2b6e8466229ca084 apart from lack of testing?

[Ocramius]

That's terribly patched up, and adds the option to all commands (even not doctrine related). What I'm thinking of is to move everything to zf2 controllers instead

[nurikabe]

+1

[Mischosch]

any news on this issue? is anyone working on it?

[Ocramius]

This will be possible in doctrine/DoctrineModule#256

[Mischosch]

Can you give me a hint, which change makes it possible? I only found https://github.com/doctrine/DoctrineModule/pull/256/files#L3R87 these comments about alias usage.

Are any changes needed on DoctrineORMModule side for that?

[Ocramius]

@Mischosch the idea is that you have a doctrine.<something>.<name> configuration.

If you replace name with myem or secondconnection or customerdb it should work with 1.0.x. Didn't yet adapt the ORM module to it, but the mongo ODM module has an 1.0.x PR open to handle that

[vladar]

Any news on this? Is this possible now or maybe there are some workarounds for now?

[adamlundrigan]

Here's a workaround that worked for me: https://gist.github.com/adamlundrigan/c0c87fc5657453212cd0

[SwissEngine]

@vladar I created this small module https://github.com/SwissEngine/Doctrine-Module-Extension to implement --em=orm_custom for all commands from the CLI. Ocramius says it's not ideal but it works for the moment. 1.x seems dead.

[improved-broccoli]

What about this issue ? May I suggest a PR ?

[duncanfwalker]

@SwissEngine I just tried using your Doctrine-Module-Extension. It worked fine when the entity manager is call from some commands but when I run a migration command (eg doctrine-module orm:schema-tool:create --em=orm_alternative) it still just picks up the orm_default configuration. It looks to me like this is because of the following lines in DoctrineORMModule

Is that correct or have I just got my configuration wrong?

        // @TODO currently hardcoded: `orm_default` should be injected
        /* @var $configuration \Doctrine\DBAL\Migrations\Configuration\Configuration */
        $configuration = $serviceLocator->get('doctrine.migrations_configuration.orm_default');
        /* @var $command \Doctrine\DBAL\Migrations\Tools\Console\Command\AbstractCommand */
        $command       = new $className;

https://github.com/doctrine/DoctrineORMModule/blob/master/src/DoctrineORMModule/Service/MigrationsCommandFactory.php

[bvarent]

@duncanfwalker I have the same problem. It works for me (@SwissEngine thank you!) with migrations:diff as well as orm:schema-tool:create. But not with others, e.g. migrations:migrate. Indeed in the file you quoted lies the problem. The name of the migrations_configuration for the ZF2 module (doctrine.migrations_configuration.orm_default) is hard coded; see the TODO. However the entitymanager to be used by (some of the commands in) the migrations tool is not in said configuration and so SwissEngine's way of overriding the 'em' in the command's helper set works for those that use the em and/or connection from the helperSet. But other (migrations) commands do use the configuration which is created by the Doctrine ORM Module. Which sets the connection to orm.connection.X where X is the same as (that hard coded) orm.migrations_configuration.X.

So two problems (solving either solves our problem, but solving both would be best):

1. Name for the doctrine.migrations_configuration.X should not be hard coded.
2. Migrations tool sometime uses the connection from the passed Doctrine\DBAL\Migrations\Configuration and sometimes from the Entitymanager in the commands's helperSet. Imho, An entitymanager should be the basis always, instead of a DB connection.

-edit- duncanfwalker is right, it doesn't work with all migrations commands

[duncanfwalker]

thanks for taking the time to explain - I will have a look this when I next
come back to that project.

On 18 December 2015 at 20:54, bvarent notifications@github.com wrote:

@duncanfwalker https://github.com/duncanfwalker It works for me (
@SwissEngine https://github.com/SwissEngine thank you!) with migrations
as well as orm:schema-tool:create. It is unfortunate that the name of the
migrations_configuration for the ZF2 module (
doctrine.migrations_configuration.orm_default) is hard coded; see the
TODO in the file you quoted. However the entitymanager to be used by the
migrations tool is not in said configuration. And so SwissEngine's way of
overriding the 'em' in the command's helper set works here too.
Are you sure you've loaded the ZF module (
SwissEngine\Tools\Doctrine\Extension) by adding it to the modules key in
config\autoload\application.config.php? Although I think you have, given
that you indicate --em does work with other commands.
Also make sure your alternative entitymanager is configured with its own
doctrine.connection and doctrine.configuration (which in turn has its own
doctrine.driver).

—
Reply to this email directly or view it on GitHub
#97 (comment)
.

[alex-patterson-webdev]

I have 4 entity managers configured, none of which are called 'orm_default'. In this case the CLI doesn't event load.

Zend\ServiceManager\Exception\ServiceNotCreatedException: An exception was raised while creating "doctrine.entitymanager.orm_default"; no instance returned in /home/alex/www/sites/spectrum-v1/vendor/zendframework/zend-servicemanager/src/ServiceManager.php on line 946

I cannot simply add it as an service alias as it could be any of the 4 entity managers I need.

[trylika]

this issue is almost 4 years old... any news/solutions on it except for using https://github.com/SwissEngine/Doctrine-Module-Extension ?

[TomHAnderson]

Fixed with #524

[MatthiasKuehneEllerhold]

Sorry @TomHAnderson but the issue with doctrine-migrations still exist.

[TomHAnderson]

@MatthiasKuehneEllerhold thanks for chiming in. Because you are the only one to mention doctrine-migrations specifically I can't grok what part of this bug is still at issue. In my experience the failure to echo the commands as they are executed has been fixed.

If you are still having trouble will you please create a new ticket and explain the problem you still see.