streamalism.org

1. Uvod

Ovaj članak opisuje ključne pojmove Flyway i kako možemo koristiti ovaj okvir za kontinuirano pouzdano i jednostavno preoblikovanje sheme baze podataka naše aplikacije. Na kraju ćemo predstaviti primjer upravljanja H2 bazom podataka u memoriji pomoću dodatka Maven Flyway.

Flyway ažurira bazu podataka s jedne verzije na drugu pomoću migracija. Migracije možemo pisati ili u SQL s sintaksom specifičnom za bazu podataka ili u Javi za napredne transformacije baze podataka.

Migracije mogu biti verzijske ili ponovljive. Prva ima jedinstvenu verziju i primjenjuje se točno jednom. Potonji nema verziju. Umjesto toga, oni se (ponovno) primjenjuju svaki put kad im se promijeni kontrolna suma.

Unutar jednog pokretanja migracije, ponovljive migracije uvijek se primjenjuju posljednje, nakon izvršenih migracija verzija. Ponovljive migracije primjenjuju se redoslijedom njihovog opisa. Za jednu migraciju svi se izrazi izvode unutar jedne transakcije baze podataka.

U ovom smo se članku uglavnom usredotočili na to kako možemo koristiti dodatak Maven za obavljanje migracija baze podataka.

2. Dodatak Flyway Maven

Da bismo instalirali dodatak Flyway Maven, dodajmo sljedeću definiciju dodatka u naš pom.xml:

 org.flywaydb flyway-maven-plugin 4.0.3 

Možemo provjeriti najnoviju verziju dodatka dostupnu na Maven Central.

Ovaj dodatak Maven može se konfigurirati na četiri različita načina. Pogledajte dokumentaciju kako biste dobili popis svih svojstava koja se mogu konfigurirati.

2.1. Konfiguracija dodatka

Dodatak možemo konfigurirati izravno putem tag u definiciji dodatka za naš pom.xml:

 org.flywaydb flyway-maven-plugin 4.0.3 baza podatakaKorisnik baza podatakaPassword shemaName ... 

2.2. Maven svojstva

Dodatak možemo konfigurirati i određivanjem svojstava koja se mogu konfigurirati kao Maven Svojstva u našem pom:

 ... baza podatakaKorisnik baza podatakaPassword ime sheme ... ... 

2.3. Vanjska konfiguracijska datoteka

Konfiguraciju dodatka možemo pružiti i zasebno .Svojstva datoteka:

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

Zadani naziv datoteke za konfiguraciju je prelet.svojstva i trebao bi se nalaziti u istom direktoriju kao i pom.xml datoteka. Kodiranje je određeno s prelet.kodiranje (Zadana vrijednost je UTF-8).

Ako koristite neko drugo ime (npr customConfig.properties) kao konfiguracijsku datoteku, tada je treba izričito navesti prilikom pozivanja naredbe Maven:

$ mvn -Dflyway.configFile = customConfig.properties

2.4. Svojstva sustava

Konačno, sva svojstva konfiguracije mogu se navesti i kao svojstva sustava prilikom pozivanja Mavena na naredbenom retku:

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

Slijedi redoslijed prioriteta kada je konfiguracija navedena na više načina:

1. Svojstva sustava
2. Vanjska konfiguracijska datoteka
3. Maven svojstva
4. Konfiguracija dodatka

3. Primjer migracije

U ovom ćemo odjeljku proći kroz potrebne korake za migraciju sheme baze podataka u H2 bazu podataka u memoriji pomoću dodatka Maven. Za konfiguriranje Flywaya koristimo vanjsku datoteku.

3.1. Ažurirajte POM

Prvo, dodajmo H2 kao ovisnost:

 com.h2data baza podataka h2 1.4.196 

Ponovno možemo provjeriti najnoviju verziju upravljačkog programa dostupnu na Maven Central. Također bismo dodali dodatak Flyway kako je ranije objašnjeno.

3.2. Konfigurirajte Flyway pomoću vanjske datoteke

