SchemaHTMLでの複合インデックス表現の改善
今までは、
例えば、A, B, Cという複合ユニークキーがあった場合、
A - o+
B - o+
C - o+
という風に + が付くようになっていて、
どこがトップカラムなのかわかりませんでした。
ツールチップにカラムの構成が出てはきますが直感的では
ありませんでした。
それが...
A - o+
B - +o
C - +o
という風になります。
-> SchemaHTMLのサンプルの購入テーブル
Aが基点になって、他のカラムを+している。
BやCは、他のカラムから+されている。
というようなニュアンスです。
厳密には、複合インデックスが何個もある場合、
しかも、カラムが重なって色々とある場合、
「トップでもありサブでもある」という状況もあります。
その場合は o+ となります。
「自分がトップカラムとして活躍するインデックスが一つ以上ある」
という印になります。
検索クエリーを書くときは、検索条件で利用するカラムに、
そのカラムがトップになっているインデックスが付いているか
どうかがとりあえず重要です。(厳密には色々ありますが)
ということで、トップかサブかを直感的にわかるようにしました。
ユニークキーで update() できるように
一件更新は、PKによる更新が基本でしたが、
ユニークキーでも更新できるようにしました。
update() - ユニークキーで更新 | DBFlute
これにより、PKを取得するためだけの事前検索が不要になります。
(PKを取得する利用が他にあるなら別にOKですが)
また、insertOrUpdate() でも利用できます。
プログラム上では、ビジネスキー (ユニークキー) だけ持っている場合、
今までは insertOrUpdate() が利用できず、
分岐のための事前検索をしなければなりませんでしたが、
ユニークキーで insertOrUpdate() が利用できます。
Java8に向けたポテンシャルの増強 but Java6でも使える
全開に引き続き、DBFlute-1.1 への仕様を先立って入れています。
基本的にデフォルトは OFF ですが、Java6, 7でも便利なものも
ありますので、ピンポイントで選んで利用できます。
将来的なアップグレードを見越して利用しておくとよいものもあります。
littleAdjustmentMap.dfprop で指定できます。
詳しくは、また別途ブログで紹介したいと思いますが、
取り急ぎ、ここに列挙しておきます。
コンパイルエラーが発生しなければOKなもの
試しにやってみて、コンパイルエラーが発生しなければ、
将来のためにも利用しておくとよいものたちです。
isCompatibleSelectByPKOldStyle = false
-> selectByPKValue() が selectByPK() に
isCompatibleSelectByPKWithDeletedCheck = false
-> selectByPKValueWithDeletedCheck() を生成しない
isMakeConditionQueryExistsReferrerToOne = false
-> one-to-oneへのExistsReferrerを生成しない
isMakeConditionQueryInScopeRelationToOne = false
-> one-to-oneへのInScopeRelationを生成しない
isMakeConditionQueryPlainListManualOrder = false
-> ManualOrderのList引数のメソッドを生成しない
開発初めであれば、やっておいた方がいいもの
isCompatibleOrScopeQueryPurposeNoCheck = false
-> OrScopeQueryの中でsetupSelectやorderByを例外に
isThatsBadTimingDetect = true
-> SubQueryの中で外側のCBを利用できないように
-> Java8のラムダの心配なところ...
そもそも Java8 で動かす人は...
isCompatibleBeforeJava8 = false
とやれば、これら全てが有効になります。
加えて、selectEntity() の戻りが Optional に、
関連テーブルの Entity が Optional になります。
ぜひとも、検討してみてください。
