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:
DoctrineMigrationsBundle/DependencyInjection/Configuration.php
Lines 37 to 42 in 05490c7
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:
DoctrineMigrationsBundle/Resources/config/services.xml
Lines 113 to 119 in 05490c7
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:
- Document in the bundle that a file passed to
--configuration
should not have the prefix. - 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.