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

3.2.2 --configuration does not work #495

Open
Redominus opened this issue May 5, 2022 · 10 comments
Open

3.2.2 --configuration does not work #495

Redominus opened this issue May 5, 2022 · 10 comments

Comments

@Redominus
Copy link

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

@GeneralCrime
Copy link

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:

@hackzilla
Copy link

hackzilla commented May 16, 2023

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.

@greg0ire
Copy link
Member

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?

@hackzilla
Copy link

@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

@greg0ire
Copy link
Member

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

@greg0ire
Copy link
Member

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 🤔 . 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?

@greg0ire
Copy link
Member

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.

@greg0ire greg0ire transferred this issue from doctrine/DoctrineMigrationsBundle May 17, 2023
@greg0ire
Copy link
Member

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.

@greg0ire greg0ire transferred this issue from doctrine/migrations May 17, 2023
@greg0ire
Copy link
Member

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.

@hackzilla
Copy link

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.

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

4 participants