Regeneratie-veilige schema-evolutie houdt productiedata geldig wanneer de backend-code wordt geregenereerd. Leer een praktische manier om schemawijzigingen en migraties te plannen.
Wanneer je backend wordt geregenereerd vanuit een visueel model, kan een databasewijziging voelen als het aanhalen van een draad in een trui. Je past een veld aan in de Data Designer, klikt op regenereer, en plotseling verander je niet alleen een tabel. Je verandert ook de gegenereerde API, validatieregels en de queries die je app gebruikt om data te lezen en te schrijven.
Wat meestal misgaat is niet dat de nieuwe code niet bouwt. Veel no-code platforms (waaronder AppMaster, dat echte Go-code genereert voor backends) genereren elke keer vrolijk een schoon project. Het echte risico is dat er al productiedata bestaat en dat die zich niet automatisch herschikt om bij je nieuwe plannen te passen.
De twee fouten die mensen het eerst opmerken zijn eenvoudig:
Beide fouten zijn pijnlijk omdat ze kunnen verborgen blijven totdat echte gebruikers ze tegenkomen. Een staging-database is misschien leeg of vers gevuld, dus alles lijkt in orde. Productie heeft randgevallen: nulls waar je waarden verwachtte, oude enum-strings of rijen die zijn aangemaakt voordat een nieuwe regel bestond.
Daarom is regeneratie-veilige schema-evolutie belangrijk. Het doel is om elke wijziging veilig te maken, zelfs wanneer de backend-code volledig wordt geregenereerd, zodat oude records geldig blijven en nieuwe records nog steeds aangemaakt kunnen worden.
"Voorspelbare migraties" betekent simpelweg dat je vier vragen kunt beantwoorden voordat je uitrolt: wat verandert er in de database, wat gebeurt er met bestaande rijen, welke versie van de app kan nog werken tijdens de uitrol, en hoe rol je terug als er iets onverwachts verschijnt.
Als je platform de backend kan regenereren, helpt het om drie dingen te scheiden in je hoofd: het databaseschema, de migratiestappen die het veranderen, en de live data die al in productie staat. Deze verwarring is waarom veranderingen onvoorspelbaar aanvoelen.
Zie regeneratie als "het opnieuw opbouwen van de applicatiecode vanuit het nieuwste model." In een tool zoals AppMaster kan die rebuild vaak gebeuren: je stuurt een veld bij, past businesslogica aan, voegt een endpoint toe, regenereert, test, herhaal. Regeneratie is frequent. Je productiedatabase zou dat niet moeten zijn.
Hier is het eenvoudige model.
Geregenereerde code moet worden behandeld als "de huidige app die praat met het huidige schema." Migraties zijn de brug die schema en runtime data op elkaar afstemt terwijl de code verandert.
Als je vaak regenereert, zul je vanzelf veel kleine schema-aanpassingen doen. Dat is normaal. Het risico ontstaat wanneer die aanpassingen een databaseverandering impliceren die niet achterwaarts compatibel is, of wanneer je migratie niet deterministisch is.
Een praktische manier om dit te beheren is regeneratie-veilige schema-evolutie te plannen als een reeks kleine, omkeerbare stappen. In plaats van één grote switch voer je gecontroleerde bewegingen uit die oude en nieuwe codepaden een korte tijd samen laten werken.
Bijvoorbeeld, als je een kolom wilt hernoemen die wordt gebruikt door een live API, hernoem deze dan niet meteen. Voeg eerst de nieuwe kolom toe, schrijf naar beide kolommen, vul bestaande rijen achteraf in, en schakel dan reads over naar de nieuwe kolom. Verwijder de oude kolom pas daarna. Elke stap is makkelijk te testen, en als er iets misgaat kun je pauzeren zonder data te beschadigen.
Dit mentale model maakt migraties voorspelbaar, zelfs als code-regeneratie dagelijks gebeurt.
Wanneer je backend wordt geregenereerd vanaf het nieuwste schema, gaat de code ervan uit dat de database dat schema nu al heeft. Daarom gaat regeneratie-veilige schema-evolutie minder over "Kunnen we de database veranderen?" en meer over "Kunnen oude data en oude requests overleven terwijl we de wijziging uitrollen?"
Sommige veranderingen zijn van nature veilig omdat ze bestaande rijen of queries niet ongeldig maken. Andere veranderen de betekenis van data of verwijderen iets dat de draaiende app nog verwacht — dáár ontstaan productie-incidenten.
Additieve wijzigingen zijn het makkelijkst te leveren omdat ze naast oude data kunnen bestaan.
Voorbeeld: het toevoegen van een nullable middle_name-kolom aan een users-tabel is doorgaans veilig. Bestaande rijen blijven geldig, geregenereerde code kan het lezen wanneer aanwezig, en oudere rijen hebben gewoon NULL.
Deze wijzigingen werken vaak technisch, maar breken gedrag. Ze vragen zorgvuldige coördinatie omdat regeneratie validaties, gegenereerde modellen en aannames in de businesslogica bijwerkt.
Hernoemingen zijn de klassieke valkuil: phone hernoemen naar mobile_phone kan leiden tot geregenereerde code die phone niet meer leest, terwijl productiedata nog in phone staat. Evenzo kan het veranderen van eenheden (prijs in dollars vs cents) berekeningen stilletjes corrumperen als je code vóór data aanpast of andersom.
Enums zijn een ander scherp randje. Het aanscherpen van een enum (waarden verwijderen) kan bestaande rijen ongeldig maken. Het uitbreiden van een enum is meestal veilig, maar alleen als alle codepaden de nieuwe waarde kunnen verwerken.
Een praktische aanpak is betekenissen te behandelen als "voeg nieuw toe, backfill, schakel, verwijder later."
Destructieve wijzigingen zijn de wijzigingen die productie meestal direct breken, vooral als het platform code regenereert die niet langer de oude vorm verwacht.
Een kolom of tabel verwijderen, of een kolom veranderen van nullable naar not-null, kan writes direct laten falen zodra een request een rij zonder die waarde probeert in te voegen. Zelfs als je denkt dat "alle rijen het al hebben", kan het volgende randgeval of een achtergrondtaak anders uitwijzen.
Als je een not-null wijziging moet doen, voer deze dan in fases uit: voeg de kolom eerst als nullable toe, backfill, wijzig de app-logic zodat het altijd wordt gezet, en dwing dan not-null af.
Indexen en constraints zijn geen "data-vorm" wijzigingen, maar kunnen nog steeds downtime veroorzaken. Het aanmaken van een index op een grote tabel of het toevoegen van een unieke constraint kan writes lang genoeg blokkeren om timeouts te veroorzaken. In PostgreSQL zijn bepaalde bewerkingen veiliger met online-vriendelijke methodes, maar het belangrijkste is timing: voer zware operaties uit tijdens lage belasting en meet hoe lang ze duren op een staging-kopie.
Wanneer wijzigingen extra zorg vereisen in productie, plan dan voor:
Als je een platform zoals AppMaster gebruikt dat backend-code regenereert vanuit de Data Designer, is de veiligste mindset: lever veranderingen die oude data vandaag kunnen verdragen, en verscherp regels pas nadat het systeem zich heeft aangepast.
Geregenereerde backends zijn geweldig totdat een schemawijziging in productie landt en oude rijen niet meer bij de nieuwe vorm passen. Het doel van regeneratie-veilige schema-evolutie is simpel: houd je app werkend terwijl je database en geregenereerde code zich in kleine, voorspelbare stappen naar elkaar toe werken.
Behandel elke betekenisvolle wijziging als drie bewegingen. Breid eerst het schema uit zodat zowel oude als nieuwe code kunnen draaien. Migreer dan data. Verklein pas daarna door oude kolommen, defaults of constraints te verwijderen.
Een praktische regel: combineer nooit "nieuwe structuur" en "brekende opruiming" in dezelfde deploy.
Ga ervan uit dat er een periode zal zijn waarin:
Ontwerp je database zo dat beide vormen geldig zijn tijdens die overlap. Dit is extra belangrijk als een platform je backend regenereert vanuit het nieuwste model (bijv. in AppMaster wanneer je de Data Designer bijwerkt en de Go-backend regenereert).
Zorg eerst dat de nieuwe code oude data veilig kan lezen. Schakel pas daarna schrijfpaths om naar de nieuwe datavorm.
Bijvoorbeeld: als je een enkele status-kolom opsplitst naar status + status_reason, lever dan eerst code die met ontbrekende status_reason om kan gaan. Daarna begin je status_reason te schrijven voor nieuwe updates.
Wanneer je enums, non-null kolommen of strengere constraints toevoegt, beslis van tevoren wat er moet gebeuren als waarden ontbreken of onverwacht zijn:
Dit voorkomt stille corruptie (verkeerde defaults) en harde fouten (nieuwe constraints die oude rijen weigeren).
Rollback is het makkelijkst tijdens de expand-fase. Als je moet terugdraaien, moet de oude code nog steeds draaien tegen het uitgebreide schema. Schrijf op wat je zou terugdraaien (alleen code, of code plus migratie) en vermijd destructieve wijzigingen totdat je zeker weet dat je niet hoeft te undo'en.
Geregenereerde backends zijn onverbiddelijk: als schema en gegenereerde code niet overeenkomen, vindt productie dat meestal als eerste. De veiligste aanpak is elke wijziging als een kleine, omkeerbare rollout te behandelen, zelfs als je zonder-code tools gebruikt.
Begin met de intentie in gewone taal op te schrijven en hoe je data er vandaag uitziet. Kies 3 tot 5 echte rijen uit productie (of een recente dump) en noteer de rommelige delen: lege waarden, oude formaten, verrassende defaults. Dit voorkomt dat je een perfect nieuw veld ontwerpt dat echte data niet kan vullen.
Hier is een praktische volgorde die goed werkt wanneer je platform backend-code regenereert (bijv. wanneer AppMaster Go-backendservices regenereert uit het Data Designer-model):
Breid eerst uit, vervang niet. Voeg nieuwe kolommen of tabellen toe op een additieve manier. Maak nieuwe velden eerst nullable, of geef ze veilige defaults. Als je een nieuwe relatie introduceert, laat de foreign key leeg totdat je die hebt gevuld.
Deploy het uitgebreide schema zonder iets te verwijderen. Voer de databasewijziging uit terwijl de oude code nog werkt. Het doel: oude code blijft de oude kolommen schrijven en de database accepteert dat.
Backfill in een gecontroleerde job. Vul nieuwe velden met een batchproces dat je kunt monitoren en opnieuw kunt draaien. Houd het idempotent (het tweemaal draaien mag geen data corrumperen). Doe het geleidelijk bij grote tabellen en log hoeveel rijen zijn bijgewerkt.
Schakel reads eerst om, met fallback. Werk de geregenereerde logica bij om nieuwe velden te prefereren, maar val terug op oude velden wanneer nieuwe data ontbreekt. Pas zodra reads stabiel zijn, schakel writes om naar de nieuwe velden.
Opruimen als laatste stap. Zodra je vertrouwen hebt (en een rollback-plan), verwijder oude velden en verscherp constraints: maak NOT NULL, voeg unieke constraints toe en handhaaf foreign keys.
Concreet voorbeeld: je wilt een vrije-tekst status-kolom vervangen door status_id die verwijst naar een statuses-tabel. Voeg status_id toe als nullable, backfill vanuit bestaande tekstwaarden, werk de app bij om status_id te lezen maar terug te vallen op status wanneer null, en drop tenslotte status en maak status_id verplicht. Dit houdt elke regeneratie veilig omdat de database op elk moment compatibel blijft.
Wanneer je backend wordt geregenereerd, kunnen kleine schema-aanpassingen doorslaan naar API's, validatieregels en UI-formulieren. Het doel van regeneratie-veilige schema-evolutie is veranderingen zo uit te voeren dat oude data geldig blijft terwijl nieuwe code wordt uitgerold.
Een directe hernoeming is riskant omdat oude records en oude code vaak het originele veld nog verwachten. Een veiligere aanpak is het behandelen van een hernoeming als een korte migratieperiode.
customer_phone) en behoud de oude (phone).customer_phone voor alle huidige records gevuld is.Dit werkt goed in tools zoals AppMaster waar regeneratie datamodellen en endpoints uit het huidige schema opbouwt. Dual-write houdt beide generaties code tevreden tijdens de transitie.
Het opsplitsen van full_name in first_name en last_name is vergelijkbaar, maar de backfill is lastiger. Houd full_name totdat je zeker weet dat de split compleet is.
Een praktische regel: verwijder het originele veld niet totdat elk record is bijgewerkt of een duidelijke fallback heeft. Als parsing faalt, sla de hele string op in last_name en markeer het record voor review.
Een nullable veld verplicht maken is een klassieke productiebreker. De veilige volgorde is: backfill eerst, handhaaf later.
Backfill kan mechanisch zijn (stel een default) of business-gedreven (vraag gebruikers om ontbrekende data in te vullen). Pas nadat de data compleet is, voeg je NOT NULL toe en werk je validatie bij. Als je geregenereerde backend automatisch strengere validatie toevoegt, voorkomt deze volgorde verrassende fouten.
Enum-wijzigingen breken wanneer oude code oude waarden blijft sturen. Tijdens een transitie accepteer je tijdelijk beide.
Als je "pending" wilt vervangen door "queued", houd dan beide waarden geldig en map ze in je logica. Zodra je zeker weet dat geen clients de oude waarde sturen, verwijder je die.
Als de wijziging in één release moet gebeuren, verklein het risico door de blast radius te beperken:
Deze patronen houden migraties voorspelbaar, zelfs wanneer geregenereerde code zich snel gedraagt.
De grootste verrassingen ontstaan wanneer mensen regeneratie als een magische resetknop beschouwen. Geregenereerde backends kunnen je applicatiecode netjes houden, maar je productiedatabase bevat nog steeds de data van gisteren, in de vorm van gisteren. Regeneratie-veilige schema-evolutie betekent dat je voor beide plant: de nieuwe code die gegenereerd zal worden en de oude records die nog in tabellen zitten.
Een veelvoorkomende val is aannemen dat het platform "de migraties wel zal afhandelen." Bijvoorbeeld, in AppMaster kun je een Go-backend regenereren vanuit je bijgewerkte Data Designer-model, maar het platform kan niet raden hoe je echte klantdata wilt transformeren. Als je een nieuw verplicht veld toevoegt, heb je nog steeds een duidelijk plan nodig voor hoe bestaande rijen een waarde krijgen.
Een andere verrassing is velden te vroeg droppen of hernoemen. Een veld lijkt misschien niet gebruikt in de hoofd-UI, maar kan nog steeds gelezen worden door een rapport, een geplande export, een webhook-handler of een adminscherm dat iemand zelden opent. De wijziging lijkt veilig in testen, maar faalt in productie omdat één vergeten codepad de oude kolomnaam nog verwacht.
Vijf fouten die vaak nachtelijke rollbacks veroorzaken:
Een eenvoudig scenario: je hernoemt phone naar mobile_number, voegt een NOT NULL constraint toe en regenereert. De app schermen kunnen werken, maar een oudere CSV-export selecteert nog steeds phone, en duizenden bestaande records hebben mobile_number null. De remedie is meestal een gefaseerde wijziging: voeg de nieuwe kolom toe, schrijf tijdelijk naar beide, backfill veilig, en verscherp constraints en verwijder het oude veld pas na bewijs dat niets er nog van afhankelijk is.
Als je backend wordt geregenereerd, kan de code snel veranderen, maar je productiedata vergeeft geen verrassingen. Voer vóór deploy een korte "kan dit veilig falen?"-check uit. Het houdt regeneratie-veilige schema-evolutie saai (wat je wilt).
Als je een nieuw verplicht veld status aan een orders-tabel toevoegt, push dat dan niet meteen als "NOT NULL, zonder default." Voeg het eerst toe als nullable met een default voor nieuwe rijen, deploy geregenereerde code die ontbrekende status aankan, backfill oude rijen en verscherp pas daarna constraints.
In AppMaster is deze mindset vooral nuttig omdat de backend vaak geregenereerd kan worden. Behandel elke schemawijziging als een kleine release met een eenvoudige rollback, en je migraties blijven voorspelbaar.
Stel je een intern supporttool voor waar agents tickets een vrije-tekstveld priority geven (bijv. "high", "urgent", "HIGH", "p1"). Je wilt overschakelen naar een strikte enum zodat rapporten en routeringsregels niet meer hoeven te raden.
De veilige aanpak is een wijziging in twee releases die oude records geldig houdt terwijl je backend regenereert.
Begin met het schema uit te breiden zonder iets te verwijderen. Voeg een nieuw enum-veld toe, bijvoorbeeld priority_enum met waarden low, medium, high, urgent. Houd het originele priority_text veld.
Werk de logica bij zodat nieuwe en bewerkte tickets naar beide velden schrijven. In een no-code tool zoals AppMaster betekent dat meestal het bijwerken van het Data Designer-model en de Business Process zodat input zowel naar de enum als naar de originele tekst wordt weggeschreven.
Vervolgens backfill je bestaande tickets in kleine batches. Map veelvoorkomende tekstwaarden naar de enum ("p1" en "urgent" -> urgent, "HIGH" -> high). Alles onbekends kun je tijdelijk op medium zetten en later reviewen.
Wat gebruikers zien: idealiter niets verandert. De UI toont nog steeds dezelfde priority-control, maar achter de schermen vul je de nieuwe enum. Rapporten kunnen de enum al gebruiken zodra de backfill loopt.
Als je vertrouwen hebt, schakel reads volledig om naar priority_enum, werk filters en dashboards bij en verwijder vervolgens priority_text in een latere migratie.
Voor Release 2 valideer met een kleine steekproef zodat je randgevallen opvangt:
medium).Als er problemen verschijnen, is rollback eenvoudig omdat Release 1 het oude veld behoudt: redeploy Release 1-logica en stel de UI weer in op priority_text terwijl je de mapping fixeert en de backfill opnieuw draait.
Als je voorspelbare migraties wilt, behandel schemawijzigingen als een klein project, niet als een snelle edit. Het doel is simpel: elke wijziging moet makkelijk uit te leggen, makkelijk te oefenen en moeilijk per ongeluk te breken zijn.
Een visueel datamodel helpt omdat het impact zichtbaar maakt voordat je deployt. Als je tabellen, relaties en veldtypes in één overzicht ziet, mis je minder snel dingen zoals een verplicht veld zonder veilige default of een relatie die oude records zal verweesden. Doe een snelle "wie hangt hiervan af?"-check: APIs, schermen, rapporten en achtergrondjobs.
Als je een veld moet veranderen dat al in gebruik is, kies dan voor een korte transitieperiode met gedupliceerde velden. Voeg bijvoorbeeld phone_e164 toe en houd phone_raw nog een of twee releases. Werk businesslogica bij om uit het nieuwe veld te lezen als het aanwezig is en terug te vallen op het oude veld als dat niet zo is. Schrijf tijdens de transitie naar beide velden en verwijder het oude veld pas nadat je hebt geverifieerd dat de data volledig is backfilled.
Omgevingsdiscipline zet goede intenties om in veilige releases. Houd dev, staging en productie op elkaar afgestemd, maar beschouw ze niet als identiek:
Maak je migratieplan een echt document, ook als het kort is. Neem op: wat verandert, de volgorde, hoe je backfillt, hoe je verifieert en hoe je terugdraait. Voer het vervolgens end-to-end uit in een testomgeving voordat het productie raakt.
Als je AppMaster gebruikt, vertrouw dan op de Data Designer om visueel over het model na te denken en laat regeneratie je backend-code consistent houden met het bijgewerkte schema. De gewoonte die voorspelbaarheid brengt is migraties expliciet maken: je kunt snel itereren, maar elke wijziging heeft nog steeds een gepland pad voor bestaande productiedata.
21 jan 2026
8 min
20 jan 20268 min
20 jan 20267 minExperimenteer met AppMaster met gratis abonnement.
Als je er klaar voor bent, kun je het juiste abonnement kiezen.
