Comments on: Tips for databasemigreringer

By: Johannes Brodwall

Johannes Brodwall — Mon, 30 Nov 2009 18:09:32 +0000

Det stemmer at med denne løsningen vil v2 måtte være forberedt på at data ligger i gammelt format. Dette er mer automatisk med triggere, men også litt mer magisk. Jeg ville valgt løsning avhengig av hvor omfattende testing jeg hadde av databasefunksjonalitet.

By: anderssv

anderssv — Mon, 30 Nov 2009 12:28:43 +0000

Da må V2 støtte begge kolonner da? Og holde de oppdatert, og lese begge? Hvis ikke vil jo V1 skrive til gammel kolonne som ikke blir vist/fanget opp i V2. Tror jeg ville gått for triggerløsningen i dette tilfellet, men løsning i kode kan være bedre for en annen situasjon.

Som Ferris sier så må man ha regime på dette med disiplin. F.eks. 6 måneder etter at en kolonne blir deprecated så slettes den og det kommuniseres ut til alle.

Fant stoff på denne bloggen og: http://exortech.com/blog/2009/02/01/weekly-rele... . De har et eget rammeverk med expansion/contraction skille. Virker nok best i tilfellene hvor du ikke har noen eksterne forbrukere du må vente lenge på.

By: Johannes Brodwall

Johannes Brodwall — Mon, 30 Nov 2009 10:09:32 +0000

By: anderssv

anderssv — Mon, 30 Nov 2009 04:28:43 +0000

Som Ferris sier så må man ha regime på dette med disiplin. F.eks. 6 måneder etter at en kolonne blir deprecated så slettes den og det kommuniseres ut til alle.

By: Johannes Brodwall

Johannes Brodwall — Thu, 26 Nov 2009 19:44:09 +0000

Alternativ for rename/redefine column:

1. Sett i produksjon en databaseendring med den nye kolonnen.
2. Kjør migreringsscript av selve data til den nye kolonnen (kan gjentas som ofte man vil)
3. Produksjonsett ny versjon (v2) av systemet parallelt med gammel versjon. Ny versjon må takle at kolonnen er NULL
4. Når man er helt sikker på at man vil gå videre, skru av gammel versjon (v1) og kjør migreringsscript for data en siste gang
5. Ny versjon av programmet (v3) som ignorerer gammel kolonne (kan kjøres i parallell med forrige versjon - v2)
6. Skru av v2
7. Dropp gammel kolonne

Det krever litt oppfølgning. Men alle stegene er reverserbare. Jeg foretrekker en slik strategi dersom frykt for feil gjør at man ikke vil produksjonsette.

By: Thomas Ferris Nicolaisen

Thomas Ferris Nicolaisen — Thu, 26 Nov 2009 12:08:40 +0000

Her er det lettest å peke på “boken” igjen. Jeg tror jo lenger uti du blar, jo vanskeligere blir det. Her er en fin oversikt forresten: http://www.agiledata.org/essays/databaseRefacto...

Det å legge til nye tabeller og kolonner er temmelig rett frem, men det er typisk knyttet til nyutvikling. Når det gjelder refaktorering, så må man typisk gjøre ting i flere faser. F.eks Rename Column: (1) opprett ny kolonne, (2) lag trigger som oppdaterer gammel kolonne i en overgangsperioden, (3) rull ut nye applikasjoner som bruker ny kolonne, (4) fjern gammel kolonne.

Hele roundtripen tar lang tid, krever tunga rett i munnen, og mye disiplin for spesielt å være sikker på at (3) og (4) blir fulgt opp. Overgangstiden kan være alt fra noen minutter (i et cluster som vi har), eller åresvis (klientapplikasjoner i andre team).

Det er 60 teknikker i “boka”, og man må beherske databasen sin godt. Man må øve mye, og ha gode regresjonstester, som Anders sier. Mye jobb for mitt lille team, altså :)

By: jhannes

jhannes — Thu, 26 Nov 2009 11:49:15 +0000

Bakoverkompatible databaseendringer er jo et tema vi kunne diskutert mer.

Som et trivielt eksempel: Det å legge til en ny tabell som er uavhengig av resten av skjema er alltid bakoverkompatibelt. Det å legge til en kolonne er nesten alltid kompatibelt.

Hvilke databaseendringer er vanlige og vanskelig å gjøre bakoverkompatible? Eksempler, plz! :-)

By: tfnico

tfnico — Thu, 26 Nov 2009 10:17:04 +0000

Vi deployer applikasjon og databaseendring samtidig. Vi har mye live trafikk på databasen, så vi tør nesten ikke annet. Uansett, det er veldig kjedelig å ha nedetid, både for kunder og ansatte (man skal gjerne ha det utenfor primetime også). Hvis vi kunne ha mestret teknikkene i boka til Ambler så kunne vi oppgradert databasen først.. Det hadde vært gull. Men per i dag så virker det så komplisert (mye arbeid å være bakoverkompatibel!) at jeg ikke kommer noen vei når jeg tar det opp i teamet.

By: anderssv

anderssv — Thu, 26 Nov 2009 06:00:15 +0000

Galskap er det nok ikke, men besnærende. ;) Bare usikker på verdien, og at man må holde tunga rett i munnen.

Men dette er spennende. Erfaringer burde samles, kanskje man kunne kjørt en XP Meetup rundt temaet?

By: geirhedemark

geirhedemark — Wed, 25 Nov 2009 17:27:13 +0000

Mnah, kan bli littegrann bedre:

“Les database refactoring av Ambler, Sadalage”
“Skriv tester som tester mot databasen, ellers vet du ikke hva du gjør”
“Unngå mest mulig av triggere, prosedyrer, views. Bruk mest mulig tabeller med minst mulig features – det er enklest å teste.”
“Sørg for at applikasjonen tester at den kjører mot riktig versjon av skjemaet”