migrations: Alternative connection via --conn option is ignored

Bug Report

Summary

In #1023 the option to allow alternative connections via --conn option was added. However as also stated in https://github.com/doctrine/migrations/issues/1062#issuecomment-801171576 and https://github.com/doctrine/migrations/issues/1062#issuecomment-807348508 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.

About this issue

Original URL
State: open
Created 3 years ago
Reactions: 1
Comments: 21 (7 by maintainers)

Most upvoted comments

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'

ToGoLimango on Jul 7, 2022

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.

mussbach on Dec 26, 2021

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?

mussbach on Dec 22, 2021

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

Kleinast on Feb 15, 2022