streamalism.org

1. Bemutatkozás

Ez a cikk a Repülőút és hogyan használhatjuk ezt a keretrendszert alkalmazásunk adatbázis-sémájának folyamatos, megbízható és egyszerű átalakítására. A végén bemutatunk egy példát a memóriában lévő H2 adatbázis kezelésére egy Maven Flyway plugin segítségével.

A Flyway frissíti az adatbázist egyik verzióról a másikra a migrációk segítségével. Írhatunk migrációkat akár SQL-be, adatbázis-specifikus szintaxissal, akár Java-ba a fejlett adatbázis-átalakításokhoz.

Az áttelepítések változatosak vagy megismételhetők. Az előbbinek egyedi verziója van, és pontosan egyszer alkalmazzák. Utóbbinak nincs verziója. Ehelyett minden alkalommal (újra) alkalmazzák őket, amikor az ellenőrző összeg megváltozik.

Egyetlen migrációs futtatáson belül a megismételhető migrációkat mindig utoljára alkalmazzák, miután a függőben lévő verziójú migrációkat végrehajtották. Az ismétlődő migrációkat leírásuk sorrendjében alkalmazzuk. Egyetlen áttelepítés esetén az összes utasítás egyetlen adatbázis-tranzakción belül fut.

Ebben a cikkben főleg arra összpontosítunk, hogy miként használhatjuk a Maven plugint az adatbázis-migrációk végrehajtására.

2. Flyway Maven beépülő modul

A Flyway Maven beépülő modul telepítéséhez adjuk hozzá a következő bővítménydefiníciót pom.xml:

 org.flywaydb flyway-maven-plugin 4.0.3 

A plugin legújabb verzióját a Maven Central oldalon ellenőrizhetjük.

Ez a Maven plugin négyféleképpen konfigurálható. Az összes konfigurálható tulajdonság listáját a dokumentációban találja meg.

2.1. A beépülő modul beállítása

A bővítményt közvetlenül a tag a plugin definíciónkban pom.xml:

 org.flywaydb flyway-maven-plugin 4.0.3 adatbázis Felhasználói adatbázis Jelszó sémaNév ... 

2.2. Maven Properties

Konfigurálhatjuk a beépülő modult is konfigurálható tulajdonságok megadásával Maven néven tulajdonságait a mi pomunkban:

 ... databaseUser databasePassword sémaNév ... ... 

2.3. Külső konfigurációs fájl

A plugin konfigurációját külön külön is megadhatjuk .tulajdonságok fájl:

flyway.user = databaseUser flyway.password = databasePassword flyway.schemas = schemaName ...

Az alapértelmezett konfigurációs fájl neve: repülési út.tulajdonságok és ugyanabban a könyvtárban kell lennie, mint a pom.xml fájl. A kódolást a repülési út.kódolás (Alapértelmezett: UTF-8).

Ha bármilyen más nevet használ (pl customConfig.properties) konfigurációs fájlként, akkor azt kifejezetten meg kell adni a Maven parancs meghívásakor:

$ mvn -Dflyway.configFile = customConfig.properties

2.4. Rendszer tulajdonságai

Végül az összes konfigurációs tulajdonság megadható rendszertulajdonságként is, amikor Mavenet meghívja a parancssorba:

$ mvn -Dflyway.user = databaseUser -Dflyway.password = databasePassword -Dflyway.schemas = schemaName

A következő egy elsőbbségi sorrend, ha egy konfigurációt egynél több módon adnak meg:

1. A rendszer tulajdonságai
2. Külső konfigurációs fájl
3. Maven tulajdonságok
4. Plugin konfiguráció

3. Példa migrációra

Ebben a szakaszban végigvezetjük a szükséges lépéseket az adatbázis-séma migrálásához a memóriában lévő H2 adatbázisba a Maven plugin segítségével. Külső fájlt használunk a Flyway konfigurálásához.

3.1. Frissítse a POM-ot

Először adjuk hozzá a H2 függőségként:

 com.h2adatbázis h2 1.4.196 

Ismét ellenőrizhetjük az illesztőprogram legújabb verzióját, amely elérhető a Maven Central-on. Hozzáadnánk a Flyway plugint is, amint azt korábban kifejtettük.

3.2. Konfigurálja a Flyway-t külső fájl használatával

Ezután létrehozunk myFlywayConfig.properties ban ben $ PROJECT_ROOT a következő tartalommal:

