mikro-orm
Feat: Ability to add migrations without actually running it
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.
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 --fake, that feels weird to me. But we can have a command to log/unlog a single migration by name, that feels quite handy and is very easy to do.
edit: but the question is where this should be available, I am not so sure I like to add a flag to the up/down commands, maybe it will be better to have separate log/unlog commands next to them
if this is implemented in Umzug instead of in MikroORM
In fact, umzug is not adding much value here, and could be easily removed, most of the stuff that @mikro-orm/migrations are doing is implemented on top of umzug, replacing most of what it does with custom implementations to allow different driver storages and whatnot.
@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 maybe it will be better to have separate log/unlog commands next to them, seems like a better approach already
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.
But we can have a command to log/unlog a single migration by name, that feels quite handy and is very easy to do.
edit: but the question is where this should be available, I am not so sure I like to add a flag to the up/down commands, maybe it will be better to have separate log/unlog commands next to them
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.
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 --fake flag in the first place). Let's not complicate things, OP asked for a way to add lines to the migrations table, that's what I can add easily, the rest doesn't feel justified for the added complexity.
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 addSql calls. But I surely see a value in that option, maybe we could just log the code of such migrations, as running them might already bring side effects.
The scenario I am trying to cover is : Lets say I modified some columns to a table externally Later on I wrote a migration to cover the change. Since the change was already applied, I wanted the orm to be able to track this as well(which is why adding it to the migration table without actually running it) .
The scenario I am trying to cover is : Lets say I modified some columns to a table externally Later on I wrote a migration to cover the change. Since the change was already applied, I wanted the orm to be able to track this as well(which is why adding it to the migration table without actually running it) .
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.