Configuring custom database schema name for migration_versions table breaks every command in release 3.9.6

[stlrnz]

Bug Report

Q	A
BC Break	yes
Version	3.9.6

Summary

Release 3.9.6 breaks configurations where migration_versions table is stored in a non-default schema.

Current behavior

When running any migrations command an exception will be thrown if the migrations table is configured to be stored in a non-default schema.

How to reproduce

1. Use a database supporting schemas (in my case: SQL Server)
2. Configure the migrations table name to include the schema name (e.g. by using doctrine migrations bundle):

doctrine_migrations:
    migrations_paths:
        # namespace is arbitrary but should be different from App\Migrations
        # as migrations classes should NOT be autoloaded
        'DoctrineMigrations': '%kernel.project_dir%/migrations'
    enable_profiler: false

    storage:
        table_storage:
            table_name: 'customschema.migration_versions'

3. Run any migrations command (e.g. by using symfony console).

bin/console doctrine:migrations:status

In TableDoesNotExist.php line 16:
                                                                            
  There is no table with name "customschema.migration_versions" in the schema.  
                                                                            

Expected behavior

Up until release 3.9.5 every command worked as expected. The migration_versions table was stored, read and written in the defined schema.

[andrew-demb]

#1564 (comment)

🥲

[greg0ire]

I was expecting this to break with a quoted schema, but here the issue is rather that we should extract the schema from and pass it to introspectSchemaWithUnquotedName() in a separate argument. Does #1567 fix the issue?

[stlrnz]

Does #1567 fix the issue?

Yes, it does. Thank you!