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
Feat: Ability to add migrations without actually running it #5390
Comments
How would you see this working? You might have more than on migration that needs to be applied. By adding this you risk “fake applying” migrations you need. If this is something people need, it might be better to have the CLI interactive, and provide you with a list of migrations it’s going to run, where you can mark some as “already used”. |
This wont introduce anything new rather builds on top of how currently migration works. It would just mark the migrations as applied without actually running anything. |
IMHO, it would be best for the ecosystem as a whole if this is implemented in Umzug instead of in MikroORM. The migrator of MikroORM is built on top of Umzug. |
I don't think we need edit: but the question is where this should be available, I am not so sure I like to add a flag to the
In fact, umzug is not adding much value here, and could be easily removed, most of the stuff that |
@B4nan did you mean something like this when you said logging https://www.doctrine-project.org/projects/doctrine-migrations/en/3.5/reference/managing-migrations.html#dry-run also i agree with this |
No, log and unlog are umzug names to add/remove lines from the migrations table, it has nothing to do with logging as in printing stuff to console. |
I guess the real question in this case is "do we want to enable log/unlog of multiple migrations at once, with the same rules as up/down?". I will admit that in practice, most people (myself included) would log/unlog one migration at a time, so that would be fine... Though then again, being able to log/unlog multiple at once may also come in handy in more exotic setups... and in that case, I would expect all migration names to be in the sequence that they would be logged/unlogged. Combined with a "--dry-run" like option to see the migrations that are to be migrated, but not migrate them, one could implement log/unlog that behaves like up/down with a --fake flag, if they really need to. |
I don't think we need that (or should I say, I am not interested in writing that myself, and I still don't like the idea of Also for dry running, I don't see how it could work, as the migration can contain dynamic stuff, e.g. query execution, not just the |
The scenario I am trying to cover is : |
FWIW, at work, I get into this exact scenario... usually when testing if an index improves the situation on a page with a slow query, and then if it does, it makes sense to keep it. Plus... the other common scenario is when migration works perfectly fine on staging, but on production, due to the sheer amount of data, and the fact that the app remains online during migration... the migration takes too long while locking up everything, forcing us to interrupt the migration, and maybe find a different way to migrate. How exactly we continue after that depends on a case by case basis, but it often involves an entirely different set of queries that are far less optimal (in the sense that the migration takes longer than it would if we were just to bring the app down), but less locking, and sometimes involves "one off" scripts. |
Is your feature request related to a problem? Please describe.
This will add the migration to the migrations table without running it. This is useful for migrations created
after manual changes have already been made to the database or when migrations have been run externally
(e.g. by another tool or application), and you still would like to keep a consistent migration history.
Describe the solution you'd like
Something like
npx mikro-orm migration:up --fake
Describe alternatives you've considered
Right now I am manually adding the migration file to the migrations table
Additional context
Add any other context about the feature request here.
The text was updated successfully, but these errors were encountered: