背景
packages/db/drizzle/ にマイグレーションはコミットされる方針(project.md)だが、デプロイ時に誰がいつ適用するか、金銭・監査テーブルへの破壊的変更をどう扱うか、バックアップ/復旧をどうするかは未決。
なぜ今決めるか
複数レプリカでブート時自動適用にすると起動レースでマイグレーションが競合し得る。append-only の台帳・監査テーブルに破壊的変更(列の型変更・drop・再作成)を掛けると履歴が壊れる。会計記録・監査・会員マッピングは失うと Stripe からの再突合でも完全復元できない部分がある。いずれも運用開始後は不可逆で、方針が無いまま入ると損失が取り返せない。
論点・選択肢
- 適用戦略: デプロイのリリースフェーズで単発実行するか、ブート時自動か。ロールバック不能な破壊的変更の扱い。
- 金銭/監査テーブルの非破壊: 追加のみ(列追加は nullable/デフォルト付き)、破壊的変更は新テーブル + バックフィルの expand-contract に限定する。
- バックアップ/復旧: 頻度・保持・リストア手順・PITR の要否。「会計記録は再構築不能ゆえバックアップ必須」という要件を確定。頻度や基盤の責任分界(自前か NeoShowcase 側か)は情報不足なら暫定。
- マイグレーション前後のバックアップ義務化。
受け入れ条件
- マイグレーション適用戦略・金銭テーブルの非破壊方針・バックアップ必須の要件が決まっている。
- 運用実態に依存する数値/手順は暫定と明示され、要件は今確定している。
関連
project.md のマイグレーション規約を金銭テーブル向けに具体化。ブート時自動適用の競合はデプロイ・トポロジ(単一/複数レプリカ)の決定に依存する。お金の記録アーキテクチャと接続する。
背景
packages/db/drizzle/にマイグレーションはコミットされる方針(project.md)だが、デプロイ時に誰がいつ適用するか、金銭・監査テーブルへの破壊的変更をどう扱うか、バックアップ/復旧をどうするかは未決。なぜ今決めるか
複数レプリカでブート時自動適用にすると起動レースでマイグレーションが競合し得る。append-only の台帳・監査テーブルに破壊的変更(列の型変更・drop・再作成)を掛けると履歴が壊れる。会計記録・監査・会員マッピングは失うと Stripe からの再突合でも完全復元できない部分がある。いずれも運用開始後は不可逆で、方針が無いまま入ると損失が取り返せない。
論点・選択肢
受け入れ条件
関連
project.md のマイグレーション規約を金銭テーブル向けに具体化。ブート時自動適用の競合はデプロイ・トポロジ(単一/複数レプリカ)の決定に依存する。お金の記録アーキテクチャと接続する。