doctrine/DoctrineMigrationsBundle

3.2.2 --configuration does not work

Redominus opened this issue · 10 comments

Hi, I encountered a bug.
How to reproduce:
create a project with at least the default doctrine_migrations.yaml.
Try to load it using --configuration.

Migrations configuration key "doctrine_migrations" does not exist.

Also tried moving it to directories under src and using --em

Same problem here, but the key is the right key in the first line off configuration file. when you change it to annother string it say´s the string is not exists. In InvalidConfigurationKey.php line 16:

I've just come across this issue and couldn't find any example config.

I've managed to get it working by removing doctrine_migrations key.

migrations_paths:
    # namespace is arbitrary but should be different from App\Migrations
    # as migrations classes should NOT be autoloaded
    'DoctrineMigrations': './migration-support'
em: support

Assuming you have an entity manager call support and have migrations in migration-support directory.

I suspect these 2 lines come into play:

if (method_exists($treeBuilder, 'getRootNode')) {
$rootNode = $treeBuilder->getRootNode();
} else {
// BC layer for symfony/config 4.1 and older
$rootNode = $treeBuilder->root('doctrine_migrations', 'array');
}

Can you tell us which branch gets executed in your case?

@greg0ire For me its the first path.

$rootNode = $treeBuilder->getRootNode();

For reference this is the command I use to run the support migrations

bin/console doctrine:migrations:migrate --configuration=migration-support/doctrine_migration_support.yaml

Ah thanks for including the command you used, I didn't realize that was what was happening here.

How does this work? I think the command is defined in another package: https://github.com/doctrine/migrations/blob/3.6.x/lib/Doctrine/Migrations/Tools/Console/Command/MigrateCommand.php

But it does not have a --configuration flag :thinking: . All the bundle does is create a Symfony service for the command, with a custom name:

<service id="doctrine_migrations.migrate_command" class="Doctrine\Migrations\Tools\Console\Command\MigrateCommand">
<argument type="service" id="doctrine.migrations.dependency_factory"/>
<argument>doctrine:migrations:migrate</argument>
<tag name="console.command" command="doctrine:migrations:migrate" />
</service>

What version of doctrine/migrations (the lib, not the bundle) are you using?

Ah the flag is defined in a parent class: https://github.com/doctrine/migrations/blob/3.6.x/lib/Doctrine/Migrations/Tools/Console/Command/DoctrineCommand.php#L41-L46

Let's move this issue to the library then.

Reading the docs, there is no mention of a doctrine_migrations key. doctrine_migrations is the name of the extension loaded by the Symfony bundle, which is not involved at all here.

So I think if there is an issue, it's a documentation issue. Moving back the issue to the Symfony bundle.

I see 2 solutions:

  1. Document in the bundle that a file passed to --configuration should not have the prefix.
  2. Somehow make --configuration work with the prefix. I cannot imagine how that would work though.

Symfony creates a default config file for the migrations in config/packages/doctrine_migrations.yaml.

doctrine_migrations:
    migrations_paths:
        # namespace is arbitrary but should be different from App\Migrations
        # as migrations classes should NOT be autoloaded
        'DoctrineMigrations': '%kernel.project_dir%/migrations'
    enable_profiler: '%kernel.debug%'

By specifying the --configuration, you're telling it to use a completely different config.
In my case, we wanted to use a second entity manager, but doctrine migrations was still trying to create the new entities on the old manager.

I agree there should be more documentation around the --configuration parameter.

Though there is the option to get Symfony to dump the default/example config with bin/console debug:config DoctrineMigrationsBundle

doctrine_migrations:
    migrations_paths:
        DoctrineMigrations: /var/www/html/migrations
    enable_profiler: true
    services: {  }
    factories: {  }
    storage:
        table_storage:
            table_name: null
            version_column_name: null
            version_column_length: null
            executed_at_column_name: null
            execution_time_column_name: null
    migrations: {  }
    connection: null
    em: null
    all_or_nothing: false
    check_database_platform: true
    custom_template: null
    organize_migrations: false
    transactional: true

That helps with when trying to know what to Google.