Jdbi: 開発者ガイド：v2からv3への移行

小さなプロジェクトの移行に関する注意事項：

クラスの名前を変更しました（インポートを削除してIDEに修正させるほど簡単ではありません）：

• DBI -> Jdbi
• IDBI -> Jdbi
• DBIException -> JdbiException

Jdbiのコンストラクターは、 create()ファクトリメソッドに置き換えられました。

ResultSetMapperはRowMapperに置き換えられ、 mapメソッドには行インデックスがなくなりました。 ResultSetMapperという名前のクラスがJdbi 3に存在しますが、それは別の目的を果たします。 @Mapperは@UseRowMapperに置き換えられます。 $＃ JdbiのregisterMapper()はregisterRowMapper()に置き換えられます。

@BindInは@BindListに置き換えられ、StringTemplateは不要になりました。

デフォルトのJdbiテンプレートでは、山かっこは引用符で囲まれていません。つまり、 [ツール]-> [データベース]-> [ユーザーパターン]でパラメーターパターンを構成した後、IntelliJが構文を理解します。

QueryのデフォルトタイプはMapではなくなったため、 list()を直接呼び出すことはできません。 list()を呼び出す前に、 mapToMap()を呼び出します。

TransactionStatusはもう存在しません。

TransactionConsumer.useTransaction()はHandle $のみを使用するため、$ JdbiのuseTransaction()メソッドでこれを使用する場合は、 TransactionStatus引数を削除する必要があります。 Handle 。

TransactionCallback.inTransaction()はHandle $のみを使用するため、 JdbiのinTransaction()メソッドでこれを使用する場合は、 TransactionStatus引数を削除する必要があります。 Handle 。

CallbackFailedExceptionはもう存在しません。 HandleConsumer 、 HandleCallback 、 TransactionalConsumer 、 TransactionalCallbackなどのさまざまな機能インターフェイスは、任意の例外タイプをスローできるようになりました（ただし、不必要なチェックを避けるためにジェネリックを使用して制限されています例外処理）。

SQLオブジェクトのサポートは、デフォルトでは使用できなくなりました。 作成されたJdbiインスタンスごとに登録する必要があります。

IntelliJのMigrateRefactorは、移行を開始するのに役立ちました。

これをまとめてくれてありがとう@electrum ！ これは大きな助けになります

私のプレゼンテーションをレビューすることからのいくつかの追加のメモ：

• アーティファクトの名前がorg.jdbi：jdbi-> orgに変更されました。 jdbi：jdbi3 、：jdbi3-sqlobject、：jdbi3-guavaなど
• コアパッケージが変更されました：org.skife.jdbi.v2-> org.jdbi.v3。 これは、移行中にv2とv3がプロジェクトに共存できることを意味します
• 名前が変更されました：GetHandle-> SqlObject
• v3引数とマッパーファクトリはjava.lang.reflect.Typeを使用しますが、v2はjava.lang.Class使用します。 これは、v3がv2では処理できなかった複雑なジェネリック型シグネチャを処理できることを意味します。
• v3引数とマッパーファクトリ、およびオプションを返す単一メソッドの関数型インターフェイス。 v2には、別々のaccepts（）メソッドとbuild（）メソッドがありました。
• v3のSQLオブジェクトタイプは、パブリックインターフェイスのみである必要があります。クラスは使用できません。 メソッドの戻り型も同様にパブリックである必要があります。 これは、SQLオブジェクトの実装がCGLIBからjava.lang.reflect.Proxyに切り替わり、インターフェイスのみをサポートするためです。
• $＃ -parametersフラグを有効にしてコードをコンパイルすることにより、SQLオブジェクトメソッドパラメーターの@Bindアノテーションをオプションにすることができます。
• オンデマンドSQLオブジェクトは、Iterablesを返すメソッドではうまく機能しません。 オンデマンドオブジェクトは、各メソッド呼び出しの後にハンドルを厳密に閉じ、v2の場合のように反復可能オブジェクトの消費を終了するために「ドアを開いたままにする」ことはなくなりました。 これにより、接続リークの主な原因が排除されます。
• SQLオブジェクトは閉じられなくなりました。オンデマンドであるか、ライフサイクルがアタッチされていたハンドルのライフサイクルに関連付けられています。
• StatementLocatorインターフェイスがコアから削除されました。 すべてのコアステートメントは、実際のSQLを受け取ることを期待しています。 同様の概念であるSqlLocatorが追加されましたが、SQLオブジェクトの領域でのみ追加されました。

