Vi har i dag postgresql-støtte med https://github.com/igrishaev/pg2. Migratus funker kun med jdbc (og kanskje jdbc.next). Så jeg tror ganske enkelt Migratus ikke løser noen problemer for oss.
Så jeg prøver med Ragtime.
Systemdesign: migrasjoner på Mikrobloggeriet
Jeg ser for meg:
Vi kjører migrasjoner på app-oppstart. Etter vi har fått en database-connection, før vi starter HTTP-serveren.
Vi skriver migrasjoner med opp- og ned-kommandoer (så vi kan migrere fram og tilbake)
Vi bruker Ragtime, men mapper over til igrishaev/pg2 selv.
Beskrivelse av implementasjon
Jeg gikk for Ragtime. Jeg synes det var midt i blinken. At Ragtime er database-agnostisk viste seg å være noe jeg likte. Det krevde lite kode å sette opp, og nå slipper vi magi vi ikke har kontroll over.
Systemdesign
Logikk for migrering er i det nye navnerommet mikrobloggeriet.db.migrate.
Jeg har flyttet tilstanden for det kjørende systemet til mikrobloggeriet.repl/state. Tidligere lå denne i user, og før det lå den i mikrobloggeriet.serve. Ved å flytte den til mikrobloggeriet.repl/state kan vi referere til den fra andre steder, feks mikrobloggeriet.db.migrate.
Til lokal utvikling kan man bruke mikrobloggeriet.db.migrate/migrate-dev!. migrate-dev! kan kun kjøres lokalt, men støtter å rulle både framover og bakover. I produksjon ruller vi ikke bakover, fordi da risikerer vi å miste data. I lokal utvikling er dette en fin mulighet å kunne ha mens man jobber med database-skjemaer.
Migreringsstrategi
Ved oppstart gjør vi en migrering, så lenge vi kjører med en database. Migrering på oppstart migrerer kun framover.
For å jobbe med skjemastruktur lokalt kan vi migrere fram og tilbake med funksjonen mikrobloggeriet.db.migrate/migrate-dev!. Denne krasjer hvis den kjøres på hops (krever at HOPS_ENV ikke er satt).
Designspørsmål
Motivasjon for å gjøre dette, og grovt hvordan vi kan gjøre det.
Motivasjon
Nå som vi har PostgreSQL-støtte må vi ha en måte å jobbe med SQL-skjemaer. Det kalles migrasjoner.
Jeg vet om to migrering-biblioteker:
Alternativ: Ragtime
Skrevet av James Reeves (også skrevet Ring, Compojure og Hiccup). Litt lavnivå, litt "samle sammen det du trenger". Litt lite dokumentasjon.
Det følger med et lavnivå migrerings-grensesnitt som ikke er koblet på SQL. Som er litt kult.
Alternativ: Migratus
Skrevet av Dmitri Sotnikov, som også har skrevet en bok om web-utvikling i Clojure: https://pragprog.com/titles/dswdcloj3/web-development-with-clojure-third-edition/
Ragtime eller Migratus, hva er best for oss?
Vi har i dag postgresql-støtte med https://github.com/igrishaev/pg2. Migratus funker kun med jdbc (og kanskje jdbc.next). Så jeg tror ganske enkelt Migratus ikke løser noen problemer for oss.
Så jeg prøver med Ragtime.
Systemdesign: migrasjoner på Mikrobloggeriet
Jeg ser for meg:
Beskrivelse av implementasjon
Jeg gikk for Ragtime. Jeg synes det var midt i blinken. At Ragtime er database-agnostisk viste seg å være noe jeg likte. Det krevde lite kode å sette opp, og nå slipper vi magi vi ikke har kontroll over.
Systemdesign
mikrobloggeriet.db.migrate.mikrobloggeriet.repl/state. Tidligere lå denne iuser, og før det lå den imikrobloggeriet.serve. Ved å flytte den tilmikrobloggeriet.repl/statekan vi referere til den fra andre steder, feksmikrobloggeriet.db.migrate.mikrobloggeriet.db.migrate/migrate-dev!.migrate-dev!kan kun kjøres lokalt, men støtter å rulle både framover og bakover. I produksjon ruller vi ikke bakover, fordi da risikerer vi å miste data. I lokal utvikling er dette en fin mulighet å kunne ha mens man jobber med database-skjemaer.Migreringsstrategi
mikrobloggeriet.db.migrate/migrate-dev!. Denne krasjer hvis den kjøres på hops (krever atHOPS_ENVikke er satt).