Hibernate-reactive: ekspor skema melalui driver Vert.x alih-alih JDBC

Ini agak aneh. Pada saat yang sama saya lebih suka untuk tidak memiliki terlalu banyak cara untuk mengkonfigurasi string koneksi yang sama. Di masa depan pengguna mungkin akan dapat menggunakan ORM dengan Rx dan mungkin ingin menggunakan Rx API hanya dalam beberapa kasus. Juga bagus bahwa kami menggunakan properti yang sudah akrab bagi pengguna ORM.

Ah maaf. Saya baru menyadari bahwa Anda tidak sedang membicarakan nama properti.

Sebagian besar, saya bertanya-tanya apakah ada kasus penggunaan di mana seseorang ingin menggunakannya
parameter konfigurasi yang berbeda.
Saya kira itu bisa terjadi jika driver reaktif asli memiliki beberapa spesifik
properti.

Bagaimanapun, saya kira kita harus memiliki properti yang mirip dengan yang ORM tapi
dengan bagian jdbc dihapus dari nama.
Dan putuskan apa yang terjadi jika hanya satu jenis properti yang disetel.

Pada Jumat, 1 Mei, 2020 05:53 Andrew Guibert [email protected]
menulis:

Dengan cara yang sama, saya tidak berpikir kita harus melampaui batas dengan membuat sesuatu
nyaman / akrab. Misalnya, saat ini kami mendukung konfigurasi RX dengan
URL protokol jdbc, yang nyaman/akrab tetapi tidak secara teknis
benar karena kami tidak menggunakan JDBC.

—
Anda menerima ini karena Anda berkomentar.
Balas email ini secara langsung, lihat di GitHub
https://github.com/hibernate/hibernate-rx/issues/104#issuecomment-622468348 ,
atau berhenti berlangganan
https://github.com/notifications/unsubscribe-auth/AAEIQ5JHS5PQ7M7APGO2YVLRPL5APANCNFSM4MXDM4CA
.

Bagaimanapun, saya kira kita harus memiliki properti yang mirip dengan yang ORM tetapi dengan bagian jdbc dihapus dari namanya.

Saya pikir kita harus tetap menggunakan format URL JDBC standar karena:

• itu standar
• itu didokumentasikan dengan baik oleh vendor database
• semua orang sudah mengetahuinya
• membuatnya lebih mudah untuk mengonfigurasi Hibernate RX dan Hibernate biasa atau JDBC biasa secara bersamaan

@DavideD Saya mungkin belum menjelaskan masalah dengan benar di OP, tetapi bagaimana parameter konfigurasi ikut bermain untuk skema gen?

Untuk menyatakan kembali maksud yang saya miliki dengan masalah ini, saya menyarankan agar prosedur drop/create table otomatis dapat dilakukan tanpa perlu melibatkan driver JDBC atau konfigurasi khusus jdbc (jika RX kebetulan menggunakan kembali properti yang sama , tidak apa-apa meskipun)

Ah maaf. Saya baru menyadari bahwa Anda tidak sedang membicarakan nama properti.

Ya, mengerti. Salahku. Saya membacanya terlalu cepat untuk pertama kalinya.

Tampaknya agak canggung untuk meminta pengguna menambahkan/mengonfigurasi driver JDBC jika aplikasi mereka hanya menggunakan RX.

Kalimat ini di sini membuat saya berpikir Anda berbicara tentang fakta bahwa kami menggunakan properti untuk konfigurasi JDBC yang sudah ada di ORM. Masih bagus bahwa kami membicarakannya dan saya tidak berencana untuk mengubahnya untuk saat ini.

Jadi sebelumnya saya berpendapat bahwa melakukan ekspor skema melalui JDBC baik-baik saja. (Apa yang dimaksud dengan ekspor skema reaktif?)

Namun, dalam percakapan telepon dengan @emmanuelbernard dan @Sanne , saya menyadari bahwa ini sebenarnya merupakan titik sakit potensial bagi pengguna Quarkus.

Saya seharusnya lebih memperhatikan @aguibert ketika dia mencoba memperingatkan saya tentang ini.