flyway.user = databaseUser flyway.password = databasePassword flyway.schemas = app-db flyway.url = jdbc: h2: mem: DATABASE flyway.locations = fájlrendszer: db / migráció

A fenti konfiguráció meghatározza, hogy az áttelepítési szkriptjeink a db / migráció Könyvtár. A memóriában lévő H2 példányhoz kapcsolódik databaseUser és databasePassword.

Az alkalmazás adatbázis sémája app-db.

Természetesen kicseréljük flyway.user, flyway.password, és flyway.url saját adatbázisunk felhasználónevével, adatbázis jelszavával és az adatbázis URL-jével megfelelően.

3.3. Adja meg az első migrációt

A Flyway betartja a migrációs szkriptek következő elnevezési szokását:

__. sql

Hol:

• - Az alapértelmezett előtag: V, amely a fenti konfigurációs fájlban konfigurálható a flyway.sqlMigrationPrefix ingatlan.
• - Migrációs verziószám. A nagyobb és a kisebb változatot elválaszthatja aláhúzás. Az áttelepítési verziónak mindig 1-gyel kell kezdődnie.
• - A migráció szöveges leírása. A leírást kettős aláhúzással kell elválasztani a verziószámoktól.

Példa: V1_1_0__my_first_migration.sql

Tehát hozzunk létre egy könyvtárat db / migráció ban ben $ PROJECT_ROOT nevű áttelepítési szkriptet V1_0__create_employee_schema.sql SQL utasításokat tartalmaz az alkalmazói tábla létrehozásához:

