Symfony/Doctrine: PostgreSQL-Migrationsproblem – Undefinierter Spaltenfehler nur im HTTP-Kernel (CLI funktioniert) ⇐ Php

[Anonymous]

Symfony/Doctrine: PostgreSQL-Migrationsproblem – Undefinierter Spaltenfehler nur im HTTP-Kernel (CLI funktioniert)
Ich arbeite an einem Symfony 7.3-Projekt, das auf PHP 8.2 läuft. Ich habe kürzlich die Datenbank von MySQL nach PostgreSQL migriert und bin seitdem auf ein sehr spezifisches Problem mit Doctrines ORM gestoßen, das sich nur im HTTP-Kontext manifestiert.
Das Problem
Wenn ich versuche, Daten aus der Benutzertabelle über eine HTTP-Anfrage abzurufen, erhalte ich den folgenden SQL-Fehler:

Code: Select all

SQLSTATE[42703]: Undefined column: 7
ERROR:  column t0.id does not exist
LINE 1: SELECT t0.id AS id_1, t0.email AS email_2, t0.password AS pa...

Dieser Fehler betrifft ausschließlich jeden Code, der innerhalb des HTTP-Kernels ausgeführt wird (z. B. Controller, Listener).
Sachliche Beobachtungen (entscheidend)

1. Die Befehlszeilenschnittstelle (CLI) funktioniert einwandfrei

Wenn Abfragen direkt über die Symfony-Konsole ausgeführt werden (die genau dieselbe Doctrine-Konfiguration und Datenbankverbindung verwendet), funktioniert alles perfekt. Dies bestätigt, dass die Tabelle public.user und die Spalten-ID vorhanden sind.

2. Isolierter Debug-Controller schlägt fehl

Ein minimaler Debug-Controller, der die Benutzerentität abruft, löst den Fehler aus.

3. Funktionierendes Gegenbeispiel (The Clue)

Ein strukturell identischer Controller für den

Code: Select all

CustomerDie 

[/b]-Entität (Tabellenname Kunde, die kein reserviertes PostgreSQL-Schlüsselwort ist) funktioniert ohne Fehler. Dies deutet stark auf einen Konflikt mit dem reservierten Schlüsselwort hin

Code: Select all

user

[/b].
Entitäts- und Datenbankdetails

Benutzerentität (gekürzt)

Die Entität verwendet standardmäßige Doctrine-Anmerkungen:

Code: Select all

// src/Entity/User.php
#[ORM\Entity(repositoryClass: 'App\Repository\UserRepository')]
#[ORM\Table(name: 'user')] // Problematic line
class User {
// ... ORM\Id and ORM\Column definitions
}

Datenbankstruktur

• DBMS: PostgreSQL
• Tabellenname in der Datenbank: Benutzer (Kleinbuchstaben, öffentliches Schema)
• PostgreSQL-Fakt: Das Wort Benutzer ist ein reserviertes SQL-Schlüsselwort.

Die vorübergehende Lösung und die Kernfrage
Ich habe festgestellt, dass der Fehler behoben wird, indem man Doctrine manuell dazu zwingt, den Tabellennamen mit Backticks in Anführungszeichen zu setzen in der Entitätszuordnung:

Code: Select all

// Temporary Fix
#[ORM\Table(name: '`user`')]

Obwohl diese Lösung funktioniert, lehne ich sie als dauerhafte Lösung ab. Sie führt eine unansehnliche Ausnahme in meinen sauberen Entitätscode ein, behandelt nur dieses einzelne reservierte Wort und bietet keine zukunftssichere, globale Garantie dafür, dass Doctrine andere reservierte PostgreSQL-Schlüsselwörter (z. B. Gruppe, Reihenfolge usw.) ohne manuellen Eingriff korrekt verarbeitet.

Die Frage
Basierend auf der bestätigten Grundursache (das für PostgreSQL reservierte Schlüsselwort user wird im HTTP-Kontext nicht zuverlässig zitiert) und dem Wunsch nach einer sauberen, globalen Lösung:
Was ist die zugrunde liegende Doctrine DBAL- oder Symfony-Konfigurationseinstellung (z. B. in doctrine.yaml), die auf die PostgreSQL-Verbindung angewendet werden muss, um global das Richtige durchzusetzen? Anführungszeichenverhalten für alle reservierten SQL-Schlüsselwörter, wodurch die Entitätszuordnung sauber bleibt (

Code: Select all

#[ORM\Table(name: 'user')]

) und Gewährleistung der zukünftigen Kompatibilität mit PostgreSQL?[/b]