L Harness D1 migration進化地図――スキーマを完成形ではなく変更履歴として読む

現在のschemaだけでは失われる互換性判断を、連番migrationと更新エンジンからどこまで復元できるか。

コードから観測できること

1. migrationにはentry routes、friend metadata、step branching、tracked links、forms、multi account、ad conversions、staff、broadcast queueなどが時系列で残る。製品の機能一覧をDB変更の履歴から検証できる。
2. 同じ番号帯を持つmigrationも存在するため、単純な数字順だけで適用済み判定を推測してはいけない。実際の適用管理と更新エンジンのmigration処理を合わせて読む必要がある。
3. 本番研究ではschemaの差分だけでなく、既存行へのdefault、index追加時間、途中失敗時の再実行、古いWorkerとの互換期間を記録対象にする。

再現・追加測定の手順

1. 空DBへ全migrationを適用する
2. 旧リリースのschemaへ段階的に適用する
3. 各段階でテーブル・index・制約をdumpする
4. 失敗を注入し再実行とrollback可能性を記録する

この資料だけでは証明できないこと

1. SQLite/D1のDDL制約により完全な逆migrationを作れない変更がある。
2. 空DB成功だけでは既存データ量が多い環境の所要時間を証明しない。

このページは新しいcommit、実測ログ、API仕様変更が得られた時点で更新します。古い観測条件と現在仕様を混同しないため、固定commitへのリンクを残します。