Upgrade to doctrine-migrations v3

[Tsvetomir Lazarov]

Given the release of Doctrine Migrations v3, is the support for the new version planned? It's such a pity, because the migrations support for psr-container-doctrine was added not a long time ago, but the version is now locked to v2. Can we do this without a BC break?

[James Titcumb]

We can definitely look into it!

[BrunoSpy]

Just updating composer.json is enough ?

[James Titcumb]

@BrunoSpy depends if there is any BC breaks that could cause issues, it would need checking

[BrunoSpy]

I dit the change. I don't see any error, at least for the part I use (Migrations Commands)

[Thomas Rieschl]

I haven't tried that yet but by looking at the UPGRADE docs I doubt that everything will work as expected, given that most (all?) of the methods in the Factory don't exist anymore.

[Ben Yan]

Any update? or how can I introduce migrations v3 with current psr-container-doctrine?

[James Titcumb]

Sorry, no update yet; it was already pointed out above some work may be necessary here, and I haven't gotten around to it yet, sorry >.<

[Yılmaz]

Hello! I was able to make some meaningful progress here recently but the final result not satisfied me. Thus, I decided to ask here first before opening a pull request. imo there are decisions needs to be made.

Just updating composer.json is enough ?

Unfortunately, it's not. v3 of migrations has major changes as mentioned by @rieschl above.

I use both psr-container factories and doctrine/migrations on couple of projects along with laminas-servicemanager and all of them sticked with migrations v2 at the moment.

Main points that I could not make sure how to proceed are:

• The new ctor of DoctrineCommand now declares a soft-dependency to a \Doctrine\Migrations\DependencyFactory
• If a DependencyFactory instances was not provided on construction, all derived migration commands expects that --db-configuration and --configration arguments are provided.
• Even if I am not sure about other use cases, I am using all available commands directly inside my symfony CLI application, besides doctrine/orm, doctrine/fixtures, and my application commands. So passing these CLI parameters is not an option for me. I would prefer having a dedicated factory that creates this commands with pre-configured entity manager, namespaces and paths to look into. A factory either located in my own project or a common library like psr-container-factories here.

My initial implementation allows creating commands with preferred entity manager something like:

return [
    'dependencies' => [
        'factories' => [
            // with default em (orm_default)
            \Doctrine\Migrations\Tools\Console\Command\ExecuteCommand::class => \Roave\PsrContainerDoctrine\Migrations\CommandFactory::class,
            // with alternative em (orm_other)
            \Doctrine\Migrations\Tools\Console\Command\ExecuteCommand::class => [\Roave\PsrContainerDoctrine\Migrations\CommandFactory::class, 'orm_other'],

            // I could not make sure if following factories should be optional, mandatory or just an implementation detail in CommandFactory
            \Doctrine\Migrations\Configuration\Migration\ConfigurationLoader::class => \Roave\PsrContainerDoctrine\ConfigurationLoaderFactory::class,
            \Doctrine\Migrations\DependencyFactory::class => \Roave\PsrContainerDoctrine\Migrations\DependencyFactoryFactory::class,
        ],
    ],
];

If someone can assist me or give an idea on which direction to go, I can proceed and open a pull request soon. As seen on new named factories on the DependencyFactory, it could be instantiated using either a connection or entity manager, which are both available in psr-container-doctrine context. So I proposed a DependencyFactoryFactory without making hundred percent sure on others' thoughts on this.

[James Titcumb]

@edigu assuming they're effectively tested, having a FactoryFactory is not a deal breaker I think. I haven't checked the code properly yet but please do open a Draft PR and we can take a closer review 🙂

[Yılmaz]

Sure, I created a PR. I will propbably need some help on addressing some of psalm errors/warnings there.

[Thomas Rieschl]

Hi! Is there any progress on this? Some of my doctrine packages are already outdated because of this constraint.
Would it be better/easier to separate the migration configuration into separate config files/classes (if not already) and marking doctrine/migrations as suggested? If I want to use the wiring/config of this package I'd still have to use v2 (no bc break) but if I want to use v3 of migrations I can have my own factories.

[James Titcumb]

Yes, working on it :) been a long time coming.