Suggestion : store migration unique id instead of migration full class name in migration table

[jomonjohnson]

Issue: suggestion : store migration unique id instead of migration full class name in migration table

So, We can move migration Class without modifying migration namespaces

[samdark (Alexander Makarov)]

What would you do when there are two same-named migrations in two different namespaces?

[rob006]

There are similar ideas in this issue:

Issue: [RFC] Aliases for migrations

The best solution is to not use namespaced migrations - they create more problems than they solves. Right now the only sane use of namespaces in migrations is to create migration as abstract class in library - end user may easily use them without copy&paste, by creating own migration, which extends real migration from library (it will be autoloaded thanks to namespaces).

[samdark (Alexander Makarov)]

Alternative approach to migrations

Suggestion : store migration unique id instead of migration full class name in migration table reminded me about me thinking about migrations approaches overall: “Classic” rails approach with plain classes named starting with timestamps. Migrations are sorted by name then applied one by one. Namespaced version of 1.. Proved to be overkill. Creating more problems than it solves. Git-like approach with explicit dependencies. Not sure it even worth implementing but since it’s still in my mind, I’…

[uldisn (Uldis Nelsons)]

A module name as column for information could be added to the migration table. If there are many modules in the system, it is difficult to understand which module has a migration record.

One module can define with two different names in configuration and in some case need for each module own table set with different prefixes. But this is a very specific case.