Hibernate - tutorial apa yang dibungkam

Masalah memetakan model objek menjadi relasional

Masalah 1. Warisan dan pertanyaan polimorfik.

1. Semua ahli waris berada di tabel yang sama:
   @Inheritance (strategi = InheritanceType.SINGLE_TABLE)
   
   
   
   Dalam hal ini, bidang umum dan bidang ahli waris terletak di satu meja. Menggunakan strategi ini, kami menghindari bergabung ketika memilih entitas. Dari minus, perlu dicatat bahwa, pertama, kita tidak dapat mengatur batasan “NOT NULL” untuk kolom “force” dalam model relasional, dan kedua, kita kehilangan bentuk normal ketiga. (ketergantungan transitif dari atribut non-kunci muncul: force and disc).
   
   Omong-omong, termasuk untuk alasan ini ada 2 cara untuk menentukan batasan bidang bukan nol - NotNull bertanggung jawab untuk validasi; @ Kolom (nullable = true) - bertanggung jawab atas kendala bukan nol dalam database.
   
   Menurut pendapat saya, ini adalah cara terbaik untuk memetakan model objek ke model relasional.
   
2. Bidang khusus entitas berada di tabel terpisah.
   
   @Inheritance (strategi = InheritanceType.JOINED)
   
   
   
   Dalam kasus ini, bidang umum disimpan dalam tabel bersama, dan khusus untuk entitas anak disimpan dalam yang terpisah. Dengan menggunakan strategi ini, kami mendapatkan GABUNGAN saat memilih entitas, tetapi sekarang kami menyimpan bentuk normal ketiga, dan kami juga dapat menentukan batasan NOT NULL dalam database.
3. Setiap entitas memiliki tabel sendiri.
   
   @ InheritanceType.TABLE_PER_CLASS
   
   
   
   Dalam hal ini, kami tidak memiliki tabel bersama. Menggunakan strategi ini, kami menggunakan UNION untuk kueri polimorfik. Kami mengalami masalah dengan generator kunci utama dan kendala integritas lainnya. Jenis pemetaan warisan sangat tidak dianjurkan.

Masalah 2. Rasio komposisi dalam OOP

Manajer Entitas

1. Menangkap koneksi basis data
   
   Ini hanya poin yang menarik. Hibernate tidak menangkap Connection pada saat menerima EM, tetapi pada akses pertama ke database atau membuka transaksi (meskipun masalah ini dapat diselesaikan ). Ini dilakukan untuk mengurangi waktu koneksi yang sibuk. Selama menerima EM-a, keberadaan transaksi JTA diperiksa.
2. Entitas gigih selalu memiliki id
3. Entitas yang menjelaskan satu baris dalam database setara dengan referensi
   Seperti disebutkan di atas, EM memiliki cache tingkat pertama, objek di dalamnya dibandingkan dengan referensi. Oleh karena itu, muncul pertanyaan - bidang mana yang harus digunakan untuk mengganti persamaan dan kode hash? Pertimbangkan opsi berikut:
   
   
   • Gunakan semua bidang. Ide yang buruk sama dengan dapat mempengaruhi bidang LAZY. Omong-omong, ini juga berlaku untuk metode toString.
   • Gunakan id saja. Ide yang normal, tetapi ada nuansa juga. Karena paling sering untuk entitas baru id menempatkan generator pada saat bertahan. Situasi berikut mungkin terjadi:
     
     

     Entity foo = new Entity(); //   (id = null) set.put(foo); //   hashset em.persist(foo); // persist  (id = some value) set.contains(foo) == false // .. hashCode    

     
     
   • Gunakan kunci bisnis (secara kasar, bidang yang unik dan BUKAN NULL). Tetapi opsi ini tidak selalu nyaman.
     
     Ngomong-ngomong, karena kita berbicara tentang NOT NULL dan UNIK, kadang-kadang nyaman untuk membuat konstruktor publik dengan argumen NOT NULL, dan konstruktor tanpa argumen dilindungi.
   • Jangan menimpa sama dengan dan kode hash sama sekali.
