Skip to content
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

Closed
robertmarsal opened this issue Jan 14, 2015 · 5 comments
Closed

Improve migrations folder structure #448

robertmarsal opened this issue Jan 14, 2015 · 5 comments
Milestone

Comments

@robertmarsal
Copy link

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.

@shadowhand
Copy link
Contributor

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.

@robertmarsal
Copy link
Author

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.

@robmorgan
Copy link
Member

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.

@dereuromark
Copy link
Member

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
#206
IMO

The whole team just has to be certain all migrations have been applied everywhere below that threshold of months/years :)
This way you can keep everything as it is, one just needs to clean up those every x years or months.

@dereuromark dereuromark added this to the 1.0.0 milestone Apr 11, 2020
@othercorey
Copy link
Member

Closing due to lack of activity or out of scope. If there is new interest, please open a PR.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants