CodeIgniter Forums
Third Party Migrations - Printable Version

+- CodeIgniter Forums (https://forum.codeigniter.com)
+-- Forum: CodeIgniter 4 (https://forum.codeigniter.com/forumdisplay.php?fid=28)
+--- Forum: CodeIgniter 4 Support (https://forum.codeigniter.com/forumdisplay.php?fid=30)
+--- Thread: Third Party Migrations (/showthread.php?tid=73106)

Pages: 1 2


Third Party Migrations - MGatner - 03-19-2019

I'm working on a library whose goal is to be plug-and-play, zero conf, whatever you want to call it. CI4 has made this *great* with name spacing everything and PSR4 autoload. My question is about the best practice around database migrations/seeds that come with a library.
The typical way I'd handle a table would be to create the migration and run it from CLI. However, CI4 has the ability to run migrations from a controller or library (https://codeigniter4.github.io/CodeIgniter4/dbmgmt/migration.html#usage-example), which makes it appealing to offer "automatic database configuration" - maybe the constructor checks for the existence of the table and runs the migrations if not found.

How do autoloaded Composer packages typically handled migrations? is there an expectation that the user will run it from CLI - every time there's an update / new migration? Can a package pass its own [namespace]/Config/Migrations.php and load it to the migrations service? if so is it customary to use the default "migrations" table? Anyone with experience in the area care to weigh in?


RE: Third Party Migrations - kilishan - 03-19-2019

I don't think there are any best practices just yet. People are still trying to figure it out Smile

I'd say for Composer-based packages that I would not run them automatically, personally. Those packages are aimed at developers who want control of their application. You could always setup a script that runs after update that would output some text to remind them, I think, though I haven't tried that exact thing before.

If it were a plugin for a CMS or something then auto-update might be a good feature, though I'd do it during an install or update from the GUI where the user was still taking an action.


RE: Third Party Migrations - MGatner - 03-19-2019

Thanks @kilishan - I'm sure there will be lots of figuring out as things go! How about migrations config - can I bundle Config/Migrations.php with my package and pass it to the migrations service to specify a namespace-specific configuration? E.g. if the user has app/Config/Migrations.php and migrations are disabled, can I use a namespace-enabled Config file to allow them? and specify a namespace-specific "current" version?


RE: Third Party Migrations - kilishan - 03-19-2019

Good question. I haven't specifically tried that but I believe the answer is no, they won't run if not enabled for the app in general. Pretty sure that config file is not searched for across namespaces.


RE: Third Party Migrations - MGatner - 03-20-2019

I’ll do some digging and testing on it and post back here. Maybe even make a proof-of-concept “auto-migrate” module


RE: Third Party Migrations - kilishan - 03-20-2019

Sounds great. Thanks!


RE: Third Party Migrations - MGatner - 03-21-2019

So as far as I can tell the MigrationRunner doesn't actually check namespaces autoloaded by Composer. If I specify a namespace in app/Config/Autoload.php then I can use migrate:latest -n [namespace], but without specifying it running the migration does nothing. To be precise: it doesn't give an error like it does if the namespace isn't matched ("Undefined index: MyNamespace"), it just says "Migrating to latest version... Done" but never detects that there are migrations to run.
Any advice would be great. If this indeed not my ignorance, this seems a pretty big block to distributable packages. if you want something to look at the context I'm working on right now is a traffic logging library:
https://github.com/tattersoftware/codeigniter4-visits


RE: Third Party Migrations - kilishan - 03-21-2019

If you use `php spark migrate:latest -all` it should run through all of the namespaces.

By default, the migrate command just runs migrations in the app directory. The thinking was that you could run, rerun, rollback, your own app during development without touching third-party migrations, except when you specifically wanted to.

How are you thinking that impacts packages? Just providing the instructions to `migrate:latest -all` should be enough, right?


RE: Third Party Migrations - MGatner - 03-22-2019

Sorry to be unclear - I think that approach is great! It's just not working, and I can't tell if it is me or the system. Testing went as follows:
  1. Use `composer require myPackage` to install
  2. Verify that myNamespace is working by loading services from the namespace, etc
  3. Run `./spark migrate:latest -all`: "Done", no namespace migrations
  4. Run `./spark migrate:latest -n myNamespace`: "Undefined index: myNamespace"
So then I add myNamespace manually to app/Config/Autoload.php under $psr4 and run `./spark migrate:latest -all` - and voilà, migrated!

Shouldn't Composer autoloaded namespaces be accessible to migrations just like their classes, services, helpers, etc?


RE: Third Party Migrations - MGatner - 03-22-2019

Alright, a long journey through the code later: confirmed that migrations only check app/Config/Autoload.php for namespaces. I updated MigrationRunner.php to use the Autoloader instead to check all initialized namespaces, which will include those sourced from Composer. I realize it is possible the original behavior was desired, but it seems odd to auto-autoload packages for all other purposes but still be forced to enter them manually in the config file if you want database support.
I'm open to discussion, here or GitHub: https://github.com/codeigniter4/CodeIgniter4/pull/1860