TÁBLÁZAT LÉTREHOZÁSA, HA NEM LÉTEZIK `alkalmazott '(` id` int NULL AUTO_INCREMENT PRIMARY KEY, `név` varchar (20),` email` varchar (50), `date_of_birth` időbélyeg) ENGINE = InnoDB DEFAULT CHARSET = UTF8;

3.4. Migrációk végrehajtása

Ezután a következő Maven parancsot hívjuk meg $ PROJECT_ROOT az adatbázis-migrációk végrehajtásához:

$ mvn tiszta repülési út: migrate -Dflyway.configFile = myFlywayConfig.properties

Ennek az első sikeres migrációnknak kell lennie.

Az adatbázis-sémát most a következőképpen kell ábrázolni:

alkalmazott: + ---- + ------ + ------- + --------------- + | id | név | email | születési dátum | + ---- + ------ + ------- + --------------- +

Megismételhetjük a definiálási és végrehajtási lépéseket további migrációk elvégzéséhez.

3.5. A második áttelepítés meghatározása és végrehajtása

Lássuk, hogyan néz ki a második áttelepítés, létrehozva egy második áttelepítési fájlt névvel V2_0_create_department_schema.sql a következő két kérdést tartalmazza:

TÁBLÁZAT LÉTREHOZÁSA, HA NINCS LÉTEZNI `osztály« (`id` int NULL AUTO_INCREMENT PRIMARY KEY,` név` varchar (20)) MOTOR = InnoDB DEFAULT CHARSET = UTF8; ALTER TÁBLÁZAT `alkalmazott` ADD` dept_id` int `email 'UTÁN;

Hasonló migrációt hajtunk végre, mint első alkalommal.

És most, az adatbázis-sémánk megváltozott, és új oszlopot adott hozzá munkavállaló és egy új táblázat:

alkalmazott: + ---- + ------ + ------- + --------- + --------------- + | id | név | email | dept_id | születési dátum | + ---- + ------ + ------- + --------- + --------------- +

osztály: + ---- + ------ + | id | név | + ---- + ------ +

Most a következő Maven parancs meghívásával ellenőrizhetjük, hogy mindkét áttelepítés valóban sikeres volt-e:

$ mvn repülési út: info -Dflyway.configFile = myFlywayConfig.properties

4. A Flyway letiltása a tavaszi csomagtartóban

Néha szükségünk lehet rá bizonyos körülmények között tiltsa le a Flyway migrációkat.

Például bevett gyakorlat az adatbázisok sémájának létrehozása az entitások alapján a tesztek során. Ilyen helyzetben letilthatjuk a Flyway-t a teszt profil.

Lássuk milyen könnyű ez a Spring Boot-ban.

4.1. Tavaszi csizma 1.x

Csak annyit kell tennünk állítsa be a repülési út.engedélyezett ingatlan a mi alkalmazás- teszt.tulajdonságok fájl:

flyway.enabled = hamis

4.2. Tavaszi csizma 2.x

A Spring Boot legújabb verzióiban ez a tulajdonság megváltozott tavasz.repülés.engedélyezett:

spring.flyway.enabled = hamis

4.3 Üres FlywayMigrationStrategy

Ha csak akarjuk indításkor tiltsa le az automatikus Flyway migrációt, de továbbra is kézzel tudja kiváltani az átállást, akkor a fent leírt tulajdonságok használata nem jó választás.

Ennek oka, hogy ilyen helyzetben a Spring Boot nem állítja be automatikusan a Repülőút bab már. Következésképpen egyedül kell biztosítanunk, ami nem túl kényelmes.

Tehát, ha ez a mi esetünk, akkor hagyhatjuk engedélyezve a Flyway-t és egy üreset is megvalósíthatunk FlywayMigrationStrategy:

@Configuration public class EmptyMigrationStrategyConfig {@Bean public FlywayMigrationStrategy flywayMigrationStrategy () {return flyway -> {// do nothing}; }}

Ez eredményesen tiltsa le a Flyway migrációt az alkalmazás indításakor.

De az átállást továbbra is manuálisan tudjuk kiváltani:

@RunWith (SpringRunner.class) @SpringBootTest nyilvános osztály ManualFlywayMigrationIntegrationTest {@Autowired private Flyway flyway; @Test public void skipAutomaticAndTriggerManualFlywayMigration () {flyway.migrate (); }}

5. Hogyan működik a repülési út

Annak nyomon követéséhez, hogy mely migrációkat alkalmazták már, mikor és ki, külön könyvelési táblázatot ad hozzá a sémához. Ez a metaadat-táblázat nyomon követi az áttelepítés ellenőrző összegeit és azt is, hogy az áttelepítések sikeresek voltak-e vagy sem.

A keretrendszer a következő lépéseket hajtja végre a fejlődő adatbázis-sémák befogadásához:

1. Megvizsgálja az adatbázis-sémát, hogy megtalálja a metaadat-táblázatot (SCHEMA_VERSION alapértelmezés szerint). Ha a metaadat-tábla nem létezik, létrehozza azt
2. Megvizsgálja az alkalmazás osztályterületét az elérhető áttelepítések után
3. Összehasonlítja a migrációkat a metaadat-táblázattal. Ha a verziószám alacsonyabb vagy egyenlő az aktuálisként megjelölt verzióval, akkor azt figyelmen kívül hagyják
4. A fennmaradó migrációkat függőben lévő migrációkként jelöli. Ezeket a verziószám alapján rendezik és sorrendben hajtják végre
5. Az egyes áttelepítések alkalmával a metaadat-tábla ennek megfelelően frissül

6. Parancsok

A Flyway az alábbi alapvető parancsokat támogatja az adatbázis-migrációk kezeléséhez.

• Info: Kiírja az adatbázis-séma aktuális állapotát / verzióját. Kinyomtatja, hogy mely migrációk vannak függőben, mely migrációkat alkalmazták, mi az alkalmazott migrációk állapota és mikor alkalmazták őket.
• Vándorol: Áttelepíti az adatbázis-sémát az aktuális verzióra. Megvizsgálja az osztályútvonalat az elérhető áttelepítések után, és függőben lévő áttelepítéseket alkalmaz.
• Alapvonal: Meglévő adatbázis kiindulása, kivéve az összes áttelepítést, beleértve baselineVersion. A Baseline segít elindítani a Flyway-t egy meglévő adatbázisban. Az újabb migrációkat ezután normálisan lehet alkalmazni.
• Érvényesít: Érvényesíti az aktuális adatbázis-sémát az elérhető áttelepítésekkel szemben.
• Javítás: Javítja a metaadat-táblázatot.
• Tiszta: Minden objektumot eldob egy konfigurált sémából. Az összes adatbázis-objektum eldobásra kerül. Természetesen soha nem szabad tiszta verziót használni semmilyen termelési adatbázisban.

7. Következtetés

Ebben a cikkben bemutattuk, hogyan működik a Flyway, és hogyan használhatjuk ezt a keretrendszert az alkalmazás-adatbázisunk megbízható átalakításához.

A cikkhez tartozó kód a GitHubon érhető el.