Følgende indekser ble kvitt noen sekvensielle postgresql-søk under testing:
create index as_record_entity_record_series_id_index on as_record_entity USING btree(record_series_id); create index as_file_file_series_id_index on as_file USING btree(file_series_id); create index as_record_entity_record_file_id_index on as_record_entity USING btree(record_file_id);
Jeg tror de bør legges inn i datamodellen. Dette kan kanskje være et godt eksempel for hvordan databasemigrering gjøres? Noen som kan gi oppskrift?
Klart! Her er en enkel og grei oppskrift på hvordan du eksporterer (pg_dump) og importerer (psql) en PostgreSQL-database ved hjelp av pg_dump og psql
Eksportere en PostgreSQL-database (pg_dump)
Verktøy: pg_dump
Du kan også eksportere til en vanlig .sql-fil: Dump:
pg_dump -U postgres -h localhost -d min_database -F p -f min_backup.sql Import:
psql -U postgres -h localhost -d ny_database -f min_backup.sql
Var det dette du tenkte på med tanke på databasemigrering?
Mvh, Ole Aamot
On Monday, April 14, 2025 at 11:55:30 am +02:00, Petter Reinholdtsen pere@hungry.com wrote:
Følgende indekser ble kvitt noen sekvensielle postgresql-søk under testing:
create index as_record_entity_record_series_id_index on as_record_entity USING btree(record_series_id); create index as_file_file_series_id_index on as_file USING btree(file_series_id); create index as_record_entity_record_file_id_index on as_record_entity USING btree(record_file_id);
Jeg tror de bør legges inn i datamodellen. Dette kan kanskje være et godt eksempel for hvordan databasemigrering gjøres? Noen som kan gi oppskrift?
-- Vennlig hilsen Petter Reinholdtsen _______________________________________________ nikita-noark mailing list -- nikita-noark@nuug.no To unsubscribe send an email to nikita-noark-leave@nuug.no
[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.
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:
1. Om databasen finnes.
2. Om nødvendige tabeller eksisterer.
3. Om felter og indekser er på plass.
4. 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.
👇 Eksempel med Flyway (mest brukt) 1. Legg til Flyway-avhengighet (Maven): <dependency> <groupId>org.flywaydb</groupId> <artifactId>flyway-core</artifactId> <version>10.0.0</version> </dependency>
2. Lag en migrasjonsfil i resources/db/migration/: F.eks. V1__create_users_table.sql
CREATE TABLE IF NOT EXISTS users ( id INT PRIMARY KEY, username VARCHAR(255) NOT NULL, email VARCHAR(255) );
3. I Java-koden:
import org.flywaydb.core.Flyway;
public class Main { public static void main(String[] args) { Flyway flyway = Flyway.configure() .dataSource("jdbc:sqlite:nikita.db", null, null) .load();
// Migrer databasen ved oppstart flyway.migrate();
// Start appen etterpå System.out.println("Database oppdatert. Starter Nikita..."); } }
Alternativ: Manuell sjekk ved oppstart Hvis du ikke vil bruke et eksternt bibliotek, kan du gjøre noe sånt:
Connection conn = DriverManager.getConnection("jdbc:sqlite:nikita.db"); DatabaseMetaData meta = conn.getMetaData(); ResultSet tables = meta.getTables(null, null, "users", null);
if (!tables.next()) { // Tabell finnes ikke – opprett Statement stmt = conn.createStatement(); stmt.executeUpdate("CREATE TABLE users (id INTEGER PRIMARY KEY, username TEXT, email TEXT)"); }
Men dette kan bli vanskelig å vedlikeholde i lengden hvis du har mange tabeller og endringer.
📌 Anbefaling: Bruk Flyway. Det er lett, ryddig og lar deg kontrollere endringer med versjonering.
Vil du at jeg setter opp en ferdig Flyway-basert migreringsstruktur for deg? Vi kan skreddersy den til enten SQLite, PostgreSQL eller MySQL, alt etter hva du bruker.
Mvh, Ole Aamot
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.
👇 Eksempel med Flyway (mest brukt)
- Legg til Flyway-avhengighet (Maven):
<dependency> <groupId>org.flywaydb</groupId> <artifactId>flyway-core</artifactId> <version>10.0.0</version> </dependency> 2. Lag en migrasjonsfil i resources/db/migration/: F.eks. V1__create_users_table.sql
CREATE TABLE IF NOT EXISTS users ( id INT PRIMARY KEY, username VARCHAR(255) NOT NULL, email VARCHAR(255) );
- I Java-koden:
import org.flywaydb.core.Flyway;
public class Main { public static void main(String[] args) { Flyway flyway = Flyway.configure() .dataSource("jdbc:sqlite:nikita.db", null, null) .load();
// Migrer databasen ved oppstart flyway.migrate();
// Start appen etterpå System.out.println("Database oppdatert. Starter Nikita..."); } }
Alternativ: Manuell sjekk ved oppstart Hvis du ikke vil bruke et eksternt bibliotek, kan du gjøre noe sånt:
Connection conn = DriverManager.getConnection("jdbc:sqlite:nikita.db"); DatabaseMetaData meta = conn.getMetaData(); ResultSet tables = meta.getTables(null, null, "users", null);
if (!tables.next()) { // Tabell finnes ikke – opprett Statement stmt = conn.createStatement(); stmt.executeUpdate("CREATE TABLE users (id INTEGER PRIMARY KEY, username TEXT, email TEXT)"); }
Men dette kan bli vanskelig å vedlikeholde i lengden hvis du har mange tabeller og endringer.
📌 Anbefaling: Bruk Flyway. Det er lett, ryddig og lar deg kontrollere endringer med versjonering.
Vil du at jeg setter opp en ferdig Flyway-basert migreringsstruktur for deg? Vi kan skreddersy den til enten SQLite, PostgreSQL eller MySQL, alt etter hva du bruker. Her kommer en strukturert og fungerende mal for Flyway-baserte migreringsoppsett både for SQLite og PostgreSQL, med én katalogstruktur og to ulike main()-metoder for å kunne bruke begge miljøene hver for seg.
📁 Prosjektstruktur nikita-flyway/ ├── src/ │ └── main/ │ ├── java/ │ │ └── com/nikita/db/ │ │ ├── SQLiteMigrator.java │ │ └── PostgresMigrator.java │ └── resources/ │ ├── db/ │ │ ├── migration_sqlite/ │ │ │ └── V1__create_users_table.sql │ │ └── migration_postgres/ │ │ └── V1__create_users_table.sql ├── pom.xml
🧪 Eksempel-Migreringsfil resources/db/migration_sqlite/V1__create_users_table.sql CREATE TABLE IF NOT EXISTS users ( id INTEGER PRIMARY KEY, username TEXT NOT NULL, email TEXT );
resources/db/migration_postgres/V1__create_users_table.sql
CREATE TABLE IF NOT EXISTS users ( id SERIAL PRIMARY KEY, username VARCHAR(255) NOT NULL, email VARCHAR(255) );
🧠 SQLiteMigrator.java
package nikita.db;
import org.flywaydb.core.Flyway;
public class SQLiteMigrator { public static void main(String[] args) { Flyway flyway = Flyway.configure() .dataSource("jdbc:sqlite:nikita.db", null, null) .locations("classpath:db/migration_sqlite") .load();
flyway.migrate();
System.out.println("SQLite-databasen er oppdatert!"); } }
🧠 PostgresMigrator.java
package com.nikita.db;
import org.flywaydb.core.Flyway;
public class PostgresMigrator { public static void main(String[] args) { Flyway flyway = Flyway.configure() .dataSource( "jdbc:postgresql://localhost:5432/nikita", "postgres", "passord123" // sett passord her ) .locations("classpath:db/migration_postgres") .load();
flyway.migrate();
System.out.println("PostgreSQL-databasen er oppdatert!"); } }
🧱 pom.xml (med Flyway + JDBC for SQLite og PostgreSQL)
<project xmlns="http://maven.apache.org/POM/4.0.0" ...> <modelVersion>4.0.0</modelVersion> <groupId>com.nikita</groupId> <artifactId>nikita-flyway</artifactId> <version>1.0-SNAPSHOT</version>
<dependencies> <dependency> <groupId>org.flywaydb</groupId> <artifactId>flyway-core</artifactId> <version>10.0.0</version> </dependency>
<!-- SQLite JDBC --> <dependency> <groupId>org.xerial</groupId> <artifactId>sqlite-jdbc</artifactId> <version>3.45.1.0</version> </dependency>
<!-- PostgreSQL JDBC --> <dependency> <groupId>org.postgresql</groupId> <artifactId>postgresql</artifactId> <version>42.7.1</version> </dependency> </dependencies> </project>
✅ Kjøring For å migrere SQLite:
mvn compile exec:java -Dexec.mainClass="com.nikita.db.SQLiteMigrator"
For å migrere PostgreSQL:
mvn compile exec:java -Dexec.mainClass="com.nikita.db.PostgresMigrator"
Her er .zip-filen med Flyway-migreringsprosjektet for både SQLite og PostgreSQL:
👉 📦 Innhold
* Full Maven-prosjektstruktur
* Ferdige migrator-klasser for begge databaser
* Egne migreringsskript for SQLite og PostgreSQL ▶️ Slik kjører du det
1. Pakk ut zip-filen.1
2. Naviger inn i mappen:
3. Kjør SQLite-migrering: 4. mvn compile exec:java -Dexec.mainClass="com.nikita.db.SQLiteMigrator"
5. Kjør PostgreSQL-migrering:
6. mvn compile exec:java -Dexec.mainClass="com.nikita.db.SQLiteMigrator" Gi beskjed hvis du vil legge til flere migrasjoner eller automatisk oppstart, Petter!
Mvh, Ole Aamot
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. :-) Mvh,
Ole Aamot
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
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:
1. Om databasen finnes.
2. Om nødvendige tabeller eksisterer.
3. Om felter og indekser er på plass.
4. 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
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