Artikkelen forklarer hvordan utviklere kan bygge trygge seed-filer for MySQL 8. Den tar for seg idempotens, rekkefølge, unike nøkler, tegnsett, transaksjoner, verifikasjon og syntaksvalg som tåler drift over tid.
Seed-filer brukes ofte i starten av et prosjekt, men de blir viktige igjen hver gang et miljø skal bygges opp, testes eller repareres. En god seed-fil er derfor ikke bare en engangsimport. Den er en kontrollert oppskrift.
I et CMS kan seed-data være roller, kategorier, standardinnstillinger, tagger, startsider og systemtekster. Slike data er små sammenlignet med artikkelinnhold, men de er ofte kritiske. Hvis en rolle, kategori eller systeminnstilling får feil ID eller dublett, kan feilen spre seg til kontrollpanel, frontend og tilgangsstyring.
Seed-data er ikke testdata
Testdata kan være midlertidig. Seed-data beskriver grunnverdier systemet forventer å finne. Derfor bør seed-filer skrives mer konservativt enn raske utviklingsscript. De bør være lesbare, kommenterte og trygge å kjøre på et eksisterende miljø.
Idempotens er hovedregelen
En seed-fil bør helst kunne kjøres flere ganger uten å lage dubletter. Det krever at systemet har stabile nøkler å slå opp på. For tagger kan det være slug. For roller kan det være rollenavn eller en fast kode. For innstillinger kan det være en nøkkel som site_name eller maintenance_mode.
Hvis seed-filen bare setter inn nye rader med autoinkrementerte ID-er, kan samme fil lage nye kopier hver gang den kjøres. Da blir den farlig i drift.
Bruk tydelig rekkefølge
Seed-data har ofte avhengigheter. Roller bør finnes før medlemmer får rolle. Kategorier bør finnes før artikler kobles til kategori. Tagger bør finnes før koblingstabeller fylles. En trygg seed-fil legger derfor inn grunnverdier før relasjoner.
Unngå skjult avhengighet til auto-ID
Autoinkrementerte ID-er er praktiske, men seed-filer bør ikke stole blindt på at de får samme verdi i alle miljøer. Hvis en kobling trenger en ID, kan filen først slå opp ID-en basert på en stabil nøkkel. Det gjør filen mer robust på utvikling, staging og produksjon.
Tegnsett og transaksjon
For norsk innhold og teknisk tekst bør patchen starte med SET NAMES utf8mb4. Det reduserer risikoen for at æ, ø, å, typografiske tegn eller kodeeksempler lagres feil. Der det er mulig, bør endringene pakkes i en transaksjon slik at en feil kan rulles tilbake samlet.
Verifikasjon er en del av seed-filen
En seed-fil bør avslutte med spørringer som viser hva som finnes etter kjøring. Det kan være antall roller, kategorier, tagger eller systeminnstillinger. Da blir filen lettere å bruke i MySQL Workbench og enklere å kontrollere før man går videre.
Konklusjon
Trygge seed-filer handler om disiplin. De skal ikke bare få databasen til å se riktig ut én gang. De skal kunne brukes på nytt, forstås senere og tåle forskjeller mellom miljøer. For små produksjonssystemer er dette en enkel måte å redusere risiko på.