<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Datamigratie on dotkarl</title><link>https://www.karlvanheijster.com/tags/datamigratie/</link><description>Recent content in Datamigratie on dotkarl</description><generator>Hugo</generator><language>nl-NL</language><lastBuildDate>Fri, 22 Nov 2024 08:02:15 +0100</lastBuildDate><atom:link href="https://www.karlvanheijster.com/tags/datamigratie/index.xml" rel="self" type="application/rss+xml"/><item><title>Waar zit de fout?</title><link>https://www.karlvanheijster.com/blog/24/11/waar-zit-de-fout/</link><pubDate>Fri, 22 Nov 2024 07:55:22 +0100</pubDate><guid>https://www.karlvanheijster.com/blog/24/11/waar-zit-de-fout/</guid><description>Mijn collega bracht een argument in dat vaak wordt genoemd als ik mensen vertel over testen via de voordeur: maar door de code direct aan te roepen, geven mijn tests onmiddellijk feedback over &lt;em>waar&lt;/em> de fout zit. Als &lt;em>deze&lt;/em> tests beginnen te falen, dan weet ik zeker dat &lt;em>daar&lt;/em> de fout zit. En dat scheelt tijd in het debuggen van de code. &amp;ndash; Maar dat laat de volgende vraag onverlet: is een unittest (waarbij &amp;ldquo;unit&amp;rdquo; wordt opgevat als &amp;ldquo;eenheid van code&amp;rdquo;) het beste middel om erachter te komen waar de fout zit?</description></item><item><title>Gedachten over modelaanpassingen</title><link>https://www.karlvanheijster.com/blog/23/02/gedachten-over-modelaanpassingen/</link><pubDate>Fri, 17 Feb 2023 08:40:45 +0100</pubDate><guid>https://www.karlvanheijster.com/blog/23/02/gedachten-over-modelaanpassingen/</guid><description>Wanneer er modelwijzigingen in het spel zijn, dan is een wijziging van de code alléén niet voldoende. Je zult ook moeten zorgen voor een migratie die de oude data omzet naar het nieuwe model. Zo&amp;rsquo;n migratie kan verschillende vormen aannemen - &lt;em>big bang&lt;/em> of stapje voor stapje -, maar dat &amp;lsquo;ie er moet komen, staat vast. De vraag waar ik me op wil richten is: wannéér moet die migratie er komen?</description></item><item><title>De standaard versus de business</title><link>https://www.karlvanheijster.com/blog/22/04/de-standaard-versus-de-business/</link><pubDate>Mon, 18 Apr 2022 10:06:45 +0200</pubDate><guid>https://www.karlvanheijster.com/blog/22/04/de-standaard-versus-de-business/</guid><description>Onze business volgt de QTI-standaard, maar ze gebruiken niet alles. Zo bestaat er - op dit moment - nog geen behoefte om Items te construeren die uit meerdere rijen bestaan. Bij het modelleren van ons domein werden we voor een keus gesteld: volgen we de QTI-standaard bij het uitschrijven van ons model? Of leggen we alleen vast wat de business nodig heeft, en laten we ons eigen model daarmee afwijken van de standaard? Concreet: ondersteunen we meerdere rijen of niet?</description></item><item><title>Evolutionaire datamigratie met FluentMigrator</title><link>https://www.karlvanheijster.com/blog/21/10/evolutionaire-datamigratie-met-fluentmigrator/</link><pubDate>Fri, 22 Oct 2021 08:15:24 +0200</pubDate><guid>https://www.karlvanheijster.com/blog/21/10/evolutionaire-datamigratie-met-fluentmigrator/</guid><description>In het kort komt evolutionair databasedesign hier op neer. Stel, een ontwikkelaar maakt een wijziging in de code die een databasewijziging impliceert. In dat geval is het aan dezelfde ontwikkelaar om een migratiescript te schrijven die de codewijziging mogelijk maakt, en deze bij de codewijziging in te checken. De databasewijziging is onderdeel van de codewijziging, als het ware. En terecht, want zonder de databasewijziging is het niet mogelijk om de gewijzigde code te runnen.</description></item><item><title>Stapje voor stapje data migreren</title><link>https://www.karlvanheijster.com/blog/21/09/stapje-voor-stapje-data-migreren/</link><pubDate>Mon, 06 Sep 2021 07:13:30 +0200</pubDate><guid>https://www.karlvanheijster.com/blog/21/09/stapje-voor-stapje-data-migreren/</guid><description>Als er één constante is in softwareontwikkelland, dan is het wel dat software constant verandert. Nieuwe inzichten noodzaken ontwikkelaars om hun code aan te passen om bepaalde &lt;em>use cases&lt;/em> (beter) te kunnen ondersteunen. Soms betekent dat dat er een aanpassing moet plaatsvinden in je model. Hoe ga daarbij om met data die nog is opgeslagen volgens het verouderd model?</description></item></channel></rss>