Jadi, bagaimanapun, ini memang masalah yang harus kita prioritaskan, meskipun saya curiga itu tidak bisa dilakukan tepat waktu untuk rilis awal.

ide aneh - maafkan saya jika ini konyol karena saya tidak benar-benar tahu - tetapi bertanya-tanya apakah kita dapat membungkus driver reaktif menjadi adaptor yang kompatibel dengan JDBC, kemudian memasukkannya ke dalam kode gen skema?

Saya kira pekerjaan seperti itu akan berlebihan jika hanya memfasilitasi alat skema, tetapi mungkin ada lebih banyak kegunaan?

@Sanne

Nah ada abstraksi di sini, yang disebut GenerationTarget . Kami mungkin dapat menerapkannya, meskipun saya tidak 100% yakin persis bagaimana cara menghubungkannya.

Jika gagal, satu hal yang mungkin dapat kita lakukan adalah meminta alat ekspor skema untuk mengekspor SCRIPT , dan kemudian hanya mengirim perintah satu per satu ke DB.

Kami mungkin dapat menerapkannya, meskipun saya tidak 100% yakin persis bagaimana cara menghubungkannya.

Masalahnya adalah bahwa daftar target ini tampaknya di-hardcode, tanpa cara yang jelas untuk menambahkan yang baru. Tetapi perbaikan kecil ke inti mungkin cukup untuk menyelesaikannya.

Oke. Meskipun ini masih bukan prioritas utama, saya akan menunda rilis ORM berikutnya sebanyak mungkin, jadi jika seseorang menemukan waktu, kami dapat menyertakan beberapa tambalan menit terakhir lagi.

