php artisan migrate:fresh
command it doesn't drop tables for secondary database connection.in my database.php I have.
'mysql' => [
'driver' => 'mysql',
'host' => env('DB_HOST', 'localhost'),
'database' => env('DB_DATABASE', 'forge'),
'username' => env('DB_USERNAME', 'forge'),
'password' => env('DB_PASSWORD', ''),
'charset' => 'utf8',
'collation' => 'utf8_unicode_ci',
'prefix' => '',
'strict' => FALSE,
'engine' => NULL,
],
'mysql_2' => [
'driver' => 'mysql',
'host' => env('DB_HOST_2', 'localhost'),
'database' => env('DB_DATABASE_2', 'forge'),
'username' => env('DB_USERNAME_2', 'forge'),
'password' => env('DB_PASSWORD_2', ''),
'charset' => 'utf8',
'collation' => 'utf8_unicode_ci',
'prefix' => '',
'strict' => FALSE,
'engine' => NULL,
],
Create a table for each database, then run the migration. After you have tables run php artisan migrate:fresh
. It ignores the mysql_2 tables when dropping, which then throws the error "Table 'X' already exists". If you drop the table manually then run the command again it will work as it should.
You can decide which database you want to drop using the --database
option
I would like to vote for this to be re-opened.
The aim of the migrate:fresh
command is to drop all of your tables and migrate everything again, right? If you use multiple databases in an application, the command will simply drop all the tables from your default connection and then attempt to migrate everything again, which will result in errors that tables already exist in your other, non-default databases.
If we are to use the --database
option to specify that we want to drop all tables from a different database, then the default connection wouldn't have its tables dropped and the subsequent up migration would fail again with similar errors, albeit for a different set of tables.
If it isn't feasible or desirable to have migrate:fresh
drop tables from all databases before migrating again, would it instead be possible to be able to specify multiple database connections when using the --database
option? I would be willing to submit a PR for the latter option if that's something that may be considered useful and would likely be accepted.
@jrhenderson1988
I would like to vote for this to be re-opened too.
+1
+1
We have multiple databases to separate admin/ CRM and customer data. It's possible to work around this by extending and replacing the command, but it would be a nice addition to the framework imo.
+1 Because of the comment above (https://github.com/laravel/framework/issues/21009#issuecomment-414971613 ) describe the problem in our development too.
Got tried of this not working and very quickly whipped up a solution. Obviously this just works for me and isn't ideal - the database names are hardcoded, views are not tested, database engines other than MySQL are not tested or supported. But it solves the immediate problem for me. Hopefully this helps someone out.
https://gist.github.com/Vusys/7989d824c512516d6ea4dc18057f602b
Recently stumbled upon this very same issue, I have both a mysql and a pgsql database and I need to run tests that touch both databases. The migrations are only stored inside one db (shouldn't the migrations for each database be stored in the corresponding database?).
The RefreshDatabase
trait only freshly migrates the first database, but does not delete the tables in the second database before attempting to re-migrate them. Is there a solution to this problem? Has anyone solved this problem already somehow?
I've stumbled upon this when setting up Telescope to use a different database, which should be possible [as per documentation]. However when you run the very common:
php artisan migrate:fresh
This throws an error reporting that the database tables still exists.
Current workaround is to publish the migration asset and wrap the create with a check to see if the table exists.
if($this->schema->hasTable('telescope_entries') === false) {
$this->schema->create('telescope_entries', function (Blueprint $table) {
...
The migration looks like it should manage on a different database connection but doesn't seem to comply.
I've also stumbled upon this issue.
migrate:fresh command is used in RefreshDatabase.php, it causes migration error on testing.
I've stumbled upon this when setting up Telescope to use a different database, which should be possible [as per documentation]. However when you run the very common:
php artisan migrate:fresh
This throws an error reporting that the database tables still exists.Current workaround is to publish the migration asset and wrap the create with a check to see if the table exists.
if($this->schema->hasTable('telescope_entries') === false) { $this->schema->create('telescope_entries', function (Blueprint $table) { ...
The migration looks like it should manage on a different database connection but doesn't seem to comply.
This is the reason I ended up here as well.
The drop part of the command only drops the default, but the migrate part migrates everything.
One option could be a new command php artisan migrate:drop --database="..."
then we can drop both before calling a new migrate
Another option could be making the --database
option support multiple databases separated by comma. php artisan migrate:drop --database="sqlite,sqlite_telescope"
.
I do think that the fresh part of the migrate:fresh
command should be migration-agnostic to prevent corrupted migrations from messing up, and so it cannot know which connections should the tables be dropped. On the other hand, migration:fresh
cannot just drop all tables from all connections available, since some DB connections are designed to not use migration mechanism.
I agree on the php artisan migrate:drop --database="connection1, connection2"
command though, that seems nice
This is how I do it now:
php artisan db:wipe --database A
php artisan db:wipe --database B
php artisan migrate:fresh --seed
i will admit this also frustrated me but it was such a specific use case i just made an alias to the effect of what @merlinro did.
alias fresh="php artisan db:wipe --database a && php artisan db:wipe --database b && php artisan migrate:fresh --seed"
Most helpful comment
I would like to vote for this to be re-opened.
The aim of the
migrate:fresh
command is to drop all of your tables and migrate everything again, right? If you use multiple databases in an application, the command will simply drop all the tables from your default connection and then attempt to migrate everything again, which will result in errors that tables already exist in your other, non-default databases.If we are to use the
--database
option to specify that we want to drop all tables from a different database, then the default connection wouldn't have its tables dropped and the subsequent up migration would fail again with similar errors, albeit for a different set of tables.If it isn't feasible or desirable to have
migrate:fresh
drop tables from all databases before migrating again, would it instead be possible to be able to specify multiple database connections when using the--database
option? I would be willing to submit a PR for the latter option if that's something that may be considered useful and would likely be accepted.