Be part of JetBrains PHPverse 2026 on June 9 – a free online event bringing PHP devs worldwide together.

DanielSetreus's avatar

Is artisan schema:dump --prune supposed to insert all the old migrations into migrations table?

In our setup we've, for domain ownership reasons, modularized features of the app into their own service provider modules . Each registering their own migrations, just like any third party package might do.

However, artisan schema:dump --prune will only prune migrations from the default /database/migrations directory. This would not be a problem, if it wasn't for the fact that the generated dump .sql file does not insert what migrations already have been run (or can be considered part of the generated dump).

The next artisan migrate:fresh will load the dump SQL just fine, but then attempt to apply migrations, which will fail because tables or columns they attempt to create already exist, as created from the dump.

What's the best approach here? Manually adding a insert into migrations in the dump file seems uggly. But it also seems strange to me that Laravel does not do this by default. There could be any number of third party dependencies that loads migrations in the same way.

0 likes
1 reply
DanielSetreus's avatar

Digging into the Illuminate\Database\Console\DumpCommand class it is indeed supposed to append all migrations into the dump file. But there's a bug in the implementation.

Dump command runs

return $connection->getSchemaState()
                ->withMigrationTable($connection->getTablePrefix().Config::get('database.migrations', 'migrations'))
                ->handleOutputUsing(function ($type, $buffer) {
                    $this->output->write($buffer);
                });

This sets the migration table name to prefix_migrations.

Next Illuminate\Database\Schema\SchemaState::hasMigrationTable runs Illuminate\Database\Schema\Builder::hasTable with the given value prefix_migrations.

However, the hasTable method adds the prefix again, making it try to find a table named prefix_prefix_migrations - and that obviously does not exist.

I'll post a bug issue for this. Thanks for the input. 

This is in Laravel version 10.48.29, and that's no longer supported. It may have been fixed in later versions. It is possible to get around by manually removing the line

$table = $this->connection->getTablePrefix().$table;

from Illuminate\Database\Schema\Builder. Just remember to re-add it again after running the dump command.

1 like

Please or to participate in this conversation.