streamalism.org

1. Introduktion

Denne artikel beskriver nøglebegreber Flyway og hvordan vi kan bruge denne ramme til kontinuerligt at ombygge vores applikations databaseskema pålideligt og nemt. I slutningen præsenterer vi et eksempel på styring af en in-memory H2-database ved hjælp af et Maven Flyway-plugin.

Flyway opdaterer en database fra en version til en anden ved hjælp af migrationer. Vi kan skrive migreringer enten i SQL med databasespecifik syntaks eller i Java til avancerede databasetransformationer.

Overførsler kan enten være versioneret eller gentages. Førstnævnte har en unik version og anvendes nøjagtigt en gang. Sidstnævnte har ikke en version. I stedet anvendes de (igen) hver gang deres checksum ændres.

Inden for en enkelt migreringskørsel anvendes gentagelige migreringer altid sidst, efter at verserende migreringer er udført. Gentagelige migreringer anvendes i rækkefølge efter beskrivelsen. For en enkelt migrering køres alle udsagn inden for en enkelt databasetransaktion.

I denne artikel fokuserer vi primært på, hvordan vi kan bruge Maven-pluginet til at udføre databasemigreringer.

2. Flyway Maven-plugin

For at installere et Flyway Maven-plugin, lad os tilføje følgende definition af plugin til vores pom.xml:

 org.flywaydb flyway-maven-plugin 4.0.3 

Vi kan kontrollere den nyeste version af det plugin, der findes på Maven Central.

Dette Maven-plugin kan konfigureres på fire forskellige måder. Se dokumentationen for at få en liste over alle konfigurerbare egenskaber.

2.1. Plugin-konfiguration

Vi konfigurerer muligvis pluginet direkte via tag i plugin-definitionen af ​​vores pom.xml:

 org.flywaydb flyway-maven-plugin 4.0.3 database Bruger database Passord skema Navn ... 

2.2. Maven Properties

Vi kan også konfigurere pluginet ved at angive konfigurerbare egenskaber som Maven ejendomme i vores pom:

 ... databaseBrugerdatabasePassword skemanavn ... ... 

2.3. Ekstern konfigurationsfil

Vi kan også levere plugin-konfiguration i en separat .ejendomme fil:

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

Standardkonfigurationsfilnavnet er flyway.properties og det skal være i samme bibliotek som pom.xml fil. Kodning er specificeret af flyway.encoding (Standard er UTF-8).

Hvis du bruger et andet navn (f.eks customConfig.properties) som konfigurationsfil, skal den angives eksplicit, når man påberåber Maven-kommandoen:

$ mvn -Dflyway.configFile = customConfig.properties

2.4. Systemegenskaber

Endelig kan alle konfigurationsegenskaber også specificeres som systemegenskaber, når de påkalder Maven på kommandolinjen:

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

Følgende er en rækkefølge, når en konfiguration er specificeret på mere end en måde:

1. Systemegenskaber
2. Ekstern konfigurationsfil
3. Maven ejendomme
4. Plugin-konfiguration

3. Eksempel på migration

I dette afsnit gennemgår vi de nødvendige trin for at migrere et databaseskema til en H2-database i hukommelsen ved hjælp af Maven-pluginet. Vi bruger en ekstern fil til at konfigurere Flyway.

3.1. Opdater POM

Lad os først tilføje H2 som en afhængighed:

 com.h2database h2 1.4.196 

Vi kan igen kontrollere den nyeste version af driveren, der er tilgængelig på Maven Central. Vi tilføjede også Flyway-pluginet som forklaret tidligere.

3.2. Konfigurer Flyway ved hjælp af ekstern fil

Dernæst opretter vi myFlywayConfig.properties i $ PROJECT_ROOT med følgende indhold:

flyway.user = databaseUser flyway.password = databasePassword flyway.schemas = app-db flyway.url = jdbc: h2: mem: DATABASE flyway.locations = filsystem: db / migration

Ovenstående konfiguration specificerer, at vores migrationsscript er placeret i db / migration vejviser. Den opretter forbindelse til en H2-hukommelse i hukommelsen ved hjælp af databaseUser og databasePassword.

Applikationsdatabaseskemaet er app-db.

Selvfølgelig erstatter vi det flyway.user, flyway.password, og flyway.url med vores eget database-brugernavn, database-adgangskode og database-URL passende.

3.3. Definer første migration

Flyway overholder følgende navngivningskonvention for migrationsskripter:

__. kvl

Hvor:

• - Standardpræfikset er V, som kan konfigureres i ovenstående konfigurationsfil ved hjælp af flyway.sqlMigrationPrefix ejendom.
• - Migrationsversion nummer. Store og mindre versioner kan adskilles af en understreg. Migrationsversionen skal altid starte med 1.
• - Tekstbeskrivelse af migrationen. Beskrivelsen skal adskilles fra versionsnumrene med dobbelt understregning.

Eksempel: V1_1_0__my_first_migration.sql

Så lad os oprette et bibliotek db / migration i $ PROJECT_ROOT med et navngivet migrationsscript V1_0__create_employee_schema.sql indeholdende SQL-instruktioner til oprettelse af medarbejdertabellen:

