<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>afterschema on Aftermarket.dev</title>
    <link>https://aftermarket.dev/tags/afterschema/</link>
    <description>Recent content in afterschema on Aftermarket.dev</description>
    <generator>Hugo -- gohugo.io</generator>
    <language>en-us</language>
    <lastBuildDate>Wed, 21 Oct 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://aftermarket.dev/tags/afterschema/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>AfterSchema Released to Keep Old SQL Working After a Schema Change</title>
      <link>https://aftermarket.dev/afterschema-released-to-keep-old-sql-working-after-a-schema-change/</link>
      <pubDate>Wed, 21 Oct 2026 00:00:00 +0000</pubDate>
      
      <guid>https://aftermarket.dev/afterschema-released-to-keep-old-sql-working-after-a-schema-change/</guid>
      <description>Aftermarket 0.8.0 adds AfterSchema, run as aftermarket schema. It&amp;rsquo;s for the day an app&amp;rsquo;s database moves to a new shape and everything else that reads it breaks: the monthly report, the export script, the BI dashboard someone set up three years ago and nobody owns.
The app&amp;rsquo;s own code got updated with the migration. Those other readers didn&amp;rsquo;t, and usually nobody has a list of them. The fix people reach for is a few hand-written views, applied once and never tested.</description>
    </item>
    
    <item>
      <title>Case Study: Keeping Old Shop Reports Working After a Schema Change</title>
      <link>https://aftermarket.dev/case-study-keeping-old-shop-reports-working-after-a-schema-change/</link>
      <pubDate>Wed, 21 Oct 2026 00:00:00 +0000</pubDate>
      
      <guid>https://aftermarket.dev/case-study-keeping-old-shop-reports-working-after-a-schema-change/</guid>
      <description>This case uses the examples/legacy-shop folder that ships in every download archive, so you can run each step yourself. The shop is a stand-in. The commands and output below come from a real run of the downloaded aftermarket 0.8.0 on Linux, with sqlite3 3.45.
The situation A small shop app moved from 1.0 to 2.0. The new version renamed customers to accounts and split the name into first and last. It stops deleting accounts and marks them with a deleted_at date instead.</description>
    </item>
    
    <item>
      <title>How AfterSchema Was Tested</title>
      <link>https://aftermarket.dev/how-afterschema-was-tested/</link>
      <pubDate>Wed, 21 Oct 2026 00:00:00 +0000</pubDate>
      
      <guid>https://aftermarket.dev/how-afterschema-was-tested/</guid>
      <description>AfterSchema makes two promises that matter. It never writes a database. And when schema test says an old read gives the same rows through the views, it does: same values, same types, same column names. The tests go after both.
Same rows, checked hard The main test builds random tables, then a new version of each with renamed columns, numbers stored times 100, and columns split in two. It writes a mapping that should give the old values back and runs reads over every column against both.</description>
    </item>
    
  </channel>
</rss>