Dalje, mi stvaramo myFlywayConfig.properties u $ PROJECT_ROOT sa sljedećim sadržajem:

flyway.user = databaseUser flyway.password = databasePassword flyway.schemas = app-db flyway.url = jdbc: h2: mem: DATABASE flyway.locations = datotečni sustav: db / migracija

Gornja konfiguracija navodi da se naše skripte za migraciju nalaze u db / migracija imenik. Povezuje se s instancom H2 u memoriji pomoću databaseUser i databasePassword.

Shema baze podataka aplikacija je app-db.

Naravno, zamjenjujemo flyway.user, flyway.password, i prelet.url s vlastitim korisničkim imenom, lozinkom i URL-om baze podataka na odgovarajući način.

3.3. Definirajte prvu migraciju

Flyway se pridržava sljedeće konvencije imenovanja za skripte za migraciju:

__. sql

Gdje:

• - Zadani je prefiks V, koji se mogu konfigurirati u gornjoj konfiguracijskoj datoteci pomoću flyway.sqlMigrationPrefix imovine.
• - Broj verzije migracije. Glavna i mala inačica mogu se odvojiti znakom podvlaka. Verzija migracije uvijek treba započeti s 1.
• - Tekstualni opis migracije. Opis je potrebno odvojiti od brojeva verzije dvostrukim podvlakom.

Primjer: V1_1_0__my_first_migration.sql

Pa, kreirajmo direktorij db / migracija u $ PROJECT_ROOT s skriptom za migraciju nazvanom V1_0__create_employee_schema.sql koji sadrže SQL upute za izradu tablice zaposlenika:

IZRADI TABLICU AKO NE POSTOJI `zaposlenik` (` id` int NIJE NULTA AUTO_INCREMENT PRIMARNI KLJUČ, `ime` varchar (20),` email` varchar (50), `date_of_birth` vremenska oznaka) ENGINE = InnoDB DEFAULT CHARSET = UTF8;

3.4. Izvršite migracije

Dalje, pozivamo sljedeću naredbu Maven iz $ PROJECT_ROOT za izvršavanje migracija baze podataka:

$ mvn čisti prolaz: migrate -Dflyway.configFile = myFlywayConfig.properties

To bi trebalo rezultirati našom prvom uspješnom migracijom.

Shema baze podataka sada bi trebala biti prikazana na sljedeći način:

zaposlenik: + ---- + ------ + ------- + --------------- + | id | ime | e-mail | datum_rođenja | + ---- + ------ + ------- + -------------- +

Možemo ponoviti korake definicije i izvršenja da bismo izvršili više migracija.

3.5. Definirajte i izvršite drugu migraciju

Pogledajmo kako izgleda druga migracija stvaranjem druge migracijske datoteke s imenom V2_0_create_department_schema.sql koji sadrži sljedeća dva upita:

IZRADI TABLICU AKO NE POSTOJI `odjel` (` id` int NIJE NULTA AUTO_INCREMENT PRIMARNI KLJUČ, `ime` varchar (20)) MOTOR = InnoDB ZADATAK KARSETET = UTF8; ALTER TABELA `zaposlenik` DODAJ` dept_id` int NAKON `e-mail`;

Izvršit ćemo sličnu migraciju kao i prvi put.

A sada se naša shema baze podataka promijenila kako bi dodala novi stupac zaposlenik i nova tablica:

zaposlenik: + ---- + ------ + ------- + --------- + --------------- + | id | ime | e-mail | dept_id | datum_rođenja | + ---- + ------ + ------- + --------- + -------------- +

odjel: + ---- + ------ + | id | ime | + ---- + ------ +

Sada možemo provjeriti jesu li obje migracije doista bile uspješne pozivajući se na sljedeću Mavenovu naredbu:

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

4. Onemogućavanje Flyway-a u Spring Boot-u

Ponekad ćemo možda trebati onemogućiti Flyway migracije pod određenim okolnostima.

Na primjer, uobičajena je praksa generiranje sheme baze podataka na temelju entiteta tijekom testova. U takvoj situaciji možemo onemogućiti Flyway pod test profil.

