Handle Doctrine DBAL getObjectName() PHPStan Warnings

Doctrine DBAL 4.5 can expose getObjectName() through a public schema object while PHPStan reports that the method belongs to an internal base class. Do not replace the call with deprecated naming APIs or disable analysis for the entire Doctrine namespace.

Last updated: November 9, 2026.

<?php
use Doctrine\DBAL\Schema\Name\NamedObject;

function unqualifiedName(NamedObject $object): string
{
    return $object->getObjectName()
        ->getUnqualifiedName()
        ->getValue();
}

echo unqualifiedName($table);

Typing the boundary against Doctrine’s public NamedObject interface makes the intended contract explicit. It also confines any compatibility workaround to one helper instead of spreading suppressions through schema code.

Use the public object-name model

Doctrine’s object names documentation states that database objects implement either NamedObject or OptionallyNamedObject. The schema manager guide also demonstrates getObjectName()->toString() on tables, columns, indexes, and sequences.

A current Doctrine DBAL report explains the mismatch: public concrete classes inherit the method from a base class marked internal, so PHPStan can attribute a legal call to the internal declaration. This is a static-analysis metadata problem, not evidence that the runtime call is unsafe.

Keep any suppression narrow and temporary

First update Doctrine DBAL and PHPStan within versions supported by the application, then rerun analysis on the minimal reproducer. If the warning remains, route name access through the interface-typed helper. For an optionally named constraint, check whether a name exists before reading it. Keep the helper return type primitive so the internal implementation object does not escape into the rest of the application.

If a suppression is still required, target the specific method.internalClass identifier and the helper line, and link the upstream issue in the configuration comment. Avoid a broad regular expression that hides unrelated calls to genuinely internal Doctrine APIs. Add a small analysis test so the suppression can be removed when the declarations are corrected. Run that test during dependency updates and inspect the generated baseline diff instead of accepting every new warning automatically.

Related Web Cheat Sheet guides

Sergey Kornilov

Sergey Kornilov