Kontrola poradia migrácií

Štrukturálna kontrola poradia migrácií vyberie cudzie kľúče zo zdrojového kódu migrácií a overí, že každá odkazovaná tabuľka vznikne skôr než migrácia, ktorá na ňu odkazuje:

expect($migrationsDir)->toHaveRunnableMigrationOrder(
    ?int $foreignKeys = null,
    array $tableResolvers = [],
    array $externalTables = [],
);

it('has a runnable migration order', function (): void {
    expect(database_path('migrations'))->toHaveRunnableMigrationOrder(foreignKeys: 19);
});

Prečo štrukturálne

SQLite bez námietok vytvorí tabuľku, ktorá odkazuje na neexistujúceho rodiča, a ozve sa až pri vkladaní dát. Prístup „zmigrujme na SQLite a uvidíme“ preto zostane zelený aj pri poradí, ktoré sa na Postgres či MySQL nedá nainštalovať. Päť našich vlastných balíkov takto vyšlo so zelenými SQLite testami. Poradie čítané zo zdrojového kódu robí kontrolu nezávislou od enginu — zlyhá aj na SQLite.

Poradie podľa blokov Schema

Poradie sa sleduje podľa blokov Schema — create(), table(), drop(), dropIfExists() a rename(), na fasáde aj cez Schema::connection(…) —, nie podľa súborov: súbory bežia v poradí adresára (rovnaký zoznam *.php, aký aplikuje spúšťač), bloky v rámci súboru v poradí zdrojového kódu. Migrácia, ktorá vytvorí teams a potom team_members (s obmedzením na teams), je spustiteľná; tie isté dva bloky v opačnom poradí nie sú.

Život tabuľky, len z up()

Každá tabuľka má svoje životnosti od CREATE po zmazanie a každý ALTER aj kľúč sa overuje voči životnosti platnej práve na jeho pozícii. Prestavba len dopredu — vytvorenie, úprava, potom dropIfExists() a nové vytvorenie — prejde. Druhé CREATE bez zmazania medzi nimi zlyhá, rovnako ako kľúč na tabuľku či ALTER tabuľky, ktorá už bola zmazaná alebo premenovaná. Schema::rename('a', 'b') ukončí a a začne b; zdrojová tabuľka musí v tej chvíli existovať alebo byť deklarovaná ako externá. down() sa pred parsovaním odstráni — pri migrácii dopredu sa nikdy nespustí, takže CREATE ani kľúč v ňom sa nepočíta.

Podporované tvary cudzích kľúčov

Zakomentované deklarácie sa ignorujú.

Preklad neliterálnych názvov tabuliek

Ak migrácia pomenúva tabuľku cez premennú alebo statickú metódu, namapujte surový výraz — presne tak, ako je v zdrojovom kóde — na názov tabuľky:

it('has a runnable migration order', function (): void {
    expect(__DIR__.'/../../database/migrations')->toHaveRunnableMigrationOrder(
        foreignKeys: 4,
        tableResolvers: [
            '$tableName' => 'books',                        // Schema::create($tableName, …)
            'PermissionRegistrar::rolesTable()' => 'roles', // ->constrained(PermissionRegistrar::rolesTable())
        ],
    );
});

Stráženie strážcu

• Deklarácia, ktorú nemožno rozparsovať, test zhodí namiesto toho, aby ju ticho vynechala: počet rozparsovaných cudzích kľúčov sa musí rovnať volaniam ->constrained( a ->references( v každom súbore, bez komentárov a bez down().
• foreignKeys: pripne celkový počet hrán. Pripnite ho všade, kde aserciu zavediete.
• Prázdny výsledok parsovania vždy zlyhá, s pripnutím aj bez neho — vrátane foreignKeys: 0: adresár bez súborov *.php (adresár len so súbormi *.php.stub na publikovanie sa číta ako prázdny, lebo stub nie je migráciou, kým sa nepublikuje) alebo migrácie bez jediného bloku Schema::create() či Schema::table(). Aserciu nasmerujte na adresár, v ktorom vaše migrácie naozaj sú.
• Chýbajúci adresár migrácií zlyhá, namiesto toho aby prešiel nad ničím.

Tabuľky, ktoré sada nevlastní

Migrácia balíka s obmedzením na tabuľku users hostiteľskej aplikácie či migrácia aplikácie, ktorá mení tabuľku vytvorenú balíkom tretej strany, odkazuje na tabuľku, ktorú žiadny súbor v adresári nevytvára. Deklarujte ju v externalTables:

expect(__DIR__.'/../../database/migrations')->toHaveRunnableMigrationOrder(
    foreignKeys: 3,
    externalTables: ['users'],
);

Každá položka externalTables sa kontroluje proti zastaraniu: musí na ňu odkazovať niektorý kľúč alebo ALTER a sada ju nesmie vytvárať.