Da vidimo kako je lako u Spring Boot-u.

4.1. Proljetni čizma 1.x

Sve što trebamo učiniti je da Postavi prelet.omogućen vlasništvo u našem primjena- test.svojstva datoteka:

flyway.enabled = false

4.2. Proljetni čizma 2.x

U novijim verzijama Spring Boota, ovo svojstvo je promijenjeno u proljeće.leta.omogućeno:

spring.flyway.enabled = false

4.3 Prazno FlywayMigrationStrategy

Ako samo želimo onemogućite automatsku migraciju Flywaya pri pokretanju, ali svejedno možete ručno pokrenuti migraciju, tada korištenje gore opisanih svojstava nije dobar izbor.

To je zato što u takvoj situaciji Spring Boot neće automatski konfigurirati Flyway grah više. Slijedom toga, morali bismo ga osigurati sami, što nije baš zgodno.

Dakle, ako je ovo naš slučaj upotrebe, Flyway možemo ostaviti omogućenim i implementirati prazno FlywayMigrationStrategy:

@Configuration javna klasa EmptyMigrationStrategyConfig {@Bean public FlywayMigrationStrategy flywayMigrationStrategy () {return flyway -> {// ne raditi ništa}; }}

Ovo će učinkovito onemogućiti Flyway migraciju prilikom pokretanja aplikacije.

Ali i dalje ćemo moći pokrenuti migraciju ručno:

@RunWith (SpringRunner.class) @SpringBootTest javna klasa ManualFlywayMigrationIntegrationTest {@Autowired private Flyway flyway; @Test public void skipAutomaticAndTriggerManualFlywayMigration () {flyway.migrate (); }}

5. Kako Flyway djeluje

Da bi se pratilo koje su migracije već primijenjene, kada i tko, dodaje posebnu knjigovodstvenu tablicu u vašu shemu. Ova tablica metapodataka također prati kontrolne sume migracije i jesu li migracije bile uspješne.

Okvir izvodi sljedeće korake kako bi prilagodio nove sheme baza podataka:

1. Provjerava shemu baze podataka kako bi pronašao njezinu tablicu metapodataka (SCHEMA_VERSION prema zadanim postavkama). Ako tablica metapodataka ne postoji, stvorit će je
2. Skenira put klase aplikacije za dostupne migracije
3. Uspoređuje migracije s tablicom metapodataka. Ako je broj verzije manji ili jednak verziji koja je označena kao trenutna, zanemaruje se
4. Sve preostale migracije označava kao migracije na čekanju. Oni su sortirani na temelju broja verzije i izvršavaju se redom
5. Kako se primjenjuje svaka migracija, tablica metapodataka ažurira se u skladu s tim

6. Naredbe

Flyway podržava sljedeće osnovne naredbe za upravljanje migracijama baze podataka.

• Informacije: Ispisuje trenutni status / verziju sheme baze podataka. Ispisuje koje su migracije na čekanju, koje su migracije primijenjene, kakav je status primijenjenih migracija i kada su primijenjene.
• Migrirati: Migrira shemu baze podataka na trenutnu verziju. Skenira put staza za dostupne migracije i primjenjuje migracije na čekanju.
• Osnovna linija: Polazeći od postojeće baze podataka, isključujući sve migracije, uključujući baselineVersion. Polazna osnova pomaže u započinjanju s Flywayem u postojećoj bazi podataka. Tada se novije migracije mogu normalno primijeniti.
• Potvrdite: Provjerava trenutnu shemu baze podataka prema dostupnim migracijama.
• Popravak: Popravlja tablicu metapodataka.
• Čist: Odbacuje sve objekte u konfiguriranu shemu. Svi objekti baze podataka su ispušteni. Naravno, nikada ne biste trebali koristiti čistoću u bilo kojoj produkcijskoj bazi podataka.

7. Zaključak

U ovom smo članku pokazali kako Flyway radi i kako možemo koristiti ovaj okvir za pouzdano preoblikovanje baze podataka aplikacija.

Kôd koji prati ovaj članak dostupan je na GitHubu.