もう1つ： StatementRewriterはTemplateEngineとSqlParserにリファクタリングされました。

リストに追加することが非常に重要なのは、selectの動作です。 それはこれから来ました：

List<Map<String, Object>> rs = h.select("select id, name from something");

これに：

List<Map<String, Object>> rs = h.select("select id, name from something").mapToMap().list();

v3の追加のパワーと柔軟性、および安全性が、冗長性の代償を伴わないことを願っています。

こんにちは@javajosh 、 Mapオブジェクトへのマッピングを思いとどまらせようとしているので、その特定のものがそれほど悪いとは考えていませんでした。 他に何もないとしても、キーの大文字と小文字の区別に関する規則は混乱を招きます。 独自に定義された型を作成するのではなく、 Mapを発行しなければならない理由はありますか？ 私は個人的に常に小さな結果クラスを作成し（コンストラクター/フィールド/プロパティマッパーとバインダーを使用）、常にMapの使用を避けます。 非常に便利なユースケースはありますか？

こんにちは@ stevenschlansker-私は「開発者の最初の経験」の観点からそれに取り組んでいます。 上記のコードは、あなた自身のv2チュートリアルから抜粋したもので、見事にミニマリストだと思います。 実際、JavaScriptのようなマップが組み込まれているGroovyのようなJVMでホストされている言語を使用すると、型指定されていない結果がより頻繁に表示されます。

@javajosh https://github.com/jdbi/jdbi/pull/925についてどう思いますか？

@ stevenschlansker ＃928のことですか？

@stevenschlansker間違いなく改善です！ しかし、それでもv2よりも冗長です。 :)これは、Mavenなどの冗長性の向上に加えてです。JDBIが、いくつかの優れた機能を備えていたためにv4を採用するのに苦労したJUnitの道を進むのを見たくありませんが、それよりもはるかに複雑でした。 v3とv3は「十分」でした。 「withHandle」構文についても同じように感じます（ただし、ぶら下がっているハンドルをすべて削除するというあなたの本能は理解しています）。

@javajoshより詳細な制御が必要な場合は、まだJdbi.open()がありますが、安全のためにtry-with-resourcesブロック内で使用することをお勧めします。

v2からv3への移行ドキュメントの作業を開始します。

@javajosh $＃$ List<Map<String,Object>> ResultBearing.list()に戻る：特にリリースサイクルの後半で、これを追加するのが良い考えかどうかはわかりません。

冗長性に関するあなたの懸念に共感しますが、その冗長性は開発者の意図を明確にする目的を果たします。

handle.createQuery(sql)
    .mapToMap()
    .list()

読者には次のことよりも明確です。

handle.createQuery(sql)
    .list()

それはデリケートなことであり、私はあなたの立場を選ばなければならないことをうらやましくはありません。 JDBIは素晴らしいライブラリであり、冗長性に関する懸念事項を登録できてうれしいです。 この特定のケースで便利な方法を追加することが理にかなっているかどうかはわかりませんが、私はプロジェクトに真剣に関与していないので、私に対するあなたの判断を信頼する傾向があります！ 聞いてくれてありがとう！

短い名前でどのように改善されるかについての具体的な例、またはそれを改善する方法のショーケースを思いついた場合は、お知らせください😄