kantarciandClaude Opus 5
05ea703655
Wiederkehrende Aufgaben ohne Cronjob (ADR 073): Sicherung, Statistik kuerzen, geplante Veroeffentlichung, Updatepruefung und Aufraeumen laufen als Plan in der Tabelle scheduled_task - eine Zeile je Aufgabe mit Faelligkeit, Sperre und letztem Ergebnis. Auf geteiltem Hosting gibt es oft keinen Cronjob; der Plan haengt stattdessen an Anfragen und an einem Takt aus dem geoeffneten Backend. Diese Arbeit entstand in einer parallel laufenden Sitzung und lag bis hierher unveroeffentlicht im Arbeitsverzeichnis: die Releases 1.5.0 bis 1.5.5 wurden bewusst aus dem jeweiligen Tag gebaut und enthielten sie deshalb nicht. Vor der Veroeffentlichung geprueft, nicht bloss eingepackt: - phpunit 452/452, npm test 28/28, npm run test:editor vollstaendig. - Die Migration 20260914000100 legt nur die Tabelle scheduled_task an und nimmt sie beim Zurueckrollen wieder weg. Sie fasst keine bestehenden Daten an. - Seit einer Stunde keine Schreibzugriffe der anderen Sitzung mehr. Dabei zwei Fehler behoben: - config/services.yaml verwendet !tagged_iterator. Das ist gueltiges Symfony, aber "lint:yaml config" kennt eigene Tags nur mit --parse-tags und gab 1 zurueck - der CI-Lauf waere daran gescheitert. Flag ergaenzt. - AdminHeadersSubscriber.php (aus 1.5.3) entsprach nicht dem Stil von php-cs-fixer; composer lint gab 8 zurueck. Behoben. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
63 lines
2.3 KiB
PHP
63 lines
2.3 KiB
PHP
<?php
|
|
|
|
namespace App\Tests;
|
|
|
|
use Doctrine\DBAL\Connection;
|
|
use Doctrine\DBAL\Schema\Schema;
|
|
use DoctrineMigrations\Version20260912000100;
|
|
use DoctrineMigrations\Version20260912000200;
|
|
use DoctrineMigrations\Version20260912000300;
|
|
use DoctrineMigrations\Version20260912000400;
|
|
use DoctrineMigrations\Version20260912000500;
|
|
use DoctrineMigrations\Version20260912000600;
|
|
use DoctrineMigrations\Version20260912000700;
|
|
use DoctrineMigrations\Version20260912000800;
|
|
use DoctrineMigrations\Version20260912000900;
|
|
use DoctrineMigrations\Version20260912001000;
|
|
use DoctrineMigrations\Version20260912001100;
|
|
use DoctrineMigrations\Version20260912001200;
|
|
use DoctrineMigrations\Version20260912001300;
|
|
use DoctrineMigrations\Version20260913000100;
|
|
use DoctrineMigrations\Version20260914000100;
|
|
use Psr\Log\NullLogger;
|
|
|
|
/**
|
|
* The schema a migrated installation has, built for a fresh test database.
|
|
*
|
|
* The list used to stand in three places, so a new migration was three edits and the fixtures
|
|
* drifted apart. It stands here once. Indexes come from the same postUp() helpers the migrations
|
|
* use, because on SQLite an index added the ordinary way rebuilds the table.
|
|
*/
|
|
final class TestSchema
|
|
{
|
|
public static function build(Connection $db): void
|
|
{
|
|
$schema = new Schema();
|
|
foreach ([
|
|
Version20260912000100::class,
|
|
Version20260912000200::class,
|
|
Version20260912000300::class,
|
|
Version20260912000400::class,
|
|
Version20260912000500::class,
|
|
Version20260912000600::class,
|
|
Version20260912000700::class,
|
|
Version20260912000800::class,
|
|
Version20260912000900::class,
|
|
Version20260912001000::class,
|
|
Version20260912001100::class,
|
|
Version20260912001200::class,
|
|
Version20260912001300::class,
|
|
Version20260913000100::class,
|
|
Version20260914000100::class,
|
|
] as $migration) {
|
|
(new $migration($db, new NullLogger()))->up($schema);
|
|
}
|
|
foreach ($schema->toSql($db->getDatabasePlatform()) as $sql) {
|
|
$db->executeStatement($sql);
|
|
}
|
|
Version20260912000400::applyIndexes($db);
|
|
Version20260912000600::applyIndexes($db);
|
|
Version20260912000900::applyIndexes($db);
|
|
}
|
|
}
|