バージョン移行{0.8.3 to 0.8.4}

環境上の注意点

Sql2Entityも一緒に

バージョンアップした際は、GenerateだけでなくSql2Entityも実行して下さい。

古いテーブルを削除

古いテーブルのクラスが残っているとコンパイルエラーになる可能性があります。 それらクラスは不要なので削除するようにして下さい。

build-xxx.propertiesに「torque.isDeleteOldTableClass = true」を定義すると、古いテーブルのクラスを削除(OS上のファイルを削除)します。設定例はこちら

幾つかのプロパティは廃止

幾つか古くなったプロパティを廃止します。これらは現在全てデフォルトがfalseのもので、公開されていなかったものもあります。 ほとんどの方は利用されていないかと思われますが、万が一ご利用されている場合はお手数ですが移行をお願いします。

不要になったクラス

残っていても害にはなりませんが、DBFluteとしては利用しなくなったクラスがありますのでお手数ですが削除願います。 (名前が変わったことによって利用されなくなったクラスも含む)

実装上の注意点

BhvがDaoを利用しない(Java版のみ)

jfluteの日記:BhvがDaoを利用しないをご覧下さい。

今回はJava版のみの話ではありますが、将来C#版も同じ挙動にする予定です。

Daoインターフェースを生成しないモード(Java版のみ)

デフォルトは今まで通りDaoインターフェースは生成されます。

概要

これは、移行できる方のみ移行して頂ければと思います。 Daoインターフェースは、Behaviorでも利用されません。つまり、アプリでDaoインターフェースを 明示的に利用していない限り、Daoインターフェースは全く不要なものとなります。 しかし、単に不要というだけなら良いですが、不要なDaoインターフェースが生成されることによる弊害が３つ存在します。

「A」は、jfluteの日記:S2Daoの機能を一部抑制と関連した話です。

「B」は、一番わかりやすいかと思います。Daoインターフェースを生成しなければ、 「テーブル数 * 2」個分のクラスが削減されます。

「C」が、一番効果がでかい話です。Daoインターフェースは初期化でJavassistによる エンハンス処理が必要です。単体テストでは(ほとんどの場合)一回のテストケース実行ごとに Containerを初期化するため、Daoインターフェースの初期化がかなりの負荷になります。 一テストケースの実行が速くなることで、プログラマはストレスなく単体テストを実装できますし、 全テストケースの実行が速くなることで、デグレ検知のための一括テスト実行がとてもやりやすくなります。 dbflute-mysql-exampleやdbflute-oracle-exampleでは既にこのモードを利用していますが、 格段に単体テスト実行が速くなっています(体感で明らかにわかるくらい速い)。

これらのことからも「可能であれば」Daoインターフェースを生成しないモードに移行することをお奨めします。 また、近い将来のバージョン(0.8.5の可能性あり)ではこのモードをDBFluteのデフォルトにする予定です。

今回はJava版のみの話ではありますが、将来C#版も同じ挙動にする予定です。

手順

手順は以下の通りです。

  1. ビルドプロパティ(build-xxx.properties)に「torque.isMakeDaoInterface = false」
  2. bsdao/exdaoパッケージを削除して自動生成し直し(Generate/Sql2Entity)
  3. EclipseでJavaクラス全部に「インポートの編成(Organize Imports)」を実行

「インポートの編成(Organize Imports)」がポイントです。bsdao/exdaoパッケージを無くすことに伴って、 ParameterBeanのパッケージが「bsdao/pmbean」から「bsbhv/pmbean」に変わっています。 Eclipseで選択したソースディレクトリ配下のクラスを一気に「インポートの編成」できますのでそんなに手間にはなりません。