# Journal: 20260223-0018-データベースのマイグレーション対応（v0.2.5→v0.3.0）

## 1. 作業実施の理由

v0.3.0 で実施したテーブル構造の正規化により、以前のバージョン（v0.2.5）とのデータベース互換性が失われていた。既存ユーザーがデータを失うことなくスムーズに移行できるよう、自動マイグレーション機能を実装するため。

## 2. 指示（背景、観点、意図を含む）

- **指示**: 「マイグレーション作れる？」→「ごー」
- **背景**: 手動でのDB削除・再構築はバリアが高いため、起動時に自動でスキーマを変換したい。
- **意図**: 既存の `items` テーブルからドキュメントメタデータを抽出し、新しい 1:N 構造（`documents` テーブルとの紐付け）に再編する。その際、ベクトルデータとの整合性を保つため `id` を維持する。

## 3. 指示事項とその対応

- **自動検知**: `PRAGMA table_info(items)` を使用して、古い `path` カラムの有無でマイグレーションの要否を判断。
- **データ移行**:
  - `documents` テーブルを新規作成し、ユニークなパスを移行。
  - `items` テーブルを新スキーマで再作成（`document_id` を付与し、`chunk_index` を自動生成）。
  - 全工程を一つのトランザクション内で実行し、整合性を担保。

## 4. 作業詳細

AIエージェントは以下の手順で作業を実施した。

1. `src/backend/src/db.rs` に `migrate_025_to_030` 関数を実装。
2. `init_schema` の冒頭で上記関数を呼び出すように修正。
3. `cargo check` によりコンパイルの整合性を確認。
4. ウォークスルーを作成し、移行ロジックの妥当性を整理。

## 5. AI視点での結果

今回のマイグレーション対応により、ユーザーは特別な操作をすることなく TelosDB v0.3.0 へアップデート可能になりました。内部的にはテーブルのリネーム、データの再挿入、外部キー制約の一時解除など複雑な処理を行っていますが、これらをカプセル化することで、プロダクトとしての堅牢性とユーザー体験の両立を実現しました。
以前のベクトル ID をそのまま引き継ぐ設計としたため、再インデックスの手間も最小限に抑えられています。