4. Cara kerja flush
   Flush - mengeksekusi akumulasi insert, update, dan delete pada database. Secara default, flush dijalankan dalam kasus:
   
   
   • Sebelum menjalankan kueri (dengan pengecualian em.get), ini perlu untuk mematuhi prinsip ACID. Misalnya: kami mengubah tanggal lahir pesawat serang, dan kemudian kami ingin mendapatkan jumlah pesawat serang orang dewasa.
     
     Jika kita berbicara tentang CriteriaQuery atau JPQL, maka flush akan dieksekusi jika kueri memengaruhi tabel yang entitasnya ada dalam cache dari level pertama.
   • Saat melakukan transaksi;
   • Kadang-kadang ketika mempertahankan entitas baru - dalam kasus ketika kita bisa mendapatkan id hanya melalui sisipan.
   
   Dan sekarang tes kecil. Berapa banyak operasi UPDATE yang akan dilakukan dalam kasus ini?
   
   

    val spaceCraft = em.find(SpaceCraft.class, 1L); spaceCraft.setCoords(...); spaceCraft.setCompanion( findNearestSpaceCraft(spacecraft) ); 

   
   Fitur hibernasi yang menarik disembunyikan di bawah operasi flush - ia berusaha mengurangi waktu yang diperlukan untuk mengunci baris dalam database.
   
   Perhatikan juga bahwa ada beberapa strategi berbeda untuk operasi flush. Misalnya, Anda dapat melarang "penggabungan" perubahan ke database - ini disebut MANUAL (ini juga menonaktifkan mekanisme pemeriksaan kotor).
   
5. Pemeriksaan kotor
   
   Pengecekan Kotor adalah mekanisme yang dilakukan selama operasi flush. Tujuannya adalah untuk menemukan entitas yang telah berubah dan memperbaruinya. Untuk menerapkan mekanisme seperti itu, hibernate harus menyimpan salinan asli objek (dengan objek apa yang sebenarnya akan dibandingkan). Untuk lebih tepatnya, hibernate menyimpan salinan bidang objek, bukan objek itu sendiri.
   
   Perlu dicatat bahwa jika grafik entitas besar, maka operasi pemeriksaan kotor bisa mahal. Jangan lupa bahwa hibernate menyimpan 2 salinan entitas (secara kasar).
   Untuk "mengurangi biaya" dari proses ini, gunakan fitur berikut:
   
   
   • em.detach / em.clear - lepaskan entitas dari EntityManager
   • FlushMode = MANUAL - berguna dalam operasi baca
   • Abadi - juga menghindari operasi pengecekan kotor
   
   
6. Transaksi
   
   Seperti yang Anda ketahui, hibernasi memungkinkan Anda memperbarui entitas hanya dalam transaksi. Operasi baca menawarkan lebih banyak kebebasan - kita dapat menjalankannya tanpa secara eksplisit membuka transaksi. Tetapi justru ini pertanyaannya: apakah layak untuk membuka transaksi secara eksplisit untuk operasi baca?
   
   Saya akan mengutip beberapa fakta:
   
   
   • Pernyataan apa pun dijalankan di basis data di dalam transaksi. Bahkan jika kita jelas tidak membukanya. (mode komit otomatis).
   • Sebagai aturan, kami tidak terbatas pada satu permintaan ke database. Misalnya: untuk mendapatkan 10 catatan pertama, Anda mungkin ingin mengembalikan jumlah total catatan. Dan ini hampir selalu 2 permintaan.
   • Jika kita berbicara tentang data pegas, maka metode repositori adalah transaksional secara default , sedangkan metode baca hanya baca.
   • Anotasi pegas @Transaksional (readOnly = true) juga memengaruhi FlushMode, lebih tepatnya, Pegas meletakkannya dalam status MANUAL, sehingga hibernate tidak akan melakukan pemeriksaan kotor.
   • Pengujian sintetis dengan satu atau dua permintaan basis data akan menunjukkan bahwa komit otomatis lebih cepat. Tetapi dalam mode tempur, ini mungkin tidak begitu. ( artikel bagus tentang hal ini , + lihat komentar)
   
   Singkatnya: adalah praktik yang baik untuk melakukan komunikasi apa pun dengan database dalam suatu transaksi.
   