Opret TABEL, HVIS IKKE FINDER 'medarbejder' ('id' int IKKE NULL AUTO_INCREMENT PRIMÆR NØGLE, 'navn' varchar (20), 'email' varchar (50), 'date_of_birth` tidsstempel) MOTOR = InnoDB STANDARD CHARSET = UTF8;

3.4. Udfør migrationer

Dernæst påkalder vi følgende Maven-kommando fra $ PROJECT_ROOT at udføre databasemigreringer:

$ mvn clean flyway: migrate -Dflyway.configFile = myFlywayConfig.properties

Dette skulle resultere i vores første vellykkede migration.

Databaseskemaet skal nu afbildes som følger:

medarbejder: + ---- + ------ + ------- + --------------- + | id | navn | e-mail | dato_fødsel | + ---- + ------ + ------- + --------------- +

Vi kan gentage definitions- og udførelsestrin for at udføre flere migrationer.

3.5. Definer og udfør anden migration

Lad os se, hvordan en anden migration ser ud ved at oprette en anden migreringsfil med navn V2_0_create_department_schema.sql der indeholder følgende to forespørgsler:

Opret TABEL, HVIS IKKE FINDER `afdeling` (` id` int IKKE NULL AUTO_INCREMENT PRIMÆR NØGLE, `navn` varchar (20)) MOTOR = InnoDB standard CHARSET = UTF8; ALTER TABEL `medarbejder` TILFØJ` dept_id` int EFTER `e-mail`;

Vi udfører en lignende migration, som vi gjorde første gang.

Og nu er vores databaseskema ændret for at tilføje en ny kolonne til medarbejder og et nyt bord:

medarbejder: + ---- + ------ + ------- + --------- + --------------- + | id | navn | e-mail | dept_id | dato_fødsel | + ---- + ------ + ------- + --------- + --------------- +

afdeling: + ---- + ------ + | id | navn | + ---- + ------ +

Vi kan nu kontrollere, at begge overførsler faktisk lykkedes ved at påkalde følgende Maven-kommando:

$ mvn flyway: info -Dflyway.configFile = myFlywayConfig.properties

4. Deaktivering af Flyway i Spring Boot

Nogle gange har vi muligvis brug for det deaktivere Flyway-migreringer under visse omstændigheder.

For eksempel er det en almindelig praksis at generere databaseskema baseret på enhederne under test. I en sådan situation kan vi deaktivere Flyway under prøve profil.

Lad os se hvor let det er i Spring Boot.

4.1. Spring Boot 1.x

Det eneste, vi skal gøre, er at Indstil flyway.enabled ejendom i vores applikationstest.egenskaber fil:

flyway.enabled = false

4.2. Spring Boot 2.x

I de nyere versioner af Spring Boot, denne ejendom er blevet ændret til spring.flyway.enabled:

spring.flyway.enabled = false

4.3 Tom FlywayMigrationStrategy

Hvis vi kun vil deaktivere automatisk Flyway-migrering ved opstart, men stadig være i stand til at udløse migrationen manuelt, så det er ikke et godt valg at bruge egenskaberne beskrevet ovenfor.

Det er fordi Spring Boot i en sådan situation ikke automatisk konfigurerer Flyway bønne længere. Derfor er vi nødt til at levere det alene, hvilket ikke er særlig praktisk.

Så hvis dette er vores brugssag, kan vi lade Flyway være aktiveret og implementere en tom FlywayMigrationStrategy:

@Configuration public class EmptyMigrationStrategyConfig {@Bean public FlywayMigrationStrategy flywayMigrationStrategy () {returflyve -> {// gør ingenting}; }}

Dette vil effektivt deaktiver Flyway-migrering ved opstart af applikationen.

Men vi kan stadig udløse migrationen manuelt:

@RunWith (SpringRunner.class) @SpringBootTest offentlig klasse ManualFlywayMigrationIntegrationTest {@Autowired private Flyway flyway; @Test offentlig ugyldighed skipAutomaticAndTriggerManualFlywayMigration () {flyway.migrate (); }}

5. Sådan fungerer Flyway

For at holde styr på, hvilke migreringer der allerede er anvendt, hvornår og af hvem, tilføjer det en særlig bogføringstabel til dit skema. Denne metadatatabel sporer også migrationskontrolsummen, og om migreringerne var vellykkede.

Rammen udfører følgende trin for at imødekomme databaseskemaer i udvikling:

1. Det kontrollerer et databaseskema for at finde metadatatabellen (SCHEMA_VERSION som standard). Hvis metadatatabellen ikke findes, oprettes den
2. Det scanner en applikations klassesti for tilgængelige migrationer
3. Den sammenligner migrationer med metadatatabellen. Hvis et versionsnummer er lavere eller lig med en version, der er markeret som aktuel, ignoreres det
4. Det markerer eventuelle resterende migrationer som ventende migrationer. Disse sorteres efter versionsnummer og udføres i rækkefølge
5. Når hver migrering anvendes, opdateres metadatatabellen i overensstemmelse hermed

6. Kommandoer

Flyway understøtter følgende grundlæggende kommandoer til at administrere databasemigrationer.

• Info: Udskriver den aktuelle status / version af et databaseskema. Den udskriver, hvilke migrationer der er i afventning, hvilke migreringer der er anvendt, hvad status for anvendte migrationer er, og hvornår de blev anvendt.
• Migrere: Migrerer et databaseskema til den aktuelle version. Det scanner klassestien for tilgængelige migrationer og anvender ventende migreringer.
• Baseline: Baserer en eksisterende database, ekskl. Alle migrationer inklusive baselineVersion. Baseline hjælper med at starte med Flyway i en eksisterende database. Nyere migreringer kan derefter anvendes normalt.
• Bekræft: Validerer aktuelt databaseskema mod tilgængelige migreringer.
• Reparation: Reparerer metadatatabel.
• Ren: Slipper alle objekter i et konfigureret skema. Alle databaseobjekter slettes. Selvfølgelig skal du aldrig bruge rent i nogen produktionsdatabase.

7. Konklusion

I denne artikel har vi vist, hvordan Flyway fungerer, og hvordan vi kan bruge denne ramme til at ombygge vores applikationsdatabase pålideligt.

Koden, der ledsager denne artikel, er tilgængelig på GitHub.