Jdbi: Panduan pengembang: migrasi v2 ke v3

Catatan dari migrasi proyek kecil:

Mengganti nama kelas (jadi tidak sesederhana menghapus impor dan membiarkan IDE memperbaikinya):

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

Konstruktor untuk Jdbi telah diganti dengan metode pabrik create() .

ResultSetMapper diganti dengan RowMapper dan metode map tidak lagi memiliki indeks baris. Kelas bernama ResultSetMapper ada di Jdbi 3, tetapi memiliki tujuan yang berbeda. @Mapper diganti dengan @UseRowMapper . registerMapper() pada Jdbi diganti dengan registerRowMapper() .

@BindIn diganti dengan @BindList dan tidak lagi membutuhkan StringTemplate.

Dengan templating Jdbi default, tanda kurung sudut tidak dikutip, yang berarti IntelliJ memahami sintaks setelah Anda mengonfigurasi Pola Parameter di bawah Tools -> Database -> User Patterns .

Query tidak lagi memiliki tipe default Map dan dengan demikian list() tidak dapat dipanggil secara langsung. Hubungi mapToMap() sebelum menelepon list() .

TransactionStatus tidak ada lagi.

TransactionConsumer.useTransaction() hanya membutuhkan Handle sekarang, jadi argumen TransactionStatus perlu dihapus saat menggunakan ini dengan metode useTransaction() pada Jdbi atau Handle .

TransactionCallback.inTransaction() hanya membutuhkan Handle sekarang, jadi argumen TransactionStatus perlu dihapus saat menggunakan ini dengan metode inTransaction() pada Jdbi atau Handle .

CallbackFailedException tidak ada lagi. Berbagai antarmuka fungsional seperti HandleConsumer , HandleCallback , TransactionalConsumer , dan TransactionalCallback , sekarang dapat membuang semua jenis pengecualian (tetapi dibatasi menggunakan obat generik untuk menghindari pemeriksaan yang tidak perlu penanganan pengecualian).

Dukungan SQL Object tidak lagi tersedia secara default. Itu harus didaftarkan setiap instance Jdbi yang dibuat.

Migrate Refactor IntelliJ sangat membantu untuk memulai migrasi.

Terima kasih @electrum untuk menyatukan ini! Ini akan sangat membantu

Beberapa catatan tambahan dari meninjau presentasi saya:

• Artefak berganti nama menjadi org.jdbi:jdbi -> org. jdbi:jdbi3 , :jdbi3-sqlobject, :jdbi3-guava, dll
• Paket inti diubah: org.skife.jdbi.v2 -> org.jdbi.v3. Ini berarti v2 dan v3 dapat hidup berdampingan di sebuah proyek saat Anda bermigrasi
• Berganti nama: GetHandle -> SqlObject
• argumen v3 dan pabrik mapper menggunakan java.lang.reflect.Type , sedangkan v2 menggunakan java.lang.Class . Ini berarti v3 mampu menangani tanda tangan tipe generik kompleks yang tidak bisa dilakukan v2.
• argumen v3 dan pabrik mapper dan antarmuka fungsional metode tunggal yang mengembalikan opsional. v2 memiliki metode accept() dan build() yang terpisah.
• Jenis Objek SQL di v3 hanya boleh berupa antarmuka publik--tidak ada kelas. Jenis pengembalian metode juga harus bersifat publik. Ini karena implementasi SQL Object beralih dari CGLIB ke java.lang.reflect.Proxy, yang hanya mendukung antarmuka.
• Anotasi @Bind pada parameter metode Objek SQL dapat dibuat opsional, dengan mengkompilasi kode Anda dengan flag -parameters diaktifkan.
• Objek SQL sesuai permintaan tidak cocok dengan metode yang mengembalikan Iterables. Objek berdasarkan permintaan secara ketat menutup pegangan setelah setiap panggilan metode, dan tidak lagi "menahan pintu terbuka" bagi Anda untuk menyelesaikan konsumsi iterable seperti yang mereka lakukan di v2. Ini menyita sumber utama kebocoran koneksi.
• Objek SQL tidak lagi dapat ditutup -- objek tersebut sesuai permintaan, atau siklus hidupnya terkait dengan siklus hidup pegangan yang dilampirkannya.
• Antarmuka StatementLocator dihapus dari inti. Semua pernyataan inti berharap untuk menerima SQL aktual sekarang. Konsep serupa, SqlLocator telah ditambahkan tetapi hanya di bidang Objek SQL.

