fa/breadcrumb-the-shire
1
0
Fork 1
Code Issues Pull Requests 1 Actions Packages Projects Releases Wiki Activity
Files
ec596d35d40359902a9b4e8dcf8ad9f41acda3b0
breadcrumb-the-shire/docs/howto-erste-aenderung.md
fs 2e73cb98b4 feat(console): add db:migrate CLI for idempotent core schema updates 
Existing systems used to have no automatic mechanism for the
db/updates/*.sql idempotent updates after `git pull` — devs had to
remember which files were already applied and run new ones manually
with `mariadb < ...`. Mirror module:migrate to fix this:

- New `bin/console db:migrate` walks db/updates/*.sql in alphabetical
  order, skipping anything already recorded in the new core_migrations
  tracking table. Each file runs in its own transaction; failure
  rolls back so the file is retried on the next run.
- New `db:migrate --status` lists applied vs. pending files without
  running anything. Useful for ops debugging "schema seems stale"
  symptoms.
- module:sync now runs db:migrate as its first step, so the standard
  post-pull command stays a single invocation. README's 3-step setup
  is unchanged — module:sync now also covers core schema updates.

CoreMigrationRepository owns its own mysqli connection (using the
same DB credentials as MintyPHP\DB) and runs raw `$mysqli->query()`
instead of going through DB::query's prepared statement path —
MariaDB rejects some DDL (e.g. ALTER TABLE … ADD CONSTRAINT CHECK)
in the prepared protocol, which the existing 18 db/updates files
trip on. ModuleMigrationRepository is left untouched (no module
migration uses such DDL today and changing the vendor pattern is
out of scope).

End-to-end verified: against an existing DB the first run applies
all 19 idempotent files as no-ops and records them, second run
reports "all updates already applied". Against a freshly init'd
DB the same thing happens — no double work, no surprises. All
encrypted seed secrets keep decrypting because APP_CRYPTO_KEY
is unchanged.

Tests: tests/Console/CoreCommandsTest covers success/failure/status
output shapes against a FakeModuleRunner (mirror of the existing
ModuleCommandsTest pattern). 5 stale baseline entries in
phpstan-baseline removed (covered by the new @api annotation on
the test fixture class).

Docs: CLAUDE.md and docs/reference-cli-commands.md document the
new command + --status flag; docs/howto-fehlerbehebung.md gains
a "schema seems stale after git pull" section pointing at
db:migrate --status.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-04-29 08:59:57 +02:00

2.3 KiB
Raw Blame History

Leitfaden für die erste Änderung

Letzte Aktualisierung: 2026-03-25

Ziel

Ein neuer Entwickler soll den ersten Change strukturiert und reproduzierbar umsetzen können.

Beispiel 1: Spalte in Admin-Liste ergänzen

Schrittfolge

  1. Data-Endpoint erweitern (z. B. pages/admin/users/data().php)
  2. Falls nötig: neue Repository-Methode ergänzen – je nach Typ:
    • Listenabfrage / Filterung / Paginierung → core/Repository/User/UserListQueryRepository.php
    • Einzelnes Objekt lesen → core/Repository/User/UserReadRepository.php
    • Schreiboperation → core/Repository/User/UserWriteRepository.php
  3. Grid-Spalte in pages/admin/<modul>/index(default).phtml ergänzen (z. B. pages/admin/users/index(default).phtml)
  4. i18n-Key für Spaltennamen setzen
  5. Service-Auflösung in Action-Dateien nur über app(Foo::class) nutzen (kein new ...Factory() in pages/**)
  6. In data().php: GET-only (gridRequireGetRequest()) und Filter/Paging über gridParseFiltersFromSchemaFile(...) normalisieren
  7. php -l + manueller UI-Test

Done-Kriterien

  • Kein SQL in View-Dateien
  • Neue Werte im Endpoint dokumentiert/benannt
  • Sortierung und Mapping im Grid konsistent
  • Bei neuen Filtern: Query-Param, Repository-Filter und Grid-State konsistent
  • Instanziierungsstandard eingehalten (app(...), keine Legacy-Helper)

Beispiel 2: API-Response erweitern

Schrittfolge

  1. Endpoint in pages/api/v1/... anpassen (z. B. pages/api/v1/me/index().php oder pages/api/v1/users/show($id).php)
  2. Permission- und Tenant-Scope-Prüfungen beibehalten
  3. Optional Service/Repository ergänzen, Instanziierung über app(...)/Factory-Standards
  4. docs/openapi.yaml aktualisieren
  5. /docs/reference-api.md mit Beispiel aktualisieren
  6. Bei neuen Berechtigungen: PermissionService + init.sql synchron halten, für Bestandsumgebungen idempotentes SQL-Update in db/updates/*.sql bereitstellen — wird automatisch von bin/console db:migrate (bzw. module:sync) angewendet

Done-Kriterien

  • Keine numerischen IDs exponieren, wenn UUID bereits Contract ist
  • Fehlercodes konsistent (ApiResponse::error(...))
  • Kein Body-Leak in Logs/Audit
  • OpenAPI und tatsächlich gelieferte Response-Felder stimmen 1:1

Finaler Check

Vor PR/Merge diese Liste gegenprüfen:

  • /docs/reference-entwickler-checkliste.md
Reference in New Issue View Git Blame Copy Permalink