Как обрабатывать миграции с помощью нескольких диспетчеров сущностей в DoctrineMigrationsBundle 3

Также в моем вопросе упоминается открытая проблема DoctrineMigrationsBundle от 2012 года, описывающая проблему миграции при использовании нескольких менеджеров сущностей: https://github.com/doctrine/DoctrineMigrationsBundle/issues/38. Кажется, есть несколько вариантов решения этой проблемы, как описано там, нам просто нужно было покопаться и попробовать каждый из них, чтобы найти лучший для нашей ситуации.

Миграция с учетом контейнеров

В Symfony 3 мы использовали подход ContainerAwareInterface. Описано в предыдущем выпуске:

Currently this can be achieved by using Container Aware Migrations. If one can have the service container injected, he can obtain an instance of some entity manager and its connection.

Однако это больше не является правильным решением при переходе на Symfony 4 из-за того, что классы ContainerAware устарели в пользу внедрения зависимостей.

Передать конфигурацию напрямую

Другой подход, упомянутый в проблеме github выше. Идея здесь состоит в том, чтобы иметь отдельный файл конфигурации для каждого менеджера сущностей, как показано ниже:

# config/packages/migrations/base.yaml
em: default
transactional: false
migrations_paths:
    Hyra\Migrations\Base: src/Migrations/Base
table_storage:
    table_name: migration_versions

Это передается непосредственно в команду вместе с менеджером сущностей следующим образом: bin/console doctrine:migrations:migrate --em default --configuration config/packages/migrations/base.yaml. Эти отдельные файлы конфигурации заменяют один файл конфигурации config/packages/doctrine_migrations.yaml.

Это также было нецелесообразно для нас, так как нам все еще нужно было внедрять сервисы в наши миграции, используя параметр конфигурации services для DoctrineMigrationsBundle, а --configuration передает параметры конфигурации только напрямую в doctrine/migrations, который не поддерживает параметр конфигурации services.

Изначально на DoctrineMigrationsBundle 3.0 этот подход усложнялся тем, что опции --em и --conn были полностью отброшены, поэтому также необходимо было создать обертку поверх команд DoctrineMigrationsBundle для повторной реализации этих опций (более подробно описано здесь). В этом больше нет необходимости в DoctrineMigrationsBundle 3.1+ (который восстановил эти параметры).

Используйте DoctrineMigrationsMultipleDatabaseBundle

Также упомянутый в ветке проблем github, этот пакет реализует именно то, что нам было нужно (и в конечном итоге использовали) — конфигурацию для каждого объекта для DoctrineMigrationsBundle, поэтому мы также можем включить нашу конфигурацию services для внедрения зависимостей миграции. Изначально я неправильно настроил это — важно, чтобы базовая конфигурация doctrine_migrations.yaml включала только конфигурацию для менеджера сущностей по умолчанию. Пример рабочей конфигурации предоставлен автором пакета (версия 0.3.3):

# doctrine.yaml
doctrine:
    dbal:
        default_connection: default
        connections:
            default:
                url: '%env(resolve:DATABASE_URL)%'
                server_version: mariadb-10.1.26
                charset: utf8mb4
                default_table_options:
                    charset: utf8mb4
                    collate: utf8mb4_unicode_ci
                mapping_types:
                    enum: string
            geonames:
                url: '%env(resolve:GEONAMES_DATABASE_URL)%'
                server_version: mariadb-10.1.26
                charset: utf8mb4
                default_table_options:
                    charset: utf8mb4
                    collate: utf8mb4_unicode_ci
                mapping_types:
                    enum: string

        # IMPORTANT: You MUST configure your server version,
        # either here or in the DATABASE_URL env var (see .env file)
        #server_version: '5.7'
    orm:
        auto_generate_proxy_classes: true
        default_entity_manager: default
        entity_managers:
            default:
                connection: default
                naming_strategy: doctrine.orm.naming_strategy.underscore_number_aware
                mappings:
                    Main:
                        is_bundle: false
                        type: annotation
                        dir: '%kernel.project_dir%/src/App/Entity/Main'
                        prefix: 'App\Entity\Main'
                        alias: Main
            geonames:
                naming_strategy: doctrine.orm.naming_strategy.underscore_number_aware
                connection: geonames
                mappings:
                    Geonames:
                        is_bundle: false
                        type: annotation
                        dir: '%kernel.project_dir%/src/App/Entity/Geonames'
                        prefix: 'App\Entity\Geonames'
                        alias: Geonames

# doctrine_migrations.yaml
doctrine_migrations:
    em: default
    migrations_paths:
        DoctrineMigrations: '%kernel.project_dir%/migrations/Main'

# doctrine_migrations_multiple_database.yaml
doctrine_migrations_multiple_database:
    entity_managers:
        default:
            migrations_paths:
                DoctrineMigrations\Main: '%kernel.project_dir%/migrations/Main'
        geonames:
            migrations_paths:
                DoctrineMigrations\Geonames: '%kernel.project_dir%/migrations/Geonames'