Auditor 3 breaks table names when using multiple "databases"

[timwsuqld]

Q	A
auditor version	3.3.1
PHP version	8.2.27
Database	MariaDB-10.6.8

Summary

Trying to upgrade an older Symfony 5.4 project from unsupported versions of Auditor and Auditor-Bundle as part of our migration to PHP 8.2 (and Attributes). After upgrading Doctrine DBAL to 3.6 (and disabling auditor bundle), doctrine works correctly.

After upgrading Auditor (3.3) and Auditor bundle (6.2) everything crashes with doctrine thinking the table names are now databasename__tablename. (This is just doctrine attempting to access tables, not even the at the point of writing an audit entry).

This application uses doctrine "schema" definitions, because it has models across multiple database (same server, just different MySQL databases).

The problem is in SchemaManager, resolveTableName relies on $platform->supportsSchemas(). From what I can see, this supportsSchemas isn't about the schema in an entity definition, but about things like Postgresql schemas, which is another layer of abstract on top of databases. This is causing your SchemaManager to incorrectly mangle the table names what have a schema defined, instead of passing them through as {namespaceName}.{prefix}{tablename}

Current behavior

When bundle is enabled, table names are resolved to databasename__tablename instead of databasename.tablename causing doctrine to crash and the bundle to be unusable.

How to reproduce

Setup a project with Doctrine entities that have schema defined, have multiple entities in different schemas. Create the tables manually, see that doctrine then complains that it can't find the table named databasename__tablename.

Expected behavior

Table names should be resolved to databasename.tablename

[timwsuqld]

I believe the call to supportsSchemas in TableSchemaListener is also breaking things. All my entity calls work fine without the auditor bundle, once the bundle is enabled things crash. If I trick the system by forcing supportsSchemas to true, then things work again. So DBAL 3 correctly works when supportsSchemas returns false, unless Auditor is installed. I think you are confusing the supportsSchemas with #[Entity(name: 'test', schema: 'databasename')] which is supported.

I think you just need to not call supportsSchemas and run the code path like before, or if you want to support things like postgres schemas, you need to differentiate them somehow from the normal schema which is the database name.

[DamienHarper]

@timwsuqld thanks for the report, I'll look into it as soon as possible