MAGICでXQuery (1)

MAGICでXQueryを使うメリット

　MAGICのソースにアクセスするという観点でみると、何よりソースがXMLファイルであるという大前提があるが故に、その一手段としてのXQueryの有用性が自ずと伺われる。しかし割と古く（といっても十数年前かな？）からある技術でありながら、馴染みのない技術者も多いのではないか？「今更XML？」という雰囲気もなんとなくあるし、知ってても少しとっつきにくいところもあるかもしれない。
　筆者はMAGIC xpaの前身であるMAGIC eDeveloper V10の時代、当サイトのブログ（すでに閉鎖）でXMLDB技術を利用した事例を紹介したことがあった。その頃は、IBMのオープン系RDBMSであるDB2のゲートウェイがまだ存在していて、DB2にソースを格納するツールを作成したりしていた。その後、uniPaaSに変わるとDB2のゲートウェイは無くなってしまう。それを境に、DB2を使う機会もすっかりなくなってしまったが、リレーショナルとXMLのハイブリッド利用が可能なDBMSに魅力を感じたのを覚えている。その後、OracleやSQL ServerでもXMLやXQueryがサポートされたことは知ったが、触れることなく十数年の歳月が流れてしまった。
　まぁ、経緯はこんなところなんだけど、開発中のソース管理ツール「SMSYS」の使い勝手を上げる上で「XQueryを使ったらできるかな？」みたいなアイデアがあったので、目下実験してみているところ。
　今回の連載記事ではMicrosoft SQL ServerのXQueryの実際のコーディング方法を紹介するとともに、その有用性やらパフォーマンスを検証してみようと考えている。

何故XQueryなのか…

　さて、MAGICでXQueryを使うメリットは何だろうか？MAGICにもXMLGetやXMLInsert、XMLModifyのようにXMLを参照したり書き換えたりする関数があるではないか？

　先ず第一に「MAGICのXML関連の組み込み関数では使えないXPATH式が使える」ことが挙げられる。
　例えば、MAGICのプログラムはタスクが再帰的に出現する構造を持っているが、MAGICの関数の場合は「何番目のタスクの子の何番目のタスク」というように、その階層の要素の位置(いわゆるposition)を直接指定しなければならない。その例が次のようなXPATHである。

　本来、XPATH式では一足飛びの指定が可能である。
　下の例では、「/Application/ProgramsRepository/Programs」の要素（＝プログラムの基点）の下位のすべての「Task」という名前の要素（＝ネストされている全タスクの基点）を指定したことになる。

　しかし、こういう指定は残念ながらMAGICでは使えないのである。
　この元々持っているXPATH式の威力は強力で、他にも属性を特定したり、テキストノードを指定したり、特定の文字を含むノードの指定が可能である。

　次に重要なのが「FLWOR（フラワー）式を使用した抽出機能が使用できる」ことである。
　FLWOR とは、for、let、where、order by、および return の頭文字で、これはSQLのSELECT文とFETCH文を組み合わせたような機能を提供する（通常良く使われるのは for、where、returnで、let、where、order byは省略も可能）。
　下記の例はとプログラムのルートタスクで代入式のある項目の一覧を取得する例である。

　プログラムリポジトリのデータビューやロジックの各行はいわゆるロジックライン（Task/TaskLogic/LogicUnit/LogicLines/LogicLine）として記述されるが、これらを変数「$e」に格納。
　そのループ（for文）毎に代入式の属性「$e/select/ASS/@val」が存在している要素を絞り込み（where文)、
　ロジックユニットのID、行識別ID、式IDをそれぞれ「Data」要素の属性として出力している。（return文）

　下記は、その出力結果の例である。