-
-
Notifications
You must be signed in to change notification settings - Fork 188
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
FEATURE: Doctrine rollback command #2938
base: 8.3
Are you sure you want to change the base?
Conversation
This could be backported to older versions, as it doesn't introduce changes to any concepts |
Hm, given |
True,
|
This is inspired by the rails way of doing this
https://edgeguides.rubyonrails.org/active_record_migrations.html#running-specific-migrations |
I see… This idea is not the worst:
Even though "step" is a horrible name for that parameter, IMHO. 😇 |
Step is not a part of this implementation of the same reasons :P Joke aside. I find my self running a migration, and need to rollback. I love the rollback command from rails because of the ease for me as a developer (no copy paste over versions and writing a direction, just a plain and simple command) |
I fully understand. I just wonder if the difference in "default behaviour" is too confusing… You run rollback but may or may not end up at the point you started your migrate from… |
We never know what we come from (very meta..) The longer description and headache this rollback features aims to resolve :) Consider this a simplification of doctrine:executemigration --version --direction down To you @kdambekalns the following can be considered common knowledge. It's for others to understand the developer headache to rollback a single migration at the time: To know what we came from, requires us to run doctrine:migrationstatus, read the numbers of migration we are about to migrate (and what versions). Note: Doctrine commands blocks us from creating a migration, if there is a pending one. Cases where we might have multiple migrations pending, could be installing a external package. The way to get back to where we came from would be to uninstall the packages and create new migrations in our own packages, or run the migrationexecute down on the versions before removing the packages. The rollback is a developers helping hand to ease the development and creations of migrations, but also usable, to test migrations if any errors pop up |
Coming back to this, an idea… What about
to "undo" the last migration? For more, this could work:
That doesn't "promise" as much as a rollback command… (IMHO) |
It delivers what is described in the command description :-) A different --version format, from a DX point of view seems odd A new command with a new purpose - It's all about developer experience :) I just want better DX for my daily tasks. Prepare for my upcoming doctrine:migrationgenerate --empty patch. |
As if people read those… or even know about Anyway, that reminded me of this old thing I drafted: https://docs.google.com/document/d/1GN10VfnYaSq-PJ3GMxw3L0y6oko6xQw4oVlopHYQgxE/edit?usp=sharing WDYT? |
It's a good idea to simplify the DX - that is the same goal of this rollback. But at the sime time isolate functionality into a single command and a simply speaking syntax. Developer Experience - make it easy, to get daily tasks done. We are really lacking behind on that, and we should at least focus on getting nice stuff into the core. I like many of the DX concept from rails and we should really look into bring it to ourself, instead of accepting the current state And you and I seems to be the only people interested in the topic. So why don't we simply move on this topic?! Get this in, and later find out of the whole doctrine command namespace should be reworked. But lets improve, while we are at it. We seem stucked. I already have it as a isolated package, I can release that instead, to see if it brings value to other than me. It can either bring the outcome:
Off-topic, but deserves a comment
To comment on the document concept, it reads as mixing things up here. The I think we should talk about a whole "generate/kickstart" concept, to simplify the kickstart of elements we are using every day
But also
and whatever generators we could introduce. And basically move the whole kickstart package concept in to such a pattern |
And we leave it here |
WTH… I came here to complain about feeling bad because others could also have had a look at this. Only to realize this works based on "executed at", a fact I had missed all the time! 🤦♂️ So to "fully roll back", one can just run the command multiple times, if needed. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks very good by reading a dozen times by now…
Released as own package |
Shouldn't
|
Previous in the "logical order" is not what this does – the change by @sorenmalling takes "time order" into account. |
With this change, you can now execute
./flow doctrine:rollback
to rollback latest executed migration
Resolves #2937
Upgrade instructions
No changes needed
Review instructions
doctrine:rollback
to see only the latest migration is rolledbackChecklist
FEATURE|TASK|BUGFIX
!!!
and have upgrade-instructions