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

(jomonjohnson) #1

So, We can move migration Class without modifying migration namespaces

Alternative approach to migrations
(Alexander Makarov) #2

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


There are similar ideas in this issue:

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).

(Alexander Makarov) #4

(Uldisnelsons) #5

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.