AsakusaFW 0.10.4 https化

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が範囲外だったときに、どういう値だったのかを例外メッセージに加えました。これが分からないと、地味に不便だったので＾＾；

SQL to AsakusaFW：having

Asakusa Framework Advent Calendar 2019の18日目、SQLをAsakusaFWに変換するポイントについてです。

SELECT文の集約のHAVING句は、対象が集約結果であるというだけで、WHERE条件と同様です。

ちなみに標準SQLでは、SELECT句で集約結果にカラム名を付けてHAVINGでそのカラム名を使うことって出来ないらしいですね。（他の人が書いたSQL文を見て、なんでカラム名を付けて統一しないのかなーと思ってたんですけどね＾＾；）

SQL to AsakusaFW：group by

Asakusa Framework Advent Calendar 2019の17日目、SQLをAsakusaFWに変換するポイントについてです。

SELECT文のGROUP BYのカラムは、集約をSummarize演算子で行う場合は集約キー、Fold演算子で行う場合は@Keyに指定すればいいです。

SQLのNULL同士の比較はUNKNOWNでFALSE扱いとなりますが、確か、（例外的に）GROUP BYではNULL同士は等しいものとして扱われるはずです。これはAsakusaFWの挙動と同じです。

SQL to AsakusaFW：集約

Asakusa Framework Advent Calendar 2019の16日目、SQLをAsakusaFWに変換するポイントについてです。

SELECT文は集約（SUMやCOUNT等）することが出来ます。
これは、AsakusaFWではSummarize演算子が該当します。
しかし、ここでもNULLの挙動は異なります。SQLのCOUNT(値)では、値がNULLだとカウントの対象外、SUM(値)では値がNULLだと合算の対象外です。が、Summarize演算子ではcountはnullでも関係なくカウントされ、sumはnullだとNullPointerExceptionが発生します。

このため、Summarize演算子を使わず、Fold演算子でnullチェックを行いつつカウント・集計を行う必要があります。
もしくは、NULLを0扱いしてよいのであれば、事前にUpdate演算子でnullを0に更新しておき、Summarize演算子に渡すということも出来ます。

SQL to AsakusaFW：join（null同士の結合）

Asakusa Framework Advent Calendar 2019の15日目、SQLをAsakusaFWに変換するポイントについてです。

SELECT文のFROM句におけるテーブル結合を実現する方法としてCoGroup・MasterJoinUpdate・Extract（+GroupView）演算子を使う方法を紹介してきました。
これらの方法に共通するSQLの問題点として、（WHERE条件の話でも出した）NULL同士の結合があります。
SQLではNULL同士の結合（「=」による演算）はUNKNOWNなのでFALSE扱い、すなわち結合しないのですが、AsakusaFWではnull==nullはtrueなので結合することになります。

大抵の結合ではマスターテーブルのプライマリキーに対して結合することになる（と思いたい）ので、プライマリキーならNOT NULLなのでこの問題を考える必要は無いのですが。

これを厳密に対処するなら、
CoGroup演算子の場合：渡ってきたデータの結合キー項目がnullかどうかチェックする
MasterJoinUpdate演算子の場合：MasterSelectionで結合キー項目がnullかどうかチェックする
GroupViewの場合：結合キー項目がnullだったらGroupViewから取得しない
のような処理を入れる必要があるでしょう。

---

個人的には、AsakusaFWの結合方法のオプションとして「null同士だったら一致しないものとして扱うモード」があると上記の問題の対処が楽になるなーと思うのですが、
しかしSQLに似せる為だけにそういうオプションを入れるのは微妙だとも思います＾＾；