Formed in 2009, the Archive Team (not to be confused with the archive.org Archive-It Team) is a rogue archivist collective dedicated to saving copies of rapidly dying or deleted websites for the sake of history and digital heritage. The group is 100% composed of volunteers and interested parties, and has expanded into a large amount of related projects for saving online and digital history.
[8.x] Add anonymous migrations #36906
Conversation
thiagorb
force-pushed the
thiagorb:add-anonymous-migrations
branch
from
97baded
to
bf104bd
|
This PR changes some of the framework migrations such as
Also wouldn't think we should change the default stubs on a patch release, but supporting anonymous migrations itself on patch release should be fine if there no breaking change risk 👍🏼 . |
|
Hey @crynobone ! Yeah, I thought that changing the stubs could be too much, so I added it as a separate commit. We can drop this last commit then. But your preference is to throw if creating a migration with duplicated name instead of anonymous migrations? |
I worry that it potentially causes an issue if developers try to run My guess all framework migration should remain as it is. and maybe ship with separate anonymous migration stubs for 8.x. php artisan make:migration -a create_posts_table --create |
|
I really like this idea. I think @crynobone indeed makes a good point about the duplicate framework shipped migrations.
Laravel 6 is closed for new features. |
|
It's a cool feature but yeah I would drop the commit of renaming existing migrations - at least until 9.x. |
This would solve #5899.
With this approach, migrations won't have class names anymore (they didn't serve any purpose and cause some tricky to solve issues).
After a project was maintained for a long time, the chance that two migrations were created with the same name is very high. For example, consider the following migrations:
With the current approach, the first and last migration have the same name. After the third migration is created, it is possible to run it just fine, unless you are trying to run all these migrations at the same time (like after creating an empty database, or while running tests). In a project where there were always tests since the beginning this will be barely an inconvenience, but it causes a lot of trouble for a project that has been developed for many years without tests.
With this new approach this won't be a problem, cause the names can be dropped completely. The new Migrator is still able to run named migration classes, so the solution is backward compatible.
I believe it would be possible to backport it to 6.x too, in case it is approved.