Detach Migrator from the CLI

[lcharette]

Migrator shouldn't be tied to so much to the CLI and migrate command. Right now, there's no standard way to test, outside of the migrate command, if a migration has been run. For example :

UserFrosting/app/sprinkles/account/src/Bakery/CreateAdminUser.php

Lines 68 to 79 in 9bad043

	if (!Capsule::schema()->hasColumn('migrations', 'id')) {
	$this->io->error("Migrations doesn't appear to have been run! Make sure the database is properly migrated by using the `php bakery migrate` command.");
	exit(1);
	}
	// Make sure the required mirgations have been run
	foreach ($this->dependencies as $migration) {
	if (!Migrations::where('migration', $migration)->exists()) {
	$this->io->error("Migration `$migration` doesn't appear to have been run! Make sure all migrations are up to date by using the `php bakery migrate` command.");
	exit(1);
	}
	}

Should also help with #778.

Progress

• Make migrator it's own class, detached from Bakery
• Move Migrator to the core sprinkle
• Add tests
• Add --database option for Bakery command
• Add status Bakery command
• Run tests against the SQLite in memory db
• Update helper traits (related Move test Trait to their respective sprinkle #826)
• Find a way to integrate data seeders (See Support "non-interactive mode" for migrations and data seeds #778)
• Add batch number to status command

[lcharette]

Some notes and references for later:

• Laravel Migration. This part is important. Laravel migration doesn't have namespaces. This would actually avoid issues people had on the chat. Will also makes the migration names less dependent of our stupid convention (Locate classes directly via namespace, rather than relying on filename conventions #743).

• Migration test. Because we need those (and I need to learn what Mockery is).

• Laravel migration commands. Because that status command could be useful.

• The database option would also be useful.

• To get those nested (stupid) version migration (and not cause a BC) : RecursiveIteratorIterator

[alexweissman]

Mockery

[lcharette]

Most work has been done in the feature-migrator branch regarding this issue.

One thing that could left to do, beside updating learn, would be to re-implement the sprinkle option for the migrate:rollback command (and probably reset and refresh too). First, that option for the base migrate command doesn't make sense. Why would you want to migrate up a sprinkle, but not the other? But for rolling back, it does makes sense if you want to delete a previously loaded sprinkle you don't want anymore. So yeah, stil looking into this (and #730).

(Sprinkle support for migration is the reason the migrator wasn't moved to a separate package btw)

Some other notes in case I forgot :

• We can't go away from using namespaces with our migrations. As pointed in my previous comment, Laravel doesn't use them (and doesn't have to deal with namespace issue) because they store all their migration in a single path OR migrate a single path at the time. This is something we can't do with sprinkles, as two sprinkles can have dependent migrations between each other and two sprinkles can have the same class names for their migrations. This is still taken care of more accurately in the new migrator since we don't enforce the version part of the migration anymore (can be in the top level).
• Tests can now use the new migrator service to call in migrations and setup a clean test, in memory, SQLite database. So this should help with Support "non-interactive mode" for migrations and data seeds #778. Seeding the database is still an issue thought...

Last of all, this update should be (squashed) merge into 4.2.0 version. There no big breaking change, but some stuff got deprecated. So, just in case...

For a list of other fix in this branch : Changelog

And yes, I did learn how Mockery works. It's great.

[lcharette]

This is a good idea...