Jdbi: Mencegah dan mencela dukungan StringTemplate4

Mari kita mulai dengan pemberitahuan di dokumen bahwa proyek StringTemplate tidak aktif.

Saya akan membiarkan anggota proyek lain mempertimbangkan pertanyaan tentang penghentian integrasi ST Jdbi. Secara pribadi saya pikir kita harus terus mendukungnya setidaknya untuk sementara waktu. Kami baru saja mulai mendukung ST4 sejak awal.

Saya pikir kita perlu alternatif. Tidak memiliki cara untuk membuat templat yang rumit untuk sql adalah hal yang tidak boleh dilakukan. Saya harus dapat berbagi bit dan bagian sql di antara templat yang berbeda, dan untuk dapat memasukkan hal-hal umum ke dalam metode templat. Bagi saya, menghapus stringtemplate membuat saya mencari kerangka kerja alternatif lain. Jika tidak saya akan terpaksa membuat file sql dengan banyak duplikasi.

Mari tambahkan NOTICE sekarang. Kami dapat menghentikannya setelah kami memiliki pengganti yang layak.

Adakah yang punya mesin templating favorit yang cocok dengan jdbi? Saya telah menggunakan mustache sedikit dan itu baik-baik saja, tapi saya jauh dari ahli...

Terima kasih @jarlah , itu seperti yang saya harapkan.

Sangat disayangkan StringTemplate diabaikan di bagian hulu, tetapi selama orang menggunakannya dan berfungsi, tidak ada alasan bagi kami untuk menarik dukungan.

Kami cukup senang dengan FreeMarker tempat saya bekerja. Kumis juga merupakan pilihan yang bagus.

Setuju dengan @jarlah - diperlukan alternatif. Saya juga aktif menggunakan template dan duplikasi akan besar-besaran tanpa ST. Alternatif harus sederhana dan ekspresif - apa yang saya suka tentang ST saat ini. Saya menggunakan Freemarker sejak lama dan jika saya mengingatnya dengan benar - itu tidak terlihat sederhana untuk templating SQL.

BTW Ini adalah masalah terakhir saya dengan ST, haruskah saya mempostingnya di sini dengan kode solusi pada tingkat integrasi jdbi?

Jika ada solusi sederhana yang dapat dilakukan jdbi tanpa terlalu memperumit banyak hal, kami pasti akan mempertimbangkannya.

Bagaimana templateEngine tambahan dibundel dalam jdbi? Mereka semua membawa dependensi eksternal yang tidak kita inginkan core , dan tidak membuat modul 1-kelas atau menyetel \

Stringtemplate IIRC punya modul mvn sendiri, jadi mungkin kita harus terus melakukannya? Kedengarannya seperti lebih sedikit kerumitan peretasan bagi pengguna daripada dependensi opsional.

Saya tertarik untuk menyumbangkan mesin StringSubstitutor (jika saya belum melakukannya), dan Kumis tampaknya juga cukup menyenangkan untuk dilakukan.

Jika itu adalah kelas tunggal mandiri dengan ketergantungan <optional> tunggal, atau sama ringannya, itu bisa masuk ke inti. Jika tidak, mari kita putar modul. Preferensi saya dimaksudkan untuk menjadi pedoman, bukan bar yang mustahil untuk dilewati :)

Itu akan putus dengan pola yang ditetapkan oleh modul stringtemplate4. Dan saya tahu sebagai pengguna ada sedikit lagi yang saya benci daripada harus main-main dengan pakar, terutama dependensi dari dependensi saya ...

Saya melihat stringtemplate mendapat @UseStringTemplateEngine meskipun @UseTemplateEngine sudah ada. Apakah ini hal kenyamanan yang diinginkan untuk setiap mesin template atau apakah kita lebih baik tetap berpegang pada anotasi umum saja mulai sekarang kecuali diperlukan?

Secara pribadi saya lebih suka mereka dipecah menjadi modul, sehingga Anda bahkan tidak dapat melihat kelas di IDE Anda tanpa dependensinya disertakan secara transitif di classpath. NoClassDefFoundError bisa sangat menyakitkan.

Saya telah bekerja dengan banyak freemarker di masa lalu. Ini bisa menjadi upaya yang menyenangkan untuk menerapkan dukungan untuk itu. Ini tidak secara langsung dimaksudkan untuk itu. Tapi itu mungkin. Harus memperhatikan kinerja dengan baik.

Saya bisa membuat lonjakan jika tidak ada yang lain

saat ini sedang mengerjakannya. Tidak akan membuka permintaan tarik sebelum saya memiliki bukti konsep kerja yang masuk akal. Ada masalah dengan menggunakan Konfigurasi, karena pemuatan template tidak statis, harus dinamis. Jadi setiap template harus dimuat dan di-cache secara manual. Saya telah mengkloning modul stringtemplate4 dan mengganti nama kelas dll. Jika seseorang tertarik maka saya sedang mengerjakan cabang master di garpu jdbi saya.

Saya pikir situasi yang menyebabkan masalah ini adalah kombinasi dari yang berikut:

• StringTemplate 4 umumnya bekerja dengan sangat baik (dapat diprediksi jika tidak ada yang lain) dalam penggunaan utas tunggal
• StringTemplate 4 tidak dirancang dengan penekanan khusus pada penggunaan bersamaan, yang menyebabkan bug yang sulit untuk diselesaikan tanpa merusak pengguna yang ada, sehingga sebagian besar hanya tetap apa adanya

Jika StringTemplate 5 dibuat, saya mengharapkan konkurensi yang aman (dan kemungkinan kekekalan) untuk memainkan peran besar dalam desain dasar.