I got this error over and over. I was using a schema_filter setting in Symfony, and that was the source of the problem.
This Laravel user had a similar problem:
https://github.com/laravel-doctrine/migrations/issues/35#issuecomment-249512155
It’s due to schema_filter.
The schema filter docs give an example where they use a negative assertion to exclude tables that match a regex.
See the docs: https://symfony.com/doc/current/bundles/DoctrineMigrationsBundle/index.html#manual-tables
The function of the filter is to return a list of tables to include — that is, the filter returns true if a given table name is acceptable.
So (once I figured that out), I made a regex like this:
schema_filter: ~^(event)$~
My goal was to produce Doctrine migrations only for one table.
At that point, I started to have error messages as Doctrine kept trying to create the migration_versions table.
As the link above explained, the migration_versions table was being filtered out. The fix was:
schema_filter: ~^(event|migration_versions)$~
I had to add the versioning table to the list of acceptable tables.
That seems weird, but there’s a clue here:
https://github.com/doctrine/migrations/tree/master/lib/Doctrine/Migrations/Metadata/Storage
Doctrine tools use Doctrine to store migration metadata.
Is this a good design decision, to use Doctrine’s classes to manage the metadata for Doctrine itself?
It’s like part of Doctrine has a dependency on Doctrine, and it exposes Doctrine’s inner working to the configuration layer.