-
Notifications
You must be signed in to change notification settings - Fork 897
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
Improve migrations folder structure #448
Comments
It's definitely something to consider, but the argument about finding files doesn't really make sense, since the files will always be oldest-to-newest or vice versa. I would consider this very low priority, but definitely something to consider as we move towards v1.0. |
I never meant to make an argument about finding files. The migrations are ordered by ascending date, so the latest migration created is always at the bottom but getting to that means scrolling past all the others. Sorry about the confusion. |
definitely a low pro for me as well and also a tough one. Some people use Phinx with very few migrations, whilst others have very substantial use cases. |
One possibility to consider is to squash all migrations older than x into a single (the first) one, and remove all other migrations (incl the DB footprint of them). this way you basically refreshed all. This would go well together with The whole team just has to be certain all migrations have been applied everywhere below that threshold of months/years :) |
Closing due to lack of activity or out of scope. If there is new interest, please open a PR. |
Currently all the migrations are created inside the migrations folder at the same level.
As the number of created migrations for a project rises it gets more cumbersome to navigate this folder (opening a migration file to edit after creation for example), because the list is huge and a lot of scrolling is necessary. This could also have a performance impact if the number of files is really big (git uses sub-folders in its internal object organisation to avoid this problem)
My suggestion is to group the migrations by year and maybe month too and this way make the migrations folder more user friendly.
Regarding the existing migrations, all of them have a timestamp and we could write a script to migrate them to the new structure if necessary.
I don't think this is a priority but it could be an improvement.
I could find some time to work on this if the maintainers and users consider this useful/necessary.
The text was updated successfully, but these errors were encountered: