Tilbagevendende migrationer med Flyway

1. Introduktion

I denne korte vejledning undersøger vi et par måder at tilbageføre en migration med Flyway.

2. Simuler tilbageførsel med en migration

I dette afsnit tilbagefører vi vores database ved hjælp af en standardmigrationsfil.

I vores eksempler bruger vi kommandolinieversionen af ​​Flyway. Kerneprincipperne er dog lige så anvendelige til de andre formater, såsom core API, Maven plugin osv.

2.1. Opret migration

Lad os først tilføje et nyt Bestil tabel til vores database. For at gøre dette opretter vi en migreringsfil kaldet V1_0__create_book_table.sql:

Opret tabelbog (id numerisk, titel varchar (128), forfatter varchar (256), begrænsning pk_book primær nøgle (id));

For det andet, lad os anvende migrationen:

./flyve migrere

2.2. Simuler tilbageførsel

Så på et eller andet tidspunkt siger vi, at vi er nødt til at vende den sidste migration.

For at gendanne databasen til før Bestil tabel blev oprettet, lad os oprette migration kaldet V2_0__drop_table_book.sql:

drop bord bog;

Lad os derefter anvende migrationen:

./flyve migrere

Endelig kan vi kontrollere historikken for alle migrationer ved hjælp af:

./flyway info

hvilket giver os følgende output:

+ ----------- + --------- + ------------------- + ------ + --------------------- + --------- + | Kategori | Version | Beskrivelse | Type | Installeret til | Stat | + ----------- + --------- + ------------------- + ------ + --------------------- + --------- + | Versioneret | 1.0 | opret bogbord | SQL | 2020-08-29 16:07:43 | Succes | | Versioneret | 2,0 | drop bord bog | SQL | 2020-08-29 16:08:15 | Succes | + ----------- + --------- + ------------------- + ------ + --------------------- + --------- +

Bemærk, at vores anden migration kørte med succes.

Hvad Flyway angår, er den anden migreringsfil bare endnu en standardmigrering. Den aktuelle gendannelse af databasen til den tidligere version sker udelukkende via SQL. I vores tilfælde er SQL for at tabe tabellen for eksempel det modsatte af den første migrering, som opretter tabellen.

Ved hjælp af denne metode revisionssporet viser os ikke, at den anden migration er relateret til den første, da de har forskellige versionsnumre. For at få et sådant revisionsspor er vi nødt til at bruge Flyway Undo.

3. Brug af Flyway Undo

For det første er det vigtigt at bemærke det Flyway Undo er en kommerciel funktion i Flyway og er ikke tilgængelig i Community Edition. Derfor har vi brug for enten Pro Edition eller Enterprise Edition for at kunne bruge denne funktion.

3.1. Opret migreringsfiler

Lad os først oprette en migreringsfil kaldet V1_0__create_book_table.sql:

Opret tabelbog (id numerisk, titel varchar (128), forfatter varchar (256), begrænsning pk_book primær nøgle (id));

For det andet, lad os oprette den tilsvarende fortryd migreringsfil U1_0__create_book_table.sql:

drop bord bog;

I vores fortrydelse af migration skal du bemærke, hvordan filnavnpræfikset er 'U' sammenlignet med det normale migrationspræfiks for 'V'. Også i vores fortryd migreringsfiler vi skriver SQL, der vender ændringerne i den tilsvarende migrationsfil. I vores tilfælde slipper vi tabellen, der er skabt af den normale migration.

3.2. Anvend migrationer

Lad os derefter kontrollere den aktuelle tilstand for migreringerne:

./flyway -pro info

Dette giver os følgende output:

+ ----------- + --------- + ------------------- + ------ + -------------- + --------- + ---------- + | Kategori | Version | Beskrivelse | Type | Installeret til | Stat | Fortrydelig | + ----------- + --------- + ------------------- + ------ + -------------- + --------- + ---------- + | Versioneret | 1.0 | opret bogbord | SQL | | Afventer | Ja | + ----------- + --------- + ------------------- + ------ + -------------- + --------- + ---------- + 

Bemærk den sidste kolonne, Fortrydelig, hvilket indikerer, at Flyway har registreret en fortryd migreringsfil, der ledsager vores normale migreringsfil.

Lad os derefter anvende vores migrationer:

./flyve migrere

Når den er afsluttet, er vores migrationer færdige, og vores skema har en ny bogtabel:

 Liste over relationer Skema | Navn | Type | Ejer -------- + ----------------------- + ------- + -------- - offentligt | bog | tabel | baeldung public | flyve_skema_historie | tabel | baeldung (2 rækker) 

3.3. Tilbagebetaling af den sidste migration

Endelig lad os fortryde den sidste migration ved hjælp af kommandolinjen:

./flyway -pro fortryd

Når kommandoen er kørt med succes, kan vi kontrollere status for overførslerne igen:

./flyway -pro info

hvilket giver os følgende output:

+ ----------- + --------- + ------------------- + ------- --- + --------------------- + --------- + ---------- + | Kategori | Version | Beskrivelse | Type | Installeret til | Stat | Fortrydelig | + ----------- + --------- + ------------------- + ------- --- + --------------------- + --------- + ---------- + | Versioneret | 1.0 | opret bogbord | SQL | 2020-08-22 15:48:00 | Fortryd | | | Fortryd | 1.0 | opret bogbord | UNDO_SQL | 2020-08-22 15:49:47 | Succes | | | Versioneret | 1.0 | opret bogbord | SQL | | Afventer | Ja | + ----------- + --------- + ------------------- + ------- --- + --------------------- + --------- + ---------- +

Læg mærke til, hvordan fortrydelsen har været vellykket, og den første migrering er tilbage til afventende. I modsætning til den første metode er også audit trail viser tydeligt de migrationer, der blev rullet tilbage.

Selvom Flyway Undo kan være nyttigt, antager det, at hele migrationen er lykkedes. For eksempel fungerer det muligvis ikke som forventet, hvis en migration mislykkes halvvejs.

4. Konklusion

I denne korte vejledning kiggede vi på gendannelse af vores database ved hjælp af en standardmigrering. Vi kiggede også på den officielle måde at rulle migrationer tilbage ved hjælp af Flyway Undo. Som normalt kan al vores kode, der vedrører denne vejledning, findes på GitHub.


$config[zx-auto] not found$config[zx-overlay] not found