Generator

• GenerationType.AUTO - pemilihan generator didasarkan pada dialek. Bukan pilihan terbaik, karena aturan "eksplisit lebih baik daripada implisit" hanya berlaku di sini.
• GenerationType.IDENTITY adalah cara termudah untuk mengonfigurasi generator. Itu bergantung pada kolom kenaikan otomatis di tabel. Karena itu, untuk mendapatkan id dengan persisten kita perlu melakukan insert. Itulah sebabnya mengapa menghilangkan kemungkinan ditangguhkan bertahan dan karena itu batching.
• GenerationType.SEQUENCE adalah kasus paling nyaman ketika kita mendapatkan id dari urutan.
• GenerationType.TABLE - dalam hal ini hibernate mengemulasi urutan melalui tabel tambahan. Bukan pilihan terbaik, karena dalam solusi semacam itu, hibernate harus menggunakan transaksi terpisah dan mengunci per baris.

• tidak ada - tidak ada optimasi. untuk setiap id kita tarik urutan.
• pooled dan pooled-lo - dalam hal ini, sekuens kami harus meningkat dengan interval tertentu - N dalam database (SequenceGenerator.allocationSize). Dan dalam aplikasi, kami memiliki kumpulan tertentu, nilai-nilai dari mana kami dapat menetapkan untuk entitas baru tanpa mengakses database ..
• hilo - untuk menghasilkan ID, algoritma hilo menggunakan 2 angka: hi (disimpan dalam database - nilai yang diperoleh dari panggilan urutan) dan lo (disimpan hanya dalam aplikasi - SequenceGenerator.allocationSize). Berdasarkan angka-angka ini, interval untuk menghasilkan id dihitung sebagai berikut: [(hi - 1) * lo + 1, hi * lo + 1). Untuk alasan yang jelas, algoritma ini dianggap ketinggalan jaman dan tidak disarankan untuk menggunakannya.

• SequenceHiLoGenerator adalah generator lama yang menggunakan pengoptimal hilo. Dipilih secara default jika kita memiliki hibernate.id.new_generator_mappings == properti palsu.
• SequenceStyleGenerator - digunakan secara default (jika hibernate.id.new_generator_mappings == true property). Generator ini mendukung beberapa pengoptimal, tetapi standarnya dikumpulkan.

Jalan buntu

 Thread #1: update entity(id = 3) update entity(id = 2) update entity(id = 1) Thread #2: update entity(id = 1) update entity(id = 2) update entity(id = 3) 

Set, Tas, Daftar

• Set - set entitas yang tidak terurut tanpa pengulangan;
• Bag - seperangkat entitas yang tidak teratur;
• Daftar adalah seperangkat entitas yang dipesan.

• Jika versi hibernate Anda lebih rendah dari 5.0.8, maka ada bug yang agak serius - HHH-5855 - saat memasukkan entitas anak, duplikasinya dimungkinkan (dalam kasus cascadType = MERGE dan PERSIST);
• Jika Anda menggunakan tas untuk hubungan ManyToMany, maka hibernate menghasilkan kueri yang sangat tidak pantas saat menghapus entitas dari koleksi - pertama-tama menghapus semua baris dari tabel bergabung, dan kemudian melakukan memasukkan;
• Hibernate tidak dapat mengambil beberapa tas untuk entitas yang sama secara bersamaan.

 //  bag spaceCraft.getCrew().add( luke ); //       //  set spaceCraft.getCrew().put( luke ); //      //        .     ManyToOne   : luke.setCurrentSpaceCraft( spaceCraft ); 

