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

Alternative connection via --conn option is ignored #1160

Open
alexgit2k opened this issue May 19, 2021 · 21 comments
Open

Alternative connection via --conn option is ignored #1160

alexgit2k opened this issue May 19, 2021 · 21 comments

Comments

@alexgit2k
Copy link

Bug Report

Summary

In #1023 the option to allow alternative connections via --conn option was added. However as also stated in #1062 (comment) and #1062 (comment) an alternative connection specified via --conn option is ignored and the default connection is used instead.

Current behavior

Default connection is used.

How to reproduce

bin/console doctrine:migrations:migrate --dry-run -vvv --no-interaction --conn=migrations
doctrine:
    dbal:
        default_connection: default
        # configure these for your database server
        connections:
            default:
                url: '...'
            migrations:
                url: '...'

Expected behavior

Alternative connection should be used.

@goetas
Copy link
Member

goetas commented May 21, 2021

can you please tell us which version of the doctrine migrations bundle are you using?

@alexgit2k
Copy link
Author

@goetas: of course the latest release:

$ ./vendor/bin/doctrine-migrations -v
Doctrine Migrations 3.1.2@1c2780df6b58998f411e64973cfa464ba0a06e00

@dant89
Copy link

dant89 commented Jun 18, 2021

Experiencing the same issue with:

php bin/doctrine-migrations -v
Doctrine Migrations 3.1.0@260991be753a38aa25b6f2d13dbb7f113f8dbf8f

@goetas
Copy link
Member

goetas commented Jul 26, 2021

can you please tell us which version of the doctrine migrations bundle are you using?

Are you using the symfony bundle? if yes, what is the bundle version (not the migrations lib)

@ureimers
Copy link

