[FIXED] php artisan migrate fails due to laravel command

Issue

I have a laravel command that contains a user entity. I wrote a migration to modify the user table. When running php artisan migrate, I get an error because the user entity does not match the database (because this migration will make those changes).

I suspect that this means that the migrate command's process includes setting up laravel commands. Is there a way I can run php artisan migrate and the laravel command code not run?

I'm running laravel 5.1 and php 7.1.

Edit:

I didn't post any code, because it's not even getting to the migration. Here is the error message (the command was php artisan migrate).

This may be helpful was well. This is in the laravel command class that is causing the error. I can comment it out and the migration runs fine. That would be annoying to do for production though.

$userRepo = $repositoryFactory->getRepository(User::class);
$this->defaultUser = $userRepo->find(3000);

I just thought I should also include part of the stack trace that is in the laravel log file for this error.

#0 /project-path/vendor/doctrine/dbal/lib/Doctrine/DBAL/DBALException.php(176): Doctrine\DBAL\Driver\AbstractMySQLDriver->convertException('An exception oc...', Object(Doctrine\DBAL\Driver\PDOException))
#1 /project-path/vendor/doctrine/dbal/lib/Doctrine/DBAL/DBALException.php(150): Doctrine\DBAL\DBALException::wrapException(Object(Doctrine\DBAL\Driver\PDOMySql\Driver), Object(Doctrine\DBAL\Driver\PDOException), 'An exception oc...')
#2 /project-path/vendor/doctrine/dbal/lib/Doctrine/DBAL/Connection.php(915): Doctrine\DBAL\DBALException::driverExceptionDuringQuery(Object(Doctrine\DBAL\Driver\PDOMySql\Driver), Object(Doctrine\DBAL\Driver\PDOException), 'SELECT t0.user_...', Array)
#3 /project-path/vendor/doctrine/orm/lib/Doctrine/ORM/Persisters/Entity/BasicEntityPersister.php(712): Doctrine\DBAL\Connection->executeQuery('SELECT t0.user_...', Array, Array)
#4 /project-path/vendor/doctrine/orm/lib/Doctrine/ORM/Persisters/Entity/BasicEntityPersister.php(730): Doctrine\ORM\Persisters\Entity\BasicEntityPersister->load(Array, NULL)
#5 /project-path/vendor/doctrine/orm/lib/Doctrine/ORM/EntityManager.php(462): Doctrine\ORM\Persisters\Entity\BasicEntityPersister->loadById(Array)
#6 /project-path/vendor/doctrine/orm/lib/Doctrine/ORM/EntityRepository.php(154): Doctrine\ORM\EntityManager->find('...', Array, NULL, NULL)
#7 /project-path/Emailer.php(53): Doctrine\ORM\EntityRepository->find(3000)
#8 /project-path/QuoteStaleEmailer.php(25): Emailer->__construct(...)
#9 [internal function]: QuoteStaleEmailer->__construct(...)
#10 /project-path/vendor/laravel/framework/src/Illuminate/Container/Container.php(780): ReflectionClass->newInstanceArgs(Array)
#11 /project-path/vendor/laravel/framework/src/Illuminate/Container/Container.php(631): Illuminate\Container\Container->build('...', Array)
#12 /project-path/vendor/laravel/framework/src/Illuminate/Foundation/Application.php(674): Illuminate\Container\Container->make('Servi...', Array)

Solution

I came up with a decent work around. I don't know the correct terms to describe it, but looking at the stack trace, laravel sets up containers during a php artisan command. That includes containers for laravel command.

$this->defaultUser = $userRepo->find(3000) line was in the constructor, which meant it ran when the containers are setup. This causes an error because, the database for the user does not match the app setting for the user (because the migration hasn't run yet).

I moved the line to the getter function instead and set the default user there if it's empty, which isn't used when setting up the containers.

Answered By - D.Jones