Untuk referensi, ingatlah bahwa melakukan rilis benar-benar tidak memakan waktu lama: sekitar 20 menit. Tapi kemudian kita harus menunggu sinkronisasi pusat Maven dan semua itu sebelum benar-benar dapat digunakan :(
Yang berarti kita perlu merilis sekitar 24 jam sebelum rilis Reaktif dimungkinkan.

Saya akan menyisihkan waktu untuk mencoba ini. Mungkin itu super sederhana. Kami akan mencari tahu.

Mungkin itu super sederhana. Kami akan mencari tahu.

Jadi, memang, itu relatif mudah, tetapi itu menimbulkan masalah yang belum saya pertimbangkan: Hibernate Reactive tidak lagi memiliki akses ke metadata JDBC, yang memang memiliki beberapa konsekuensi, tetapi saya tidak berpikir mereka terlalu buruk. Untungnya Hibernate ditulis ketika metadata JDBC sangat tidak dapat diandalkan, dan tidak terlalu bergantung padanya.

Saya kira tidak apa-apa.

Itu juga mengekspos bug di ForeignKeys mana Hibernate Reactive akan benar-benar menggunakan koneksi JDBC untuk mendapatkan snapshot dari database! Saya akan membuka laporan bug terpisah untuk masalah itu.

Keren terima kasih!

Perbaikan Gavin digabungkan dalam ORM; pembuatan skema harus bisa dilakukan sekarang.

Saya menduga pembaruan skema otomatis sedikit lebih rumit - dapatkah kita setuju bahwa itu kurang penting untuk potongan pertama?

Perbaikan Gavin digabungkan dalam ORM; pembuatan skema harus bisa dilakukan sekarang.

Terima kasih.

Saya menduga pembaruan skema otomatis sedikit lebih rumit

Oh, jauh lebih sulit, karena implementasi saat ini sepenuhnya didasarkan pada metadata JDBC, IIRC.

bisakah kita setuju bahwa itu kurang penting untuk potongan pertama?

Ya, saya tidak punya niat sama sekali untuk mengerjakan itu pada tahap ini. Saya juga tidak berpikir itu diperlukan.

@Sanne berapa lama sebelum kita mendapatkan rilis inti ORM dengan perubahan di dalamnya?

@gavinking kami dapat merencanakan rilis pada hari Senin. Saya bertanya-tanya - jika ada lebih banyak perubahan yang mungkin diperlukan, mungkin yang terbaik adalah menunda?
Kami juga sedang mengerjakan beberapa perbaikan lain yang dibutuhkan Quarkus - jadi sementara kami dapat merilisnya kapan pun kami mau, semakin lama semakin banyak perbaikan.

@Sanne Jangan pegang erat-erat, komentar itu dibuat sebelum saya menemukan keseriusan #113.

@gavinking di beberapa titik, bisakah Anda menulis masalah di Vertx-sql-client yang menguraikan jenis metadata DB apa yang dibutuhkan oleh Hibernate? Klien Vertx harus memiliki API metadata yang lebih baik daripada saat ini suatu hari nanti.

+1 untuk Andre!

Kami memiliki inisiatif untuk membangun metadata yang mengambil API untuk Postgres di
https://github.com/Eclipse-vertx/vertx-sql-client/pull/513. Umpan balik akan
tentu membantu kami membangun API generik yang lebih baik di sekitar ini.

Pada Thu, 14 Mei, 2020 09:58 Andrew Guibert [email protected]
menulis:

@gavinking https://github.com/gavinking di beberapa titik dapatkah Anda menulis
masalah pada Vertx-sql-client yang menguraikan jenis metadata DB
dibutuhkan oleh Hibernate? Klien Vertx harus memiliki API metadata yang lebih baik
daripada saat ini tidak suatu hari nanti.

—
Anda menerima ini karena Anda berlangganan utas ini.
Balas email ini secara langsung, lihat di GitHub
https://github.com/hibernate/hibernate-reactive/issues/104#issuecomment-628654875 ,
atau berhenti berlangganan
https://github.com/notifications/unsubscribe-auth/ABJV4JODSAYQT7BG2TWHZI3RRP2JFANCNFSM4MXDM4CA
.

Apa yang dibutuhkan alat manajemen skema adalah akses ke informasi di information_schema.tables dan saya kira juga information_schema.key_column_usage .

Apa yang dibutuhkan alat manajemen skema adalah akses ke informasi di information_schema.tables dan saya kira juga information_schema.key_column_usage .

Perhatikan bahwa satu opsi adalah untuk mendapatkan informasi itu secara langsung dengan menanyakan information_schema . Secara historis itu hanya API metadata JDBC untuk itu, untuk mengabstraksi dari perbedaan platform.

Hal ini dilakukan!

Dan itu dilakukan dengan cara yang cukup transparan bagi pengguna: jika mereka memiliki driver JDBC atau kumpulan koneksi yang diatur, maka Hibernate ORM akan melakukan ekspor skema melalui JDBC tetapi jika mereka tidak memiliki driver JDBC, maka ekspor skema berakhir driver Vert.x akan masuk.

Itu luar biasa!
Terima kasih banyak

Dan itu dilakukan dengan cara yang cukup transparan bagi pengguna: jika mereka memiliki driver JDBC atau kumpulan koneksi yang diatur, maka Hibernate ORM akan melakukan ekspor skema melalui JDBC tetapi _iff_ mereka tidak memiliki driver JDBC, maka ekspor skema berakhir driver Vert.x akan masuk.

penasaran aja, kenapa harus coba pake pendekatan JDBC dulu? Jika kita memiliki kemampuan untuk menjalankannya di atas vertx, mengapa tidak selalu melakukannya?

Mungkin membingungkan pengguna jika ada perilaku berbeda yang dipicu hanya karena beberapa koneksi yang tidak terkait sedang disiapkan. Juga - bagaimana Anda tahu jika koneksi lain itu benar-benar menunjuk ke DB yang sama?

penasaran aja, kenapa harus coba pake pendekatan JDBC dulu? Jika kita memiliki kemampuan untuk menjalankannya di atas vertx, mengapa tidak selalu melakukannya?

Nah, jika Anda memiliki Hibernate reguler di sana yang diatur dengan driver JDBC biasa, mengapa tidak menggunakannya? Ekspor skema reaktif bukanlah hal yang berarti. Untuk membuatnya bekerja, kita harus melakukan join() benar-benar buruk di akhir, yang menurut Vert.x cukup mengecewakan.

bagaimana Anda tahu jika koneksi lain itu benar-benar menunjuk ke DB yang sama?

Karena itu URL JDBC yang sama?