Remove unused empty migrations/ directory; document migration-baseline blocker (#541)

[maltehuebner]

Summary

Partial progress on #541. Only the safe, unambiguous task is implemented here; the core baseline-migration work is blocked on information that is not in the repository (details below), so it is deliberately left open rather than guessed.

Changes

• Removed the top-level migrations/ directory (it held only an empty .gitignore, a Symfony-skeleton leftover). Migrations are configured under src/Migrations in config/packages/doctrine_migrations.yaml, so the second empty location was purely confusing. (Task: "Leeres migrations/-Verzeichnis entfernen.")

Open (deliberately not implemented)

Consolidated PostgreSQL baseline migration + the current_data materialized view

The table schema can be generated authoritatively and offline from the entity metadata (bin/console doctrine:schema:create --dump-sql), and is a solid starting point:

CREATE SEQUENCE city_id_seq INCREMENT BY 1 MINVALUE 1 START 1;
CREATE SEQUENCE station_id_seq INCREMENT BY 1 MINVALUE 1 START 1;
CREATE SEQUENCE data_id_seq INCREMENT BY 1 MINVALUE 1 START 1;
CREATE SEQUENCE network_id_seq INCREMENT BY 1 MINVALUE 1 START 1;
CREATE TABLE city (id INT NOT NULL, created_at TIMESTAMP(0) WITHOUT TIME ZONE NOT NULL, name VARCHAR(255) NOT NULL, slug VARCHAR(255) NOT NULL, description VARCHAR(255) DEFAULT NULL, PRIMARY KEY (id));
CREATE TABLE station (id INT NOT NULL, station_code VARCHAR(12) NOT NULL, uba_station_id INT DEFAULT NULL, title VARCHAR(255) DEFAULT NULL, latitude DOUBLE PRECISION NOT NULL, longitude DOUBLE PRECISION NOT NULL, coord geometry(POINT, 0) NOT NULL, from_date DATE DEFAULT NULL, until_date DATE DEFAULT NULL, altitude INT DEFAULT NULL, station_type VARCHAR(255) CHECK(station_type IN ('traffic','background','industrial')) DEFAULT NULL, area_type VARCHAR(255) CHECK(area_type IN ('urban','suburban','rural')) DEFAULT NULL, provider VARCHAR(255) DEFAULT NULL, city_id INT DEFAULT NULL, network_id INT DEFAULT NULL, PRIMARY KEY (id));
CREATE UNIQUE INDEX UNIQ_9F39F8B1992617A5 ON station (station_code);
CREATE INDEX IDX_9F39F8B18BAC62AF ON station (city_id);
CREATE INDEX IDX_9F39F8B134128B91 ON station (network_id);
CREATE TABLE data (id INT NOT NULL, date_time TIMESTAMP(0) WITHOUT TIME ZONE NOT NULL, value DOUBLE PRECISION NOT NULL, pollutant SMALLINT NOT NULL, tag VARCHAR(32) DEFAULT NULL, station_id INT DEFAULT NULL, PRIMARY KEY (id));
CREATE INDEX IDX_ADF3F36321BDB235 ON data (station_id);
CREATE UNIQUE INDEX unique_station_pollutant_datetime ON data (station_id, pollutant, date_time);
CREATE TABLE network (id INT NOT NULL, name VARCHAR(255) DEFAULT NULL, description TEXT DEFAULT NULL, link VARCHAR(255) DEFAULT NULL, PRIMARY KEY (id));
ALTER TABLE station ADD CONSTRAINT FK_9F39F8B18BAC62AF FOREIGN KEY (city_id) REFERENCES city (id) NOT DEFERRABLE;
ALTER TABLE station ADD CONSTRAINT FK_9F39F8B134128B91 FOREIGN KEY (network_id) REFERENCES network (id) NOT DEFERRABLE;
ALTER TABLE data ADD CONSTRAINT FK_ADF3F36321BDB235 FOREIGN KEY (station_id) REFERENCES station (id) NOT DEFERRABLE;

The blocker is the current_data materialized view. It is not defined anywhere in the repository, and it cannot be safely reconstructed from the code:

• DataRepository::findCurrentDataForCoord() selects id, ..., id AS station_id from the same current_data.id column, i.e. the view's column layout is ambiguous from the query alone (data id vs. station id), so an inferred CREATE MATERIALIZED VIEW risks mapping the wrong columns and silently corrupting results.
• The "current" time window / dedup semantics that justify a refreshed matview (LuftRefreshCommand) are unknown.

The definitive source is the production database:

SELECT pg_get_viewdef('current_data'::regclass, true);
-- plus its indexes:  \d+ current_data

Once that definition is captured, the baseline migration should bundle the tables above + CREATE EXTENSION IF NOT EXISTS postgis + the real current_data matview (+ its index).

Removal of the old MySQL/getName() migrations and the 29 baseline entries

These are intentionally not removed yet: they can only be dropped once the consolidated baseline above exists (otherwise a fresh doctrine:migrations:migrate has no schema at all). Removing them also requires the standard baseline procedure on existing databases:

# on databases that already have the schema, mark the new baseline as applied:
php bin/console doctrine:migrations:version <BaselineVersion> --add --no-interaction

The 29 AbstractPlatform::getName() phpstan-baseline.neon entries must be removed together with those migration files (they still error under DBAL 4 while the files exist; reportUnmatchedIgnoredErrors is false, so leaving them is harmless until then).

Verification limit

The table DDL above is generated from the live entity mapping (authoritative). The full baseline + matview needs a real PostGIS database to author correctly and to run doctrine:migrations:migrate end-to-end; that production schema/view definition was not available in this environment (the only reachable local PostGIS container hosts an unrelated application), so it is left to a maintainer with DB access. This PR ships only the zero-risk directory cleanup.

Refs #541

🤖 Generated with Claude Code