Create a migration package

[WanWizard]

In addition to current functionality, it needs

• a better sequencing mechanism then just numbers in a filename
• dependency management
• PSR compliant class names
• a mechanism that prevents folder sweeps when looking for migrations
• the option for a single migration to abort an entire migration run
• the option for a single migration to abort the current run
• the option for a single migration to skip itself (so it will run again on a next migration run)

[emlynwest]

If there are no complaints I can get this started on Monday

[WanWizard]

complaints against my quick functionality list? 😄

[emlynwest]

Just want others to have a chance to protest before I hammer this out ;-)

[sagikazarmark]

I was looking around for already existing solutions and I found this: https://phinx.org/

On its own, it is great. However it is not general migration tool. And it does not check out @WanWizard's list. Also, as I can see, it cannot be easily integrated.

[WanWizard]

Migrations are about a lot more than only database. They should be able to handle anything that migrates an application from state A to state B.

The current requirement for sequential processing, and the lack of dependencies, make that they are currently not very useful.

[sagikazarmark]

Can't agree more

[emlynwest]

Sounds like I'll have to restart the v2 migration package I started a couple of years ago ;)

[sagikazarmark]

If we create one that has all the mentioned features, it will be quite unique. There is nothing like a "generic migration package" in the PHP community. And I see potential in contributing to the community with "not-only-fuel-components". I know your argument @WanWizard ("we are building a framework here"). But we could create something that not just works in fuel, but in other applications as well. (With official support)

[emlynwest]

I talked over ideas about migrations with @WanWizard way back and we came up with quite a comprehensive feature set. The stuff I worked on is here https://github.com/fuelphp/migration but I have no looked at the code for ages so am not sure what state it is in.

[WanWizard]

My main concern with anything "third party" is: how does it affect the stability of the framework.

Obviously, if it is still "our" code, but it's part of phpleague instead of fuelphp, it doesn't change anything, it's just a name. I don't have any objections, on the contrary.

[sagikazarmark]

To be clear: I am on the side of writting one. 😃 What generally think about packages created by frameworks is that people don't think about it as a framework agnostic packages. So we can write the better on the market, many people simply won't use it.

[WanWizard]

The only place for such an independent package would be the phpleague. But you don't start with that, so I think it's best to start with a fuelphp repo, write it to be framework independent, and see how to move on from there. If it gets accepted in the league, it's only a composer.json change...

[sagikazarmark]

And a namespace one. But sounds like a good plan.

[emlynwest]

My TODO list just got a little longer it seems ;)

[WanWizard]

That is only an issue in the code that runs the migrations, and that bit is Fuel specific anyway.

The actual migration classes themselfs should not be coupled with the migration package at all. I suggest, if it's going to be an independent package, to use adapters to construct the migrations tree, so other environments can customize the way the dependency tree is built.

[emlynwest]

@WanWizard I already have an idea on how to decouple that, cogs are turning and plans in motion.