[Hoch] Migrations-Kette auf PostgreSQL nicht lauffähig; Materialized Views werden nirgends erstellt

[maltehuebner]

Problem

1. Alt-Migrationen sind MySQL-Migrationen und crashen unter DBAL 4

Die ältesten Migrationen stammen aus der MySQL-Ära, z. B. src/Migrations/Version20171203181834.php:17:

$this->abortIf($this->connection->getDatabasePlatform()->getName() !== 'mysql', ...);
$this->addSql('CREATE TABLE city (... ) DEFAULT CHARACTER SET utf8 ... ENGINE = InnoDB');

• AbstractPlatform::getName() wurde in DBAL 4 entfernt (installiert: doctrine/dbal 4.4.1) → der Guard selbst ist ein Fatal Error. phpstan-baseline.neon unterdrückt exakt dies 29-mal quer durch src/Migrations/.
• Selbst mit funktionierendem Guard wäre die Kette MySQL-DDL auf einem PostgreSQL/PostGIS-Stack.

php bin/console doctrine:migrations:migrate auf frischer Datenbank (README-Installationsschritt 4) bricht damit ab — Onboarding und Disaster-Recovery sind kaputt.

2. Materialized Views existieren nur in Bestands-Datenbanken

current_data, silvester_data, data_view werden intensiv genutzt:

• src/Repository/DataRepository.php:26 (FROM current_data), :64 (FROM silvester_data), :87-89 (REFRESH MATERIALIZED VIEW …)
• src/Command/LuftRefreshCommand.php (Cron-Refresh)

Es gibt aber kein einziges CREATE MATERIALIZED VIEW im Repository (grep über alle Migrationen/SQL/Configs). Ohne die Views brechen /display, /api (Koordinaten-Abfragen) und die Corona-Silvester-Analyse.

3. Verwaistes migrations/-Verzeichnis

Top-Level migrations/ enthält nur eine leere .gitignore; konfiguriert ist src/Migrations (config/packages/doctrine_migrations.yaml:2-3). Verwirrende Doppelstruktur.

Kontext/Risiko

Das Schema ist faktisch nur als „gewachsenes Artefakt" in der Produktions-DB vorhanden und nicht reproduzierbar. Jede neue Umgebung (Dev-Onboarding, Staging, Restore-Test, CI mit echter DB) scheitert. Das blockiert auch das Test-Issue (Integrationstests brauchen ein aufbaubares Schema).

Aufgaben

• Eine konsolidierte Baseline-Migration für PostgreSQL erstellen (aktuelles Schema inkl. PostGIS-Spalten, Sequenzen, Unique-Constraints und der drei Materialized Views + Indizes)
• Alte MySQL-/getName()-Migrationen entfernen (doctrine:migrations:sync-metadata-storage-Strategie für Bestands-DBs dokumentieren)
• Leeres migrations/-Verzeichnis entfernen oder migrations_paths dorthin umziehen
• 29 getName()-Baseline-Einträge aus phpstan-baseline.neon löschen
• Frische Installation nach README einmal komplett durchspielen; optional CI-Job mit doctrine:migrations:migrate gegen PostGIS-Service-Container