移行 1.0.4K to 1.0.5A
お約束の注意点
- 古いバージョンの削除
- 古いバージョンのDBFluteランタイム(JAR)が[WEB-INF/lib]の下などに残らないように
- タスクを実行し忘れないように
- generateタスクだけでなく、(外だしSQLがある場合は)Sql2Entityタスクも実行
環境上の注意点
外だしSQLのカーソルで、CustomizeEntityも生成されるように
外だしSQLでタイプセーフカーソル +cursor+ を自動生成オプションを付けたとき、自動生成されるクラスの挙動が以下のようになります。
- いままで
- タイプセーフカーソルだけ自動生成
- これから
- タイプセーフカーソルに加えて普通のCustomizeEntityも生成
カーソル検索とページング検索と一つの外だしSQLで利用できるようになります。 要らないときもありますが、そのときは単に使わなければOKです。
地味にですが、普通の検索からカーソル検索に移行したときの、古いCustomizeEntityがDBFluteアップグレード時にコンパイルエラーになる問題が発生しなくなります。
実装上の注意点
Insert で ModifiedProperties
一件登録の insert() メソッドで、insert文に列挙されるカラムのルールが変わります。
- いままで
- Entityに値が存在するカラムだけ列挙
これからは、以下のようになります。
- 自分でnewしたEntity
- EntityのSetterが呼ばれたカラムだけ列挙 ※通常はこちら
- 事前検索されたEntity
- 全てのカラムを列挙 ※copy insertするような場合 (レアケース)
update() のルールと同じく ModifiedProperties が利用されます。統一的な仕様を重視しました。 ただ、copy insert のケースが更新時にはない特別なケースのため、事前検索されたEntityのときだけは全カラム列挙です。
DB変更でデフォルト制約付きのNotNullカラムが新規追加された場合でも、どちらのケースでも修正無しで対応できます。 Setterで呼ばれてないカラムは、デフォルト制約が有効です。 (事前検索されている場合は、そもそも別レコードのそのカラムの値で登録される)
互換性は？
以前のバージョンとの互換性で気にするポイントは、Entityにnullを明示的にセットしたカラムに対して、デフォルト制約が利かなくなっていることです。 (かなりレアケースではあると考えています)
こちらの挙動を元に戻すには、以下のプロパティを littleAdjustmentMap.dfprop に以下を定義します。
e.g. insert()の挙動を今まで通りにする @littleAdjustmentMap.dfprop
; isCompatibleInsertColumnNotNullOnly = true
BatchInsert で ModifiedProperties
バッチ登録の batchInsert() メソッドで、insert文に列挙されるカラムのルールが変わります。
- いままで
- 全てのカラム (デフォルト制約を全く利用できなかった)
これからは、以下のようになります。
- 自分でnewしたEntity
- EntityのSetterが呼ばれたカラムの最小公倍数を列挙 ※通常はこちら
- 事前検索されたEntity
- 全てのカラムを列挙 ※copy insertするような場合 (レアケース)
update() のルールと同じく ModifiedProperties が利用されます。統一的な仕様を重視しました。 ただ、一件登録と同様に、copy insert のケースが更新時にはない特別なケースのため、事前検索されたEntityのときだけは全カラム列挙です。
また、DB変更でデフォルト制約付きのNotNullカラムが新規追加された場合に、修正無しで対応できるようになりました。 (全てのEntity)Setterで呼ばれてないカラムは、デフォルト制約が有効です。 (事前検索されている場合は、そもそも別レコードのそのカラムの値で登録される)
互換性は？
以前のバージョンとの互換性で気にするポイントは、通常利用ではないと考えます。 NotNullでないカラムのデフォルト制約が利かずにnullが登録されていたのが、デフォルト制約が利くようになったということはあり得ますが、 その状況はかなりレアケースと言えるでしょう。
とはいえ、こちらの挙動を元に戻すには、以下のプロパティを littleAdjustmentMap.dfprop に以下を定義します。
e.g. batchInsert()の挙動を今まで通りにする @littleAdjustmentMap.dfprop
; isCompatibleBatchInsertDefaultEveryColumn = true
BatchUpdate で ModifiedProperties
バッチ登録の batchUpdate() メソッドで、update文に列挙されるカラムのルールが変わります。
- いままで
- 全てのカラム (パフォーマンス劣化の温床)
- これから
- EntityのSetterが呼ばれたカラムを列挙 (全てのEntityで一致の必要あり)
update() のルールと同じく ModifiedProperties が利用されます。統一的な仕様を重視しました。 また、無駄な更新カラムが減るため、パフォーマンス向上が見込まれます。
ただし、リスト内の全てのEntityでSetter呼び出しのセットが一致していることが前提です。一致していない場合は例外が発生します。 これは、不意の null 更新を防ぐためです。nullで更新したいなら、明示的にnullをセットします。
一部 Entity の、とあるカラムの既存の値をキープしたいという場合は、そもそも事前検索が必要となりますが、そのためだけに事前検索をするくらいなら、バッチ更新は利用しない方が良いでしょう。 (そもそもパフォーマンス考慮のために存在するメソッドであるため、事前検索を避ける方が良いかと)
ちなみに、第二引数のSpecifyQueryを使った BatchUpdate の場合に変更はありません。SpecifyQueryを使って明示的にカラムを指定したら、ModifiedPropertiesは関係なくなります。
互換性は？
以前のバージョンとの互換性で気にするポイントは、Entity間でのSetter呼び出しのセットが一致していないケースです。 その状況はかなりレアケースと言えると考えていますが、とはいえ、こちらの挙動を元に戻すには、以下のプロパティを littleAdjustmentMap.dfprop に以下を定義します。
e.g. batchUpdate()の挙動を今まで通りにする @littleAdjustmentMap.dfprop
; isCompatibleBatchUpdateDefaultEveryColumn = true
また、以前と同じ挙動でなくても、Entity間でのSetter呼び出しのセットがバラバラであること許容して、最小公倍数のカラムで更新することもできます。 もともと全カラム更新だったので、事前検索したEntityに対してセットしていることが想定され、不意のnull更新をしてしまうことはないと考えられるので、 互換性の心配があるのであれば、こちらのプロパティを設定するだけでも良いのではないと思われます。ただし、新たに new した Entity でバッチ更新する場合は、不意のnull更新に注意が必要です。
e.g. batchUpdate()の挙動を最小公倍数にする @littleAdjustmentMap.dfprop
; isBatchUpdateColumnModifiedPropertiesFragmentedAllowed = true
更新系、列挙されるカラムのまとめ
まとめていますので、ぜひご覧を。