Satu lagi: StatementRewriter telah difaktorkan ulang menjadi TemplateEngine dan SqlParser .

Sangat penting untuk ditambahkan ke daftar adalah perilaku pilih. Itu pergi dari ini:

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

Untuk ini:

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

Saya berharap kekuatan ekstra dan fleksibilitas dan keamanan v3 tidak datang dengan harga bertele-tele.

Hai @javajosh , kami tidak menganggap yang satu itu terlalu buruk karena kami mencoba untuk mencegah pemetaan ke objek Map . Jika tidak ada yang lain, aturan seputar sensitivitas huruf besar/kecil untuk kunci membingungkan. Apakah ada alasan Anda harus mengeluarkan Map daripada membuat tipe yang Anda tentukan sendiri? Saya pribadi akan selalu menulis kelas hasil kecil (menggunakan konstruktor/bidang/pemeta dan pengikat properti) dan selalu menghindari penggunaan Map . Apakah Anda memiliki beberapa kasus penggunaan yang sangat nyaman?

Hai @stevenschlansker - Saya membahasnya dari perspektif "pengalaman pertama pengembang". Kode di atas diambil dari tutorial v2 Anda sendiri, yang menurut saya sangat minimalis. Dan memang, dengan bahasa yang dihosting JVM seperti Groovy, yang memiliki peta bawaan seperti javascript, Anda mungkin akan lebih sering melihat hasil yang tidak diketik.

@javajosh apa pendapat Anda tentang https://github.com/jdbi/jdbi/pull/925 ?

@stevenschlansker Apakah maksud Anda #928 ?

@stevenschlansker Pasti peningkatan! Tapi itu masih lebih verbose dari v2. :) Ini selain verbositas yang lebih besar di maven, dll. Saya hanya tidak ingin melihat JDBI mengikuti JUnit yang berjuang untuk membuat orang mengadopsi v4 karena memiliki beberapa fitur yang bagus, tetapi jauh lebih rumit daripada v3 dan v3 adalah "cukup baik". Saya memiliki perasaan yang sama tentang sintaks "withHandle" (walaupun saya mengerti naluri Anda untuk menghilangkan semua pegangan yang menggantung).

@javajosh Anda masih memiliki Jdbi.open() jika Anda ingin kontrol yang lebih besar, meskipun kami menyarankan Anda menggunakannya di dalam blok coba-dengan-sumber daya untuk keamanan.

Mulai mengerjakan dokumen migrasi v2 ke v3.

@javajosh Kembali ke metode ResultBearing.list() yang mengembalikan List<Map<String,Object>> : Saya tidak yakin menambahkan ini adalah ide yang bagus, terutama di akhir siklus rilis ini.

Saya berempati dengan kekhawatiran Anda tentang verbositas, tetapi verbositas itu bertujuan untuk memperjelas maksud pengembang:

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

lebih jelas bagi pembaca daripada:

handle.createQuery(sql)
    .list()

Ini hal yang rumit, dan saya tidak iri dengan posisi Anda yang harus memilih. JDBI adalah perpustakaan yang bagus, dan saya senang telah mencatat kekhawatiran saya tentang verbositas; apakah masuk akal untuk menambahkan metode kenyamanan dalam kasus khusus ini, saya tidak yakin dan akan cenderung mempercayai penilaian Anda atas penilaian saya, karena saya tidak terlibat secara serius dalam proyek tersebut! Terima kasih untuk mendengarkan!

Beri tahu kami jika Anda menemukan contoh nyata tentang bagaimana nama yang lebih pendek lebih baik, atau contoh bagaimana kami dapat meningkatkannya