-
Notifications
You must be signed in to change notification settings - Fork 92
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
namespacing migrations #77
Comments
It's not particularly something I would use, but I'm not against it and would happily accept a contribution, provided it's optional. Just FYI, the reasons I wouldn't use it:
|
I can agree with your use cases for typical apps, but what actually brought this up for me is a project that has user installable plugins which have their own independent migrations. When we perform an upgrade for the app we process migrations for the app as well as those for all installed plugins. Since we process migrations as part of a larger upgrade process, we have more than just phpmig loaded. We also can't predict third party usage of migrations, so we can't be sure there won't be a collision with our app stack or migrations. Moreover, because we're dealing with so many more migrations due to the large pool of available plugins the likelihood of a collision is much higher. After reading this article, I'm convinced this should be handled by extending and overriding AbstractCommand::bootstrapMigrations, though I can't see an easy way to do that. It's trivial for PhpmigApplication::loadMigrations, which is what I intend to use. So I believe I can solve this for my use case. But a general solution is blocked by #66. |
Ugh, yeah, this lib isn't particularly well put together and does make some more complicated things hard to grind in. I need to pencil some time in to spend on it regularly. |
Here's what I'd like to see:
Assume default namespace is set to 'My\Project'.
|
I am assuming this effort is over but I am looking to implement something like this. We I currently work I need namespacing for our migrations before we can merge a project that is wrapping up. Would a PR still be accepted? I am thinking that a good solution would be to pass in the expected namespace as an optional argument like so. vendor/bin/phpmig migrate -b path/to/bootstrap.php --namespace="Foo\Bar" or vendor/bin/phpmig migrate -b path/to/bootstrap.php --n="Foo\Bar" Would you accept a PR for that? |
After taking a look to see what it might take, I think separating the migration logic out of the console commands and PhpmigApplication class would need to be the first step. This logic could then be shared and also so it would make the change less of a hack. I am willing to do both as long as you would be willing to accept a PR for it. |
@ddelnano I'm totally willing to accept a PR so long as it doesn't break existing functionality :) |
Awesome should have something by the end of the weekend 👍 |
Yea I saw that in your earlier comment and from looking through the codebase before have noticed the coupling. Thanks! |
It doesn't appear that we can currently namespace our migrations. Here's why it would be good to have:
To accomplish this we'd need the ability to specify the namespace for each collection of migrations so they can be loaded correctly.
Thoughts?
The text was updated successfully, but these errors were encountered: