Catyリリース4の確認は、チュートリアル書きながらやっています。僕は文章書くの苦手だとは思ってないけど、チュートリアルは難しいなー。なるべく早めにリリースすべく作業しますけどね(腰がイテー)。
そういうことなので、リリース4は2,3日か4,5日か先です。なーのに、その次のリーリス5だの6だのの話をするのもナンですが、「これはちょっといいぞー」な機能が予定されているので、先走って言っておきたい。言いたくて仕方ない。
データの保存場所として、ファイルシステム(mafs)だけではさすがに辛いので、データベースは欲しいのですが、Catyの目的、すなわち「ラーメン屋さんのサイトをまっとうに迅速に作る」に対して、通常のRDBはオーバースペックです。機能が豊富な方がそりゃいいに決まってますが、概念を理解して機能を使いこなすための学習コストが問題なんです。
やれ正規化だインデックスだジョインだとか、ンナコターやりたくないのですよ。Catyは、あらゆる所でJSONデータを使っているので、JSONオブジェクトを保存できて取り出せればいいのです。が、SQLのSELECT文相当の機能は欲しい。もちろん、できるだけ分かりやすい形で。
Catyスクリプトからデータベースを操作するなら、コマンドを使うことになります。コマンドラインのオプションやら引数で、複雑な問い合わせを表現するのはチト無理があるなー、とか思っていたら、Kuwataさんが、JSONインスタンスを使って問い合わせを表現するというアイディアを持ち出したのです。これはとてもナイスな方法です。JSON-centricなCatyにはうってつけ。しかも分かりやすい。
JSONは、シーケンス構造とキーバリュー構造を持つので、相当に複雑なデータを表現できます。この表現力を活かして、問い合わせをJSONにエンコードするわけ。普通のJSON構文だと、可読性を保ったエンコードは無理でしょうけど、Catyはシンタックスシュガーとしてタギング拡張をしているのです。このタギング構文を利用すると、かなり自然に問い合わせが書けます。
例えば、「女性で、19901980年代生まれ、東京都在住」という条件は次のように書けるでしょう。
{
"gender" : "female",
"birth" : {
"year" : @_AND [@_GTEQ 1980, @_LT 1990]
},
"addr" : {
"area" : @_CONTAINS "東京都"
}
}
これを論理式(と等価なラムダ式)に書き換えるため、次の書き換え規則を考えます。
- @_AND → ∧
- @_GTEQ → ≧
- @_LT → <
- @_CONTAINS → contains関数
すると:
- λx.[x.gender = "famle" ∧ (x.birth.year≧1980 ∧ x.birth.year<1990) ∧ contains(x.addr.area, "東京都")]
という述語ラムダ式になります。
この例に限らず、JSONインスタンスで書いた問い合わせは古典論理の論理式に翻訳できます。逆に、“基本述語を原子論理式として組み立てられた古典命題論理”の論理式(集合ブール代数の元)は、JSONインスタンスで表現可能です。ということは、他のいかなる問い合わせ言語と比べてもなんら遜色がないのです。
問い合わせコマンドの全体は次のようになるでしょう。
{
"gender" : "female",
"birth" : {
"year" : @_AND [@_GTEQ 1980, @_LT 1990]
},
"addr" : {
"area" : @_CONTAINS "東京都"
}
} | strg:select --from=our.Customer --order-by=cust_no
問い合わせは単なるJSONオブジェクトであり、それはCatyスクリプトでもあるので、別ファイル query1.caty とかに入れておけば次のようにも書けます。
query1.caty | strg:select --from=our.Customer --order-by=cust_no
問い合わせ結果はリスト(JSON配列)なので、Catyスクリプトのeach構文とリスト処理コマンド群で好きなように加工してから、printコマンド(テンプレートサブシステム)に流し込めます。
上記のようなコマンドラインが書けるには、それなりの学習・トレーニングが必要なことは認めますが、SQLと汎用プログラミング言語を学ぶ負担に比べたら、どう考えたってはるかに楽ですぜ。
技術者にとって「学習・トレーニングは重要だ」と強調している僕が、学習・トレーニングの軽減にどうしてそんなに拘るかというと、その人にとって必要な学習・トレーニングをする時間とエネルギーを捻出するには、無駄で無意味な学習・トレーニングを排除すべきだと思うからです。そして、SQLと汎用プログラミング言語なんて無駄で無意味な状況は多々あるのです。
というわけで、リリース5か6に、JSONストレージとJSON問い合わせが入ります。
[追記]
Kuwataさんが、RDBバックエンドに対するJSONストレージの実装方式について書いています。
[/追記]