From: Kouhei Sutou Date: 2009-05-16T21:14:51+09:00 Subject: [ruby-dev:38476] Re: SQLiteライブラリ 須藤です。 In <4A0E3D1C.3080805@airemix.jp> "[ruby-dev:38471] Re: SQLiteライブラリ" on Sat, 16 May 2009 13:12:33 +0900, "NARUSE, Yui" wrote: >> また、SQLite3のエラーはArgumentErrorかRuntimeErrorで返されま >> すが、SQLite::BusyやSQLite::ReadOnlyなど専用の例外クラスを返 >> して欲しいです。busyのときは少し待ってからもう一度試してみる、 >> というような処理を書くことがあると思いますが、そのときにエラー >> メッセージを正規表現でマッチさせてbusyなエラーかどうかを判断 >> するということはしたくありません。 > > これもそういう意見はあるだろうなぁと思いつつとりあえず外しておいたところです。 > このライブラリにおいて例外を区別して分けたいのはSQLITE_BUSYな時に > ちょっと待ってからリトライだと思うのですが、 > それはすでにこのライブラリ側で行っています。 タイムアウトの時間は1秒に固定されていますよね。 場合によってはもっと長くしたり短くしたりしたいと思います。 アプリケーション側で制御できるべき項目だと思います。 > さらにもうしばらく待ってからリトライが欲しいとか、 > 別のケースを捕獲して何かしたい例があるのならば例外を分けますが、 > そのようなケースってありますか？ GUIアプリケーションの場合はsleepするのではなく、メインループ を回したいです。GTK+などのGUIツールキットはシングルスレッド で動くので、別スレッドでやってくれ、という回避策はやめてほし いです。 やはり、busyなときにどうやって待つかもアプリケーション側で制 御できるべき項目だと思います。もちろん、制御できるのであれば デフォルトはsleepという風になっていてもよいと思います。 >>> * それなりにやる気のあるメンテナ >>> という利点があります。 >> >> いきなりRubyに標準添付するのではなくて、まず、独立ライブラリ >> として使ってもらって使いにくいところなどのフィードバックをも >> らった後で標準添付を検討するというのでは遅いでしょうか？ > > まずはgemでやったらという指摘があることは理解しています。 > しかし、既に実績のあるSQLite3/Rubyがgemである中、 > gemでわざわざ入れて試してくれるかについてわたしは悲観的に見ています。 > つまり、独立ライブラリとすると、使ってもらえないのではないかと。 開発が終了したSQLite3/Rubyの代替を目指しているのかと思ってい たのですが、それとは違う方向でしょうか？ もし、代替を目指しているのであれば、SQLite3/Rubyの代わりに使っ てもよいと思えるものでなければいけないと思います。 > > とりあえず、単体テストの中でpとかppを使っている状態では標準 > > 添付になって欲しくないです。継続して改善されていくのであれば、 > > ある程度継続して改善された後に標準添付になって欲しいです。 > > 当然単体テストとrdocが揃うまでは標準添付にはなりませんね。 > そこは当然のことだと思っています。 > というわけで、その辺はこの土日でなんとかします。 個人的な経験では、テストとドキュメントだけではなく、いくつか アプリケーションを書いて使ってみないと使いやすいAPIのライブラ リにはならないと感じています。 （アプリケーションを書いてみて、あまりの使いづらさに愕然とす ることもありますが。）