Sutou Kouhei
Sutou Kouhei
参考URL にもあるとおり、各レコードバッチの前に追加のdictionaryのエントリーを送ることができるのですが、Apache ArrowのC++実装ではまだこれに対応していなかったはずなので、最初にdictionaryを完成させてから送受信できたほうが現状ではよりポータブルになりそうです。
参照型だけdictionaryを使うようにするのがよさそうには思っています。参照型だと別途dictionaryを構築する必要がないからです。（値を全部なめて重複なしのキーと値のリストを用意する必要がない。参照先のテーブルの`_id`と`_key`がdictionary相当の情報になる。） ただ、参照先のテーブルの`_key`をすべて送るのは無駄（レコードバッチで使われていない`_key`があるかもしれない）なので、そこはがんばらないといけない。
参照先のテーブルごとに別のdictionaryを作るので大丈夫なはずです！
Dictionaryにすると発生する問題って互換性だけでしたっけ？ `command_version=3`はexperimental扱いなので、 #1217 と同じバージョンでえいやっとやってしまっていい気がします。 Dictionaryにすると参照先のレコードのIDも一緒に返せると思うので文字列型だけではなくすべての型でDictionaryを使ったほうがいい気がします。
あぁ、そうなるんでしたっけ。では、レコードIDも一緒に返すのは諦めますか。。。
Generally, we don't need to close types such as `ShortText`. Because it doesn't allocate large memory nor open files.
`match_positions(column)`で ``` json [ { "offset": 3, "length": 2 }, { "offset": 7, "length": 3 } ] ``` みたいな感じですかねぇ。 単位がバイトか文字かわかりにくい気がするので`match_positions_byte(column)`の方がいいかも。
`position`と`location`はどっちがいいのかしら。
> 「ポジション」の配列を返します。各「ポジション」には「ポジション」情報と「長さ」情報が含まれます。 という説明になると混乱しそうなので`position`じゃない方がいいんじゃないですかねぇ。