Use migrate:fresh in DatabaseMigrations

[henriquebremenkanp]

#20089

[olimorris]

This is busting my non Dusk feature tests when I run the full suite. The error I get is:

Illuminate\Database\QueryException: SQLSTATE[HY000]: General error: 1 table "migrations" already exists (SQL: create table "migrations" ("id" integer not null primary key autoincrement, "migration" varchar not null, "batch" integer not null))

Switching back to $this->artisan('migrate') doesn't cause the error.

[browner12]

sounds like it's unable to drop the existing database. maybe a permissions issue?

[olimorris]

This is being run in memory. Excerpt from my phpunit.xml file:

        <env name="DB_CONNECTION" value="sqlite"/>
        <env name="DB_DATABASE" value=":memory:"/>

and my sqlite connection:

'sqlite' => [
            'driver' => 'sqlite',
            'database' => env('DB_DATABASE', database_path('database.sqlite')),
            'prefix' => '',
        ],

[henriquebremenkanp]

Are you sure this is the problem? Because I was trying to think how it can be possible...
migrate:fresh basically drops all tables and call the migrate command.

The 'fresh' part of the command does not attempt to create a table. And if you're running sqlite/:memory:, there is nothing to drop either, so it will run through.
https://github.com/laravel/framework/blob/master/src/Illuminate/Database/Console/Migrations/FreshCommand.php#L38-42

The 'migrate' part is exactly what we had before, it calls the same command. If it works with migrate, it has to work with migrate:fresh because they're the same command, right?
https://github.com/laravel/framework/blob/master/src/Illuminate/Database/Console/Migrations/FreshCommand.php#L44-L48

Your error says you are trying to create a table 'migrations' when one already exists. I can only guess here, but maybe you have somewhere in your tests an attempt to create a migrations table?

I also tried some tests on sqlite/:memory: settings in phpunit and it was running as expected here.

[bartabel]

What is the purpose of rolling back the migrations (in beforeApplicationDestroyed) now that we drop all the tables in the next run?