DB構造
実は一番の大物はこれかも
ぶりの中核のテーブルはこの4つ
- buriPath
- buriData
- buriState
- buriBranch
これの構成が判ればぶりの仕組みは判るはず。
他にも二つあるけど、権限を使わない限り必要ないので放置
- buriUser
- buriStateUser
buriData
ぶりの外のデータをぶりが把握するIDを付与するためのテーブル
テーブル名とか主キーとか実際のクラス名が入ってるだけ
ここからEntityを再現できるのも重要なポイント
buriPath
XPDLの情報を収集して必要なモノだけ突っ込むもの。
PathNameは判りやすいやつ、RealPathNameはIDから作ったもの
RealPathNameはそのままXPDLをコンパイルしたときのクラス名とかメソッド名になってるのが重要なポイント。
この定義があるからXPDLのIDは重複すると駄目だし、変更するとちょっと面倒になる。
まぁやっちゃったときはDB書き換えれば良いんだけどね〜
buriState
状態情報そのもの。
これを理解してしまえばとりあえずぶりはSQLから使えるはず。
insertDateがあって、processDateが今より小さい値だと処理されたって扱いになる。
abortDateがあると、そのデータは処理されなかった(toNextStatusされなかった)って意味。
有効な状態が全部取ってこれる
buriBranch
これがぶりの中で謎って思う人が多いテーブル（ｗ
Viewでもjoinされてないのに何故かしっかり値が入るからね〜
簡単に説明するとAND分岐とJOIN処理を管理するためのモノ。
ぶりは一本線の所を一つのburiBranchで管理。AND分岐があると新たに分岐した数のburiBranchのレコードを作る。そのときにparentBranchIdを入れることで分岐した/しないとかを管理。
AND-JOINをするときはparentBranchIdが一致してるburiBranchに紐尽くburiStateの有無をチェックして全てが無ければ次の状態に進む。1件でもあればそこで待機する
XOR-JOInをするときはparentBranchIdが一致しているburiBranchに紐尽くburiStateをabortする
って事で状態を検索する時には一切要らない。
ぶりのテーブル構造はシンプルで良いね〜〜
