Love Fuel?    Donate

FuelPHP Forums

Ask your question about FuelPHP in the appropriate forum, or help others by answering their questions.
Modules Migrations
  • Has any headway been made with making module-specific migrations available? It would be amazing to allow my modules to have their own migration versioning.
  • Search the forums, Phil has killed that idea and explained multiple times why. There were plans for allowing tasks in modules/packages which would allow similar functionality, but I think we pushed that back to 1.1.
  • We'll have to discuss this after release of 1.0. I can see a need for this. In a truly modular environment, modules can introduce their own set of tables to an application. You don't want the break the loose coupling achieved by using modules by being forced to have the migrations for the module tables in app.
  • Harro Verton wrote on Wednesday 6th of July 2011:
    We'll have to discuss this after release of 1.0. I can see a need for this. In a truly modular environment, modules can introduce their own set of tables to an application. You don't want the break the loose coupling achieved by using modules by being forced to have the migrations for the module tables in app.

    I like this logic. I'm developing a open source forum module built on Fuel, and am running into this problem. I find myself lacking a way to easily install the tables into the database... Perhaps I could simply set up a task that generates and runs the migrations for me... But that's still an extra step. I don't believe it's currently possible to have tasks inside of modules, correct?
  • According to the docs, you are correct. I feel that having tasks/migrations within modules is a very important thing for Fuel, as it will allow us to share our modules between eachother without having to worry about database levels. The only concern I have, is database table names. An example, if I'm installing a forum module and an ecommerce module, they would both have something similar to "users" tables, etc. That would be interesting to mesh together.
  • I think that issue could be alleviated with simply standardizing around the core Auth system and base components. If all modules follow one Auth library, all would use the same user table... Which could be altered in the Auth configuration file. Everything is pretty much separated in Fuel and would make developing modules with individual information as simple as adding fields to the user table configured in the Auth system when the module is installed. So in the example of having forums and e-commerce... The users table would exist before both modules. Installing each would add columns for both via module migrations. They would also add products, and posts tables... See where this is going? Sessions would be shared via the Session class and extended when inside of each module. They could be inter-connected via HVMC calls... I think the idea of module migrations would be powerful in keeping the framework as modular and re-usable as possible. Just my $0.02.
  • in latest oil the migration for modules seems to be implemented. How do i have to set the migration in modules directory and how must the config of the module look like?
  • Patrick Heller wrote on Tuesday 14th of February 2012:
    in latest oil the migration for modules seems to be implemented. How do i have to set the migration in modules directory and how must the config of the module look like?

    Same as migrations anywhere else. Create a migrations folder in the modules base directory with migrations inside. Run the same oil command but add '--modules' at the end for all modules or '--modules=mymodue' for a specific module or '--modules=mymodule1,mymodule2' for multiple. You can also use '--packages' for package migrations and I believe there is also an '--all' command that does evertyhing.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

In this Discussion