Upgrade to doctrine-migrations v3
thexpand opened this issue · comments
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?
We can definitely look into it!
Just updating composer.json is enough ?
@BrunoSpy depends if there is any BC breaks that could cause issues, it would need checking
I dit the change. I don't see any error, at least for the part I use (Migrations Commands)
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.
Any update? or how can I introduce migrations v3 with current psr-container-doctrine?
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 >.<
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.
@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 🙂
Sure, I created a PR. I will propbably need some help on addressing some of psalm errors/warnings there.
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.
Yes, working on it :) been a long time coming.