I received a message from Phil S on github regarding adding migrations into modules. I have to agree that migrations outside of the application can cause sequencing problems... Basically the gist is that migrations should be application wide. But modules are reusable...
So this leads me to a question...
With the reply in mind... What is the best practice for working with the schema inside of a module? Is there a way to implement an eloquent solution to adding in modules?
Perhaps using the migrate class inside of an install module function? Perhaps in a oil task? This way the module can place it's own upgrades into the application without needing to create migrations by hand?
Using the method above you could then use version numbers to insert migrations directly into the application when upgrading...
I don't know the best solution, but maybe a discussion could work through this for the future...
Migrations are just a way to run SQL. Just because a module needs to run SQL does not mean it needs to be done with a Migration right?
You touched on the solution here, tasks.
Right now tasks inside modules and packages are not supported and they won't be until about v1.1, but this is how the feature would be best implemented.
Basically you'd have:
$ php oil r --module=foo install
Even still, this is a pretty weird way to do it in a system that is probably going to be a CMS. In PyroCMS i just have a details.php file that has an install(0 method containing all the SQL and installation functionality it needs. This can be run much easier and does not need to spawn a terminal process which would most likely be blocked on a live server.
That will do for me. Anything I can do to help speed up adding tasks inside of modules just let me know and I'll help any way I can. That sounds like a decent solution.
Donate