Hi,
as I have the same problem (stated in #1062 (comment)), I switched to the DEV branch of the migrations bundle, just to be sure not to miss any unreleased fix to this:

doctrine/doctrine-migrations-bundle      3.2.x-dev fda5e69
doctrine/migrations                      3.2.0

It doesn't matter what is defined as the --conn parameter, it seems to be simply ignored:

bin/console doctrine:migrations:migrate -n --conn=this-connection-does-not-exist

 [OK] Already at the latest version ("DoctrineMigrations\Version20210727091159")

@goetas
Copy link
Member

goetas commented Aug 23, 2021

@ureimers hmm. that is weird and looks like a big :(

@goetas
Copy link
Member

goetas commented Aug 23, 2021

So, after looking into the issue, there is a problem when there is only the default entity manager... the --conn option is ignore and always the entity manager connection is choosen.

could you share your doctrine migrations and doctrine connection configs?

@ureimers
Copy link

Hi @goetas,
I was away for a month, so please excuse the late response. Here are my configurations (I removed some internal bundle names):

# doctrine.yaml

doctrine:
    dbal:
        default_connection: default
        connections:
            default:
                url: '%env(resolve:DATABASE_URL)%'
                charset: UTF8
            live:
                url: '%env(resolve:LIVE_DATABASE_URL)%'
                charset: UTF8
            user:
                url: '%env(resolve:USER_DATABASE_URL)%'
                charset: UTF8
            live_user:
                url: '%env(resolve:LIVE_USER_DATABASE_URL)%'
                charset: UTF8
            log:
                url: '%env(resolve:DATABASE_URL)%'
                charset: UTF8

    orm:
        auto_generate_proxy_classes: true
        default_entity_manager: default
        entity_managers:
            default: &doctrine_default_entity_manager
                connection: default
                naming_strategy: doctrine.orm.naming_strategy.underscore_number_aware
                mappings:
                    # [...] lots of custom bundles
                    FOSUserBundle: ~
                    SonataUserBundle: ~
                dql:
                    numeric_functions:
                    # [...] some DQL functions
            live:
                <<: *doctrine_default_entity_manager
                connection: live

            user:
                <<: *doctrine_default_entity_manager
                connection: user
# doctrine_migrations.yaml

doctrine_migrations:
    services:
        'Doctrine\Migrations\Version\MigrationFactory': 'App\Migrations\MigrationFactoryDecorator'
    migrations_paths:
        # namespace is arbitrary but should be different from App\Migrations
        # as migrations classes should NOT be autoloaded
        'DoctrineMigrations': '%kernel.project_dir%/migrations'

@goetas
Copy link
Member

goetas commented Nov 13, 2021

hmm, that seems weird. is there a way to reproduce this somehow in a failing test case?

@feosys
Copy link

feosys commented Nov 15, 2021

has it already been fixed?

@goetas
Copy link
Member

goetas commented Nov 16, 2021

has it already been fixed?

you did not mange to reproduce it? or you saw a commit fixing it?

@mussbach
Copy link

I face the same issue and you seem to be right:

So, after looking into the issue, there is a problem when there is only the default entity manager... the --conn option is ignore and always the entity manager connection is choosen.

This is the case for us as well.
As I am not very familiar with the code: Where do you suggest to locate the Test?

@goetas
Copy link
Member

goetas commented Dec 26, 2021

@mussbach so you have one entity manager and multiple connections, right?

and commands and diff will need to the entity manager, while the commands as migrate will need to choose on which connection to run.

So my question is: why do you have two connections if you have only one entity manager? what is doing the other connection?

@mussbach
Copy link

Yes, you understood it correctly.
Our usecase is that we have a privileged user with alter (and some more) rights that we want to use only during migration to keep the permission set for the „ordinary“ user as small as possible.
Both users need the same entities to be managed.

@Kleinast
Copy link

I tried to update from 2.x to 3.4 and have the same error with multiple connection.
Is there a workaround or a commit who fix it ?

Thx in advance

@schodemeiss
Copy link

I have the same issue. I have 2 connections, lets say "default" and "database_2" but only one Entity Manager on "default" (my second connection doesn't need Entities.

If I provide "--conn database_2" to any of the migration commands, it always falls back to the "default".

Any ideas how to sort this?

@ToGoLimango
Copy link

ToGoLimango commented Jul 7, 2022

i could solve this for me by adding "connection: migrations to doctrine_migrations.yaml (or the connection you need than)

so at the end its looking like this:

doctrine_migrations:
    connection: migrations
    migrations_paths:
        'DoctrineMigrations': '%kernel.project_dir%/migrations'

@kSHerstyanikov
Copy link

has it already been fixed?

@revilon1991
Copy link

While we are waiting for the fix we can use flag --em instadeof --conn.
Just don't forget to configure an enity manager and set nessasary connection.

# config/packages/doctrine.yaml
doctrine:
    dbal:
        default_connection: default
        connections:
            default:
                url: '%env(resolve:DATABASE_URL)%'
                # ...
            migrations: # <--- connection for migration
                url: '%env(resolve:DATABASE_MIGRATIONS_URL)%'
                # ...
    orm:
        default_entity_manager: default
        entity_managers:
            default:
                connection: default
                # ...
            migrations: # <--- orm manager for connection
                connection: migrations
                # ...

and run

php bin/console doctrine:migrations:migrate --no-interaction --em=migrations

@cavasinf
Copy link

Same case here..
Using @revilon1991 solution seems to work,
but we should test every possible case before.

Because with the mapping,
we have Bundle that add a CompilerPass, and this doesn't work with other EntityManager.

        $mappings = [
            realpath(__DIR__ . '/Resources/config/doctrine') => 'Allsoftware\SymfonyBundle\Entity',
        ];

        $container->addCompilerPass(
            DoctrineOrmMappingsPass::createXmlMappingDriver(
                $mappings,
                ['allsoftware.symfony.model_manager_name'],
                'allsoftware.symfony.backend_type_orm'
            )
        );

Result of php bin/console debug:config doctrine:

doctrine:
    orm:
        entity_managers:
            default:
                [...]
                mappings:
                    App:
                        is_bundle: false
                        type: attribute
                        dir: /var/www/html/src/Entity
                        prefix: App\Entity
                        alias: App
                        mapping: true
+                   AllsoftwareSymfonyBundle:
+                       type: attribute
+                       dir: src/Model
+                       prefix: Allsoftware\SymfonyBundle\Model
+                       mapping: true
            client1:
                [...]
                mappings:
                    App:
                        is_bundle: false
                        type: attribute
                        dir: /var/www/html/src/Entity
                        prefix: App\Entity
                        alias: App
                        mapping: true

@HaiD84
Copy link

HaiD84 commented Aug 1, 2023

The problem seems to be with Doctrine\Bundle\MigrationsBundle\DependencyInjection\CompilerPass\ConfigureDependencyFactoryPass.
If preferred connection/em not defined and there is any entity manager then DependencyFactory::fromEntityManager is used, effectively ignoring --conn option.
Like already mentioned possible workaround would be to add connection parameter to doctrine_migrations.yaml. That way DependencyFactory::fromConnection will be used, allowing --conn option, but now ignoring --em.

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