Hei Thomas,
Takk for at du deler refleksjonene dine rundt Flyway og databasemigrering i Nikita-prosjektet. Det du peker på er svært relevante og viktige betraktninger, både teknisk og strategisk, og jeg ønsker å komme med noen akademisk funderte perspektiver som kan bidra til en videre diskusjon.
For det første er det riktig observert at både Hibernate og Flyway opererer i skjæringspunktet mellom databasedefinisjon og migrasjonskontroll. Der Hibernate har som formål å kartlegge objektmodell til databasen og i noen tilfeller auto-generere skjema, er Flyway eksplisitt utviklet for å håndtere versjonering og kontrollert migrering av databasestrukturer. Dette kan føre til overlapping og i noen tilfeller konflikt, særlig hvis man forsøker å bruke begge uten en klar strategi for ansvarfordeling.
En viktig grunn til at mange prosjekter benytter Flyway eller Liquibase, til tross for en viss læringskurve, er at man med disse verktøyene får:
* Versjonshistorikk for databasestruktur (via migreringsskript som sjekkes inn i versjonskontroll)
* Reproduserbarhet i ulike miljøer (dev, test, staging, prod)
* Automatisert initiering og oppdatering av skjema – spesielt viktig i CI/CD-kjeder Når det gjelder stabilitet og feilmeldinger i møte med PostgreSQL, er det forståelig at frustrasjon kan oppstå dersom det ikke er tydelig hva som feiler. Det kan i mange tilfeller spores til forskjeller i konfigurasjon, inkompatible datatyper eller skript som kjøres uten idempotente sjekker. Det er mulig å mitigere mye av dette ved å innføre gode utviklingsmønstre – f.eks. oppdeling av migreringer i initielle og inkrementelle skript og tydelig dokumentasjon av antatte forhåndsbetingelser. Din skepsis til lukkede modeller og kommersialisering (det du kaller "enshitification") er også en reell utfordring i samtiden. I Flyways tilfelle finnes det heldigvis en under Apache 2.0-lisens, som dekker det aller meste av funksjonaliteten vi trenger. Og skulle dette endre seg, er det alltid mulig å migrere over til alternativer som Liquibase https://www.liquibase.org/ (også med FOSS-kjerne) eller til og med bygge egne migreringsstrategier basert på SQL og versjonsstyring.
Når det gjelder spørsmålet om «når» man skal ta det i bruk: Jeg er helt enig i at det handler om riktig tidspunkt og prioritering. Så lenge migrasjoner kan håndteres manuelt og det er akseptabelt innenfor prosjektets tidsrammer og risikobilde, er det ingen hast med å innføre ytterligere verktøy. Men dersom man i fremtiden ønsker:
* Distribuert utvikling
* Flere produksjonsmiljøer
* Automatisert testing
* Full CI/CD-integrasjon ... da vil et verktøy som Flyway eller tilsvarende sannsynligvis gjøre mer nytte enn skade.
Jeg setter pris på det arbeidet dere har gjort i de eksisterende Flyway-grenene, og foreslår at vi ser på disse som et grunnlag for videre arbeid når tiden og kapasiteten tillater det. Det viktigste er at vi sikrer at databasemigrering – uansett verktøy – skjer på en transparent og kontrollert måte som tåler langsiktig vedlikehold.
Jeg hørte første gang om Flyway på M.I.T. da jeg tok en tur innom SIPB-kontoret 18. juni 2014 og snakket med en som jobber i Amazon med utvikling av AWS som bruker Flyway fra Red Gate.
https://www.red-gate.com/products/flyway/community/
Mvh, Ole Aamot
Aamot Research
On Thursday, April 17, 2025 at 11:36:41 am +02:00, Thomas John Sødring tsodring@oslomet.no wrote:
Hei,
Du vil se at nikita har noen gren med flyway erfaringer:
https://gitlab.com/OsloMet-ABI/nikita-noark5-core/-/branches/active
Dette er for meg ikke i utgangspunkt et spørsmål om hvordan vi bruker flyway, det er mer et spørsmål om når vi tar det i bruk. Mine enkle tester av flyway med PostgreSQL gjorde at jeg ble skeptisk fordi jeg fikk feilemeldinger ofte. Da bruker jeg tid som jeg egentlig ikke har til å jobbe med det som oppleves for med som idiotiske feil., da flyway skal gjøre livet mitt enklere, ikke vanskeligere. Kanskje det er noe med at hibernate og flyway ikke helt får det til. Begge er en beskrivelse av databasen, mens flyway håndterer migrasjon, noe hibernate ikke er laget for.
Når det er sagt så er det sikkert manglende kompetanse og tid til å ta et flyway kurs for å forstå det riktig. Som oftest fungerer de enkle eksemplene godt i dev-modus. Videre er både flyway og liquibase veldig kommersielle og med den generelle enshitification vi ser med programvare, er jeg skeptisk til å bruke tid på et program som plutselig kan lukkes. Da blir det kanskje et spørsmål hvorvidt prosjektet er interessant nok til at noen vil jobbe med en fork.
Om man ønsker å ta i bruk flyway så håper jeg at det som er i flyway grenene gir det som trengs. Når den lange listen av viktige ting blir kortere så kan vi bruke mer tid på flyway. Fram til da så er vi dessverre nødt til gjøre dette manuelt.
Thomas
Fra: Ole Aamot ole@aamot.software Sendt: torsdag 17. april 2025 11:14 Til: Petter Reinholdtsen pere@hungry.com Kopi: nikita-noark@nuug.no nikita-noark@nuug.no Emne: Re: Tre nye indekser for PostgreSQL
On Thursday, April 17, 2025 at 11:09:35 am +02:00, Ole Aamot ole@aamot.software wrote:
On Thursday, April 17, 2025 at 11:02:16 am +02:00, Ole Aamot ole@aamot.software wrote:
On Thursday, April 17, 2025 at 10:44:35 am +02:00, Ole Aamot ole@aamot.software wrote:
On Tuesday, April 15, 2025 at 7:58:16 am +02:00, Petter Reinholdtsen pere@hungry.com wrote:
[Ole Aamot]
Var det dette du tenkte på med tanke på databasemigrering?
Nei. Jeg snakker om at Nikita skal oppdatere databasen ved oppstart, hvis den ikke har forventet datastruktur. Aha, da skjønner jeg! Du tenker på en form for automatisk migrering ved oppstart av applikasjonen – altså at hvis databasen mangler tabeller eller felter, så skal Nikita (programmet) selv kunne opprette eller oppdatere strukturen uten manuell inngripen.
En slik løsning innebærer ofte at man ved oppstart sjekker:
Om databasen finnes.
Om nødvendige tabeller eksisterer.
Om felter og indekser er på plass.
Og eventuelt kjører migreringsskript for å oppdatere databasen til siste "versjon". Eksempel på hvordan man kan gjøre dette i Python med SQLite:
Og hvis du vil at Nikita skal sjekke og oppdatere databasen ved oppstart, finnes det et par etablerte måter å gjøre dette på i Java-verdenen. Den vanligste og tryggeste løsningen er å bruke et migreringsverktøy som: ✅ Flyway eller Liquibase Disse verktøyene lar deg versjonere og kjøre databasemigreringer automatisk ved oppstart – typisk via main() eller Spring Boot-lifecycle. Jeg er sikker på at det finnes Python-bibliotek av enten Flyway eller Liquibase, som du kan benytte i noark5-tester, til å skrive migreringsskript i Python i stedet for Java, som er mitt valgte språk etter IN105-studium ved IFI i 1998, men jeg er sikker på at du løser dette enkelt som den superflinke programmeren du er, Petter. :-)
...og for de som vil lære mer om Python med å løse knapsack problemer og Dijkstra er den akademiske veien dit https://introcomp.mit.edu/spring25 og 6.100B veien å gå videre etter 6.100A.
Mvh, Ole Aamot