HN5729
SQLiteにもRustのような「エディション（Edition）」制を導入すべきでは？
SQLite should have (Rust-style) editions
gnyeki・約22時間前
議論
9件SQLiteにRustのような「エディション」の概念を取り入れるべきではないでしょうか。これにより、既存の動作を壊すことなく、長期的な進化と互換性の維持を両立できるはずです。
お疲れ様、著者です。ここHNで話題になっているのを見るのは面白いね。
SQLiteはデータコンテナであるという点で、Rustとは少し違うんだよね。SQLiteのデータベースファイルを別のマシンに移動させてコマンドラインツールで中身をチェックするというのは、比較的よくある使い方だし。それに、アプリに組み込まれているSQLiteのバージョンが、たまたま入っている /usr/bin/sqlite3 よりも新しいバージョンであることもよくある。SQLiteファイルにエディションを追加すると、新しいエディションで書かれたデータベースを古いバージョンで読み込もうとした時に、新しいエディションで何が変更されたのか分からないから、この運用方法は多分壊れちゃうだろうね。
まあ、大した問題じゃないけど。アプリで使っているのと同じバージョンのコマンドラインユーティリティを一緒に配布するように、運用を改善すれば済む話だし。
興味深いアイデアだね。不満点のリストを挙げるだけでなく、後方互換性を保ちつつ「代替のデフォルト設定」を用意するための現実的な提案が続いているのはいい。もしその機能を使いたくなければ、新しい PRAGMA edition = 2026 を実行しなければいいだけだからね。
ただ問題点を列挙して、他のみんなが自分に合わせて変わってくれればいいのに、と願うだけの内容が多いから。
あと、SQLITE_BUSY の擁護というわけじゃないけど、busy_timeout は SQLITE_BUSY を受け取った時に指定された時間までスリープして再試行するようにsqliteに指示するだけだ。それを呼び出し側のコードに任せるのは、ライブラリとしては賢明なデフォルト設定だと思うよ。待機している間に他の処理ができる可能性もあるからね。もっとも、そのロジックが忘れられがちなんだけど！
この件、フォーラムで提起してみる価値はあるかもね [1]。開発者たちはそこでかなり活発に活動しているし、彼らがこのオプションを検討したことがないか、あるいは検討済みで導入しない理由がある可能性もある。元の設計はポステルの法則に従っていたんだ（他の日の自分のコメント [2] を参照）。理論的には、エディションを指定することでその混乱を避けられたら素晴らしいんだけどね。
今日気付いたんだけど、pragma foreign_key = ON を実行しても、pragmaが間違っている（正しくは foreign_keys と複数形であるべき）にもかかわらず、何も警告が出なかった。実際、正しいpragmaを指定しても何も警告が出ないんだよね。だからpragmaの確認はちゃんとしないと！
最初の例で、もう一つ驚いたことがあるんだけど、エンティティを削除して、そのユニークIDが再利用されるってこと？それっていいアイデアなの？
外部キーが適切に処理されていれば、定義上は問題ないということなのかな？でも、なんだか間違っているような気がする。
"use strict" の話は面白いね。JSの不合理な挙動を直せない理由として「後方互換性！」と言われるのをよく耳にするけど、いやいや、もう既にやってのけた実績はあるし、またやることもできるはずだよね。
SQLiteはここでやたらと絶賛されているけど、いざ使い始めるとその酷さにすぐ気付くよ。デフォルトの型システムは非常に制限が多くて危険だ。
昔のPHPと静的型付け言語を比較しているようなものだよ。
日付型すらないなんてさ...
悲しいことに、ORM層が対応できていないんだ。DrizzleにはSTRICTテーブルを宣言する方法がない。2023年3月からリクエストが出ているのに（issue #202、現在は議論 #2435）、v1.0のベータ版にも入らなかった。唯一の回避策は、生成されたマイグレーションSQLに手動でSTRICTを追記することだけど、drizzle-kit push を使っている場合は全く機能しない。
https://github.com/drizzle-team/drizzle-orm/discussions/2435 (https://github.com/drizzle-team/drizzle-orm/discussions/2435)