-
Notifications
You must be signed in to change notification settings - Fork 99
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
Feature run migrations based on config #64
Feature run migrations based on config #64
Conversation
@mefenlon what is your input on the above? |
First, I love this package. You have saved me a lot of effort. In my use case, I added your package to a project that already had a languages table. I could have changed the table name in the config to avoid the conflict. I then could have made a new migration to drop the uneeded tables. But, I was expecting the behavior to be different considering I could disable the modules in the config file.
I am sure there is a use case that would only want countries. I do see that you could not disable states and enable cities. But, I understand if you don't want to disable the states and cities.
|
This also got me thinking about the refresh command. I added a check to make sure the modules are enabled before dropping the table. |
@nnjeim did you have a chance to review my comments in response to your concerns? |
These changes check the config for enabled modules before running the migration.
When using this project, I noticed a table would be created despite a module being disabled. This may not be the most elegant solution, but it prevents the migration from running when the module is disabled.