#仕事で使う必要があってGauche-dbd-mysqlを直して使えるようにしました。
#壊れてた(5.1や5.6でSEGVくらってた)ので。いつから壊れてたのかはちょっとわからない。と言うより、初期化の仕方を以前から間違ってた疑惑。
#それはさておき
#ついでなんで、Gaucheのinfoの「DBI用のドライバを書く」の項を読んでみたんですが
#• ドライバにあったクエリ結果を表現するための‘<relation>’および
‘<collection>’のサブクラス。(ほとんどの場合、SELECT文の結果は順序 が
重要です。それは、ORDER BY 節によってソートされる可能性があるからで
す。したがって、‘<sequence>’を継承するほうが、‘<collection>’ を継承
するよりも適切です。)#とあるんですが、RDBMSの結果セットの性質を考えると、<collection>や<sequence>より、ジェネレータであった方がいい(いいと言うか安全)なのではないか、と思いました。
#今さら変えるのは難しいですかねぇ...
#あと、list->generatorとかvector->generatorとかstring->generatorよりもうちょっと汎用的な、イテレータをジェネレータに変換する関数があると嬉しいなと思いました。簡単に実装できるんですけど、標準であると便利かな、と。
#確かに、結果を1行づつ取ってくる形式にはジェネレータの方がふさわしいですね。ただ、他のdbdでどういう形になるかわからんし… いっそlazy sequenceで統一するのはどうだろう。
#あと、変換関数は x->generator じゃだめっすか。
#あ、x->generator見落としてた... 失礼しました。
#lazy sequenceでもいいか...
#実は、現状のGauche-dbd-mysqlは、call-with-iteratorがgenerator的な挙動をするので、同じ<mysql-result-set>を2回mapすると、2回目は空になるというひどい代物です
#あ、と思ったらseekしてる...
#すごい無理矢理や...
#む、でも<collection>を継承してresult-setを作るって形式だと、lazy sequenceは継承できないから (クラスとしては<list>にすぎない) やっぱり困るか。
#そうですね。
#むしろクエリの結果はlseqで統一、の方がやりやすいのかな。
#lseqってクラスなんでしたっけ?
#あ、違うわ。普通に<collection>や<sequence>と同じ関数に渡せるというところが重要なのか
#lseqは普通のリストと原則として見分けつかないです。要素がlazyに現実化されるってだけで。
#例えば、多段のmapをlseqに適用して、一種のパイプライン的に処理を行いたい場合は、mapじゃなくてgauche.lazyのlmapを使えばいい、という感じですか?
#ああ、result-setにはrelationとして列情報を持たせようって含みもあったんだっけ。だとすると単なるlseqじゃまずいな。
#あう
#mapとlmap (に限らず、* vs l* 一般) の違いは、返されるシーケンスがlazyかどうか、で、入力はどちらでも構いません。中間リストが生成されるのを気にしなければmapでつなげばいいし、全部lazyにやりたければlmapをつなげば良いです。
#たぶん巨大な結果セットに対しては中間リストは作りたくないので。「パイプライン的に」というのはそういう意味でした(UNIXのパイプラインのイメージ)。
#dbdの実装APIとして、カラムへのアクセス方法を返すものと、行の集合をlseqとかcollectionなどで返すものを用意すれば、dbiレベルでresult-setにまとめてくれる、っていうふうになってればいいかな。
Gauche > Archives > 2014/06/26