Asakusa Framework Advent Calendar 2019の22日目、SQLをAsakusaFWに変換するポイントについてです。
SQLで結構やっかいなのが、サブクエリーです。SELECT句やらWHERE句やら、値を書ける場所ならどこにでも書けるSELECT文です。
スカラサブクエリーなら取得できるのは1件だけなのでまだましですが。
サブクエリーをWHERE条件で結合している場合、AsakusaFWではそれが結合キーになります。
サブクエリーのデータの量が少ないならGroupViewを使うのが一番簡単です。GroupViewならConvert演算子やBranch演算子でも使えるので。
そうでなければ、ConvertやBranchの前にCoGroup演算子等でサブクエリーの値を取得・結合する形になるでしょう。
複数のサブクエリーがある場合、結合キーが1種類で済むならCoGroupひとつでいけますが、そうでないなら、サブクエリーの数だけCoGroupが必要となり、あまり好ましい感じはしないのですが、仕方ないですね＾＾；
Asakusa Framework Advent Calendar 2019の21日目、SQLをAsakusaFWに変換するポイントについてです。
SELECT文のLIMITは（標準SQLなのかどうか知りませんが）、出力するレコード件数を絞るものです。
ORDER BYでソートした後に件数を絞るとすれば、AsakusaFWではGroupSort演算子が相応しいです。
OracleにはLIMITは無く、WHERE条件でROWNUM擬似列を使うのが常套手段だと思いますが、AsakusaFW化する際はLIMITと同様の扱いにする方が楽でしょう。
なお、LIMITではキー毎の件数制限は出来ないと思いますが、GroupSort演算子ではそれも簡単です。
Asakusa Framework Advent Calendar 2019の20日目、SQLをAsakusaFWに変換するポイントについてです。
SELECT文のORDER BYは、出力結果をソートするものです。
AsakusaFWで結果をDirect I/Oでファイルに出力する場合は、ExporterのgetOrderメソッドでソートするカラムを指定します。
AsakusaFWのOperatorの各メソッドの場合は、出力データに対してソートするわけではありません。ここはSQLとは異なります。
CoGroup演算子とGroupSort演算子では、入力データに対してソートすることが出来ます。これらの演算子への入力がORDER BY付きのSELECT文の場合は、ソートカラムをCoGroup/GroupSortの入力データの@Keyのorderに指定します。
それ以外の演算子ではソートすることは出来ません。基本的に分散して処理する演算子ばかりなので、そもそもソート順を指定することは出来ないんですね。
Asakusa Framework Advent Calendar 2019の19日目です。
（SQLからAsakusaFWへの変換について書いている最中にAsakusaFW 0.10.4がリリースされました。開発陣、アドベントカレンダーのことなんか気にしてくれない＾＾；）
2019/12/18にAsakusa Framework0.10.4がリリースされました。→リリースノート
一番の目玉は、内部で使っているMavenリポジトリーのURLがhttpからhttpsに変わったことです。
2020/1/15にMavenのCentral RepositoryのURLのhttpが解決されなくなる（httpsに変えなければならない？）そうです。（たぶんそれに合わせて、Gradleもhttpsに変わるようです）
AsakusaFWは今までhttpだったので、httpsに変えたようです。
0.10.4より前の古いバージョンはhttpのままなので、もしかすると2020/1/15以降にGradleを使おうとすると、エラーになるかもしれません。（一応回避策はあるみたいなので、そのときが来たら試してみますが）
もうひとつがAsakusaアプリケーションをコンパイルするときのオプションmaxHeapSizeのバグ修正です。
もっとも、演算子（Operator）が大量に使われているようなフローでもない限り、このオプションを使う事は無いと思いますが＾＾；
あ、あとこっそりPullRequestしたHeapListBuilderの修正が取り込まれた模様ｗ
CoGroupとかの引数で使っているListにアクセスした際のindexが範囲外だったときに、どういう値だったのかを例外メッセージに加えました。これが分からないと、地味に不便だったので＾＾；
Asakusa Framework Advent Calendar 2019の18日目、SQLをAsakusaFWに変換するポイントについてです。
SELECT文の集約のHAVING句は、対象が集約結果であるというだけで、WHERE条件と同様です。
ちなみに標準SQLでは、SELECT句で集約結果にカラム名を付けてHAVINGでそのカラム名を使うことって出来ないらしいですね。（他の人が書いたSQL文を見て、なんでカラム名を付けて統一しないのかなーと思ってたんですけどね＾＾；）
