makotan _at_ gmail dot com

DataAccess

buri

DataAccessってDaoとか探して・・・って思ったら大間違いの巻
ちょっとこれからの説明が面倒なので仕様レベルのおさらい
ぶりはエンジンにn個のパッケージにm個のプロセスっていうツリー構造を内部的に保持していて、toNextStatusはそれぞれを指定するためのモノ
で、XPDLのパッケージのデータ定義かプロセスのデータ定義にクラス名とそれのアクセス方法を書けばその通りにアクセスするよ
XPDLのパッケージのデータ定義とプロセスのデータ定義のどっちを優先させるのかという問題があって、プロセスが優先、プロセスに定義がなければパッケージを見に行く。
って言うのが本来の基本スペック＜ここ重要
で、XPDLの定義に書いたデータアクセスのルールはBuriDataFieldCompilePreprocessorImplでチェックしたあとコンパイルされてネイティブに動作するわけです（深い意味はないんだけど）


DataAccessっていうのはパッケージを見て、プロセスを見て・・・を実現してるDataAccessFactoryと実際のデータアクセスを担当するUtilが基本的な構造
DataAccessFactoryは自分の所に定義が無くてでも、子供があれば子供に処理を依頼する。
ということで、DataAccessするためにパッケージとプロセスの関係の逆方向に辿るわけですね
ちなみに、最後にたどり着くのはextensionDAFとScriptDataAccessFactory
extensionDAFを置き換えてしまえば他の所を拡張せずに独自のルールを使ったりも出来るよと。渡すデータはHibernateでもなんでもご自由にどうぞ〜みたいな（笑）


ここまでが開発当初のぶりの姿。
このぶりをプレゼン担当コミッタがめんどくさいからワンパターンな定義しなくて良いように出来ない？とか言うもんだから作ったのが、ScriptDataAccessUtilLongKeyImplとそれに伴う各種ルールを処理するためのコンポーネント群
その中にはじめからS2Daoの定義を自動的に探して勝手に使うのがあったと。
まぁデータアクセス関係の処理ルールがコンパイラの所にあるのは元々の経緯がこういう感じだから(^^;
それから何年も経ってソースコードからこの機能が発掘され、S2JDBC拡張やらDBFlute拡張やらが一気に進んだよ。
って事なんだけど、実は当初そんなにここが拡張対象になるとは思わなかった・・・extensionDAF置き換えた方が自由度が遙かに上だからね


これも書いとこ
ぶりがLong型だけに単一主キーを使ってIntegerとかは整数値の単一キーとして扱わないのは100%作者の趣味。
そこの書き換えも実はFactory丸ごと作ればなんとでも出来るはず。
あと、文字列の単一キーであっても複合主キー扱いになるのも作者の趣味というかこれは本人がほとんど使う気がないからそう言う実装になってるだけ（ぉぃ
Factory丸ごと作ってしまえば何とでもなるよ
ぶりの実装的にはLongか文字列以外の判断をしてるつもりはないから。