このファイルには、後から見返す価値のある設計判断だけを残す。
全体の入口は overview.md、
具体的な実装段取りは plans/ を参照する。
ステータス: 採用
決定: Rust で実装する。
理由:
- 所有権と型システムにより、低レイヤ実装でも安全性を保ちやすい
- パフォーマンスコストを抑えつつ、学習対象としても価値が高い
thiserror、tokio、parking_lotなど周辺エコシステムを使いやすい
ステータス: 採用
決定: 責務ごとに crate を分ける。
構成:
storagesqlquerycatalogtypes
理由:
- parser、planner、storage の境界を明確に保ちたい
- 学習中の責務分離をコード構造で強制できる
- テストや依存関係を crate 単位で整理しやすい
ステータス: 採用
決定:
最初は文字列を直接読み進める hand-written parser を採用し、
必要になれば後で sqlparser-rs を adapter 的に導入できる形を目指す。
理由:
SQL -> ASTの流れを自分で理解しやすい- 学習段階では最小構文に絞って段階実装しやすい
- AST 主導の設計を維持すれば、将来の parser 差し替え余地を残せる
ステータス: 採用
決定:
最初の到達目標は単一文の CREATE TABLE / INSERT / SELECT / UPDATE / DELETE とし、
その後の次段階で最小トランザクション制御を追加する。
最適化や高度な同時実行制御はさらに後続フェーズへ送る。
理由:
- 学習の主眼は parser から executor までの基本経路を通すことにある
- 一度に対象を広げると、SQL 構文、実行、永続化、同時実行制御が同時に複雑化する
- CRUD が一通り揃うと、後続の query / storage との接続点が見えやすい
ステータス: 採用
決定: 最初のトランザクション制御は次の範囲に絞る。
- SQL は
BEGIN / COMMIT / ROLLBACKを優先する - 実行モデルはオートコミット + 明示トランザクションとする
- 同時実行は単一接続、単一ライタから始める
- 永続化は rollback journal で atomic commit / rollback を支え、 WAL、checkpoint、MVCC、分離レベルは後続へ送る
理由:
- PostgreSQL の公式文書でも、トランザクションの基本操作は
BEGIN / COMMIT / ROLLBACKを軸に説明されている - SQLite の公式文書でも、暗黙トランザクションと明示トランザクション、 そして rollback journal を使った atomic commit が基本として整理されている
- rollback journal は、最初に必要な Atomicity / Durability の学習対象を WAL より小さい設計で切り出しやすい
- 単一接続から始めれば、Isolation を直列実行で単純化でき、 recovery と実行経路の理解に集中しやすい
ステータス: 採用
決定:
現在の最小 SELECT を第一段階の到達点とし、
JOIN 派生構文、派生表の拡張、LIMIT / OFFSET などは
plans/05-select-extensions.md に切り出す。
理由:
- 実装済み範囲と将来計画を同じ文書に混ぜると、次に何をやるかが曖昧になる
INSERT / UPDATE / DELETE / CREATE TABLEを先に進めたほうが CRUD 全体の形が早く見える- 学習用として「今の到達点」と「次の拡張」を分離したほうが追いやすい