Skip to main content

Doctrine catchup migrations

Resetting Doctrine Migrations and Generating a Fresh Baseline

Sometimes, after months of development, experiments, rebases, or multiple contributors, Doctrine migrations can become difficult to follow. You may end up with:

  • Too many migration files
  • Broken migration history
  • Conflicts between branches
  • Databases that are already in sync but migrations are not
  • Old migrations that no longer represent reality

In those situations, one practical solution is to completely reset the migration history and generate a brand new migration representing the current state of your entities.

When Should You Do This?

This approach is useful when:

  • You are still in active development
  • The project has not yet reached production
  • You want to simplify migration history
  • Your migration chain has become unreliable
  • You want a clean baseline for future migrations

Do not do this lightly on production systems with historical environments that depend on previous migrations.

Step 1 — Remove Existing Migration Files

Delete everything inside your migrations/ directory. 

rm -rf migrations/*

This removes the old migration history from the codebase.

Step 2 — Generate a Migration From an Empty Schema

Generate a migration that represents the full current structure of your entities: 

php bin/console doctrine:migrations:diff --from-empty-schema

The --from-empty-schema option tells Doctrine:

Compare the current entities against an empty database and generate everything.

The generated migration becomes your new baseline migration.

Step 3 — Rollup the Migration History

Now tell Doctrine that the database is already synchronized with this migration: 

php bin/console doctrine:migrations:rollup

This command does not execute SQL. Instead, it updates the migration metadata so Doctrine considers the database already migrated.

Why This Works

At this point:

  • Your entities represent the current truth
  • Your database is already synchronized
  • You now have a single clean migration baseline
  • Future migrations become easier to manage

Typical Workflow

# Remove old migrations
rm -rf migrations/*

# Generate fresh baseline migration
php bin/console doctrine:migrations:diff --from-empty-schema

# Mark database as already migrated
php bin/console doctrine:migrations:rollup

Important Notes

  • Always commit your database state before doing this
  • Backup important databases
  • Coordinate with teammates before rewriting migration history
  • Avoid this approach once multiple production environments depend on historical migrations

Conclusion

Doctrine migrations are excellent for tracking schema evolution, but sometimes the cleanest solution is to create a fresh baseline.

Using: 

php bin/console doctrine:migrations:diff --from-empty-schema
php bin/console doctrine:migrations:rollup

you can quickly reset migration history while keeping the current database structure intact.

Popular posts from this blog

Undefined global vim

Defining vim as global outside of Neovim When developing plugins for Neovim, particularly in Lua, developers often encounter the "Undefined global vim" warning. This warning can be a nuisance and disrupt the development workflow. However, there is a straightforward solution to this problem by configuring the Lua Language Server Protocol (LSP) to recognize 'vim' as a global variable. Getting "Undefined global vim" warning when developing Neovim plugin While developing Neovim plugins using Lua, the Lua language server might not recognize the 'vim' namespace by default. This leads to warnings about 'vim' being an undefined global variable. These warnings are not just annoying but can also clutter the development environment with unnecessary alerts, potentially hiding other important warnings or errors. Defining vim as global in Lua LSP configuration to get rid of the warning To resolve the "Undefined global vi...
Read more

CopilotChat GlobFile Configuration

CopilotChat GlobFile Configuration Want to feed multiple files into GitHub Copilot Chat from Neovim without listing each one manually? Let's add a tiny feature that does exactly that: a file glob that includes full file contents . In this post, we'll walk through what CopilotChat.nvim offers out of the box, why the missing piece matters, and how to implement a custom #file_glob:<pattern> function to include the contents of all files matching a glob. Using Copilot Chat with Neovim CopilotChat.nvim brings GitHub Copilot's chat right into your editing flow. No context switching, no browser hopping — just type your prompt in a Neovim buffer and let the AI help you refactor code, write tests, or explain tricky functions. You can open the chat (for example) with a command like :CopilotChat , then provide extra context using built-in functions. That “extra context” is where the magic really happens. Built-in functio...
Read more

npm run build base-href

Using NPM to specify base-href When building an Angular application, people usually use "ng" and pass arguments to that invocation. Typically, when wanting to hard code "base-href" in "index.html", one will issue: ng build --base-href='https://ngx.rktmb.org/foo' I used to build my angular apps through Bamboo or Jenkins and they have a "npm" plugin. I got the habit to build the application with "npm run build" before deploying it. But the development team once asked me to set the "--base-href='https://ngx.rktmb.org/foo'" parameter. npm run build --base-href='https://ngx.rktmb.org/foo did not set the base href in indext.html After looking for a while, I found https://github.com/angular/angular-cli/issues/13560 where it says: You need to use −− to pass arguments to npm scripts. This did the job! The command to issue is then: npm run build -- --base-href='https://ngx.rktmb.org/foo...
Read more