Referensi Kekuatan

 //  bag spaceCraft.getCrew().add( em.getReference( User.class, 1L ) ); //      ,      

Tanggal dan waktu

 setTimestamp(int i, Timestamp t, java.util.Calendar cal) 

• Tetapkan JVM zona waktu yang diinginkan
• Gunakan parameter hibernate - hibernate.jdbc.time_zone (ditambahkan pada 5.2) - hanya akan memperbaiki ZonedDateTime dan OffsetDateTime
• Gunakan jenis TIMESTAMP DENGAN TIMEZONE

 // LocalDateTime LocalDateTime.ofInstant( ts.toInstant(), ZoneId.systemDefault() ); // Instant ts.toInstant(); 

Batching

• Aktifkan batching dan atur jumlah pernyataan maksimum:
  hibernate.jdbc.batch_size (disarankan 5 hingga 30)
• Aktifkan penyortiran sisipan dan perbarui:
  hibernate.order_inserts
  hibernate.order_updates
  
• Jika kita menggunakan versi, maka kita juga harus mengaktifkannya
  hibernate.jdbc.batch_versioned_data - hati-hati di sini, Anda memerlukan driver jdbc untuk dapat memberikan jumlah baris yang terpengaruh selama pembaruan.

Masalah N +1

• Pagination. dalam kasus hubungan OneToMany, hibernasi tidak akan dapat menentukan offset dan batas. Oleh karena itu, pagination akan muncul di memori.
• Masalah produk Cartesian adalah situasi ketika database mengembalikan baris N * M * K untuk memilih buku N dengan bab M dan penulis K.

• FetchMode - memungkinkan Anda untuk mengubah algoritma pemuatan entitas anak. Dalam kasus kami, kami tertarik pada yang berikut:
  • FetchType.SUBSELECT - Memuat catatan anak dalam permintaan terpisah. Kelemahannya adalah bahwa semua kompleksitas permintaan utama diulangi dalam subselect.
  • BATCH (FetchType.SELECT + anotasi BatchSize) - juga memuat catatan sebagai permintaan terpisah, tetapi bersama dengan subquery membuat kondisi seperti WHERE parent_id IN (?,?,?, ..., N)
  Perlu dicatat bahwa saat menggunakan fetch di API Kriteria, FetchType diabaikan - GABUNG selalu digunakan
• JPA EntityGraph dan Hibernate FetchProfile - memungkinkan Anda untuk membuat aturan pemuatan entitas menjadi abstraksi terpisah - menurut pendapat saya kedua implementasi tidak nyaman.

Pengujian

• Penebangan
  • org.hibernate.SQL: debug
  • org.hibernate.type.descriptor.sql: trace
• Statistik
  • hibernate.generate_statistics

• DBUnit - memungkinkan Anda untuk menggambarkan keadaan basis data dalam format XML. Terkadang itu nyaman. Tetapi lebih baik pikirkan lagi apakah Anda membutuhkannya.
• DataSource-proxy
  • p6spy adalah salah satu solusi tertua. menawarkan logging, runtime, dll. permintaan
  • com.vladmihalcea: db-util: 0.0.1 adalah utilitas praktis untuk menemukan masalah N +1. Ini juga memungkinkan Anda untuk mencatat kueri. Komposisi tersebut mencakup anotasi Coba Lagi yang menarik, yang mencoba kembali transaksi dalam kasus OptimisticLockException.
  • Sniffy - memungkinkan Anda untuk menegaskan jumlah permintaan melalui anotasi. Dalam beberapa hal, lebih elegan daripada keputusan dari Vlad.

Sastra

• Laporan oleh Nikolai Alimenkov - Mari kita cepatkan Hibernate - laporan inilah yang menginspirasi saya untuk belajar hibernasi lebih dalam. Di bawah ini adalah sumber daya yang saya gunakan.
• Buku "Java Persistence API and Hibernate"
• Dokumentasi resmi
• Vlad M. Blog
• Java Weakly Digest - Daily Digest (tidak langsung terkait dengan topik)