Strategia generowania identyfikatorów ma kluczowe znaczenie dla wstawiania partii w Hibernate. W szczególności generowanie IDENTITY zwykle nie pracy (zauważ, że AUTO zazwyczaj mapuje również na IDENTITY). Dzieje się tak, ponieważ podczas wstawiania wsadowego Hibernate ma flagę o nazwie „requiresImmediateIdAccess”, która mówi, czy wygenerowane identyfikatory są natychmiast wymagane, czy nie; jeśli tak, przetwarzanie wsadowe jest wyłączone.
Można to łatwo zauważyć w dziennikach poziomu DEBUG, gdy jest napisane „wykonywanie natychmiastowego wstawiania tożsamości” – oznacza to, że pominięto przetwarzanie wsadowe, ponieważ powiedziano mu, że wygenerowane identyfikatory są wymagane natychmiast po wstawieniu.
Strategie generowania, które zwykle działają pracy to TABLE i SEQUENCE, ponieważ Hibernate może wstępnie generować identyfikatory, umożliwiając w ten sposób wstawianie partii.
Szybkim sposobem sprawdzenia, czy wstawianie partii działa, jest aktywacja dzienników poziomu DEBUG, ponieważ BatchingBatcher wyraźnie poinformuje Cię o rozmiarze partii, którą wykonuje („Wykonywanie rozmiaru partii:” + BatchSize ).
Dodatkowo, następujące właściwości są ważne dla uzyskania wstawienia partii. Nie śmiem twierdzić, że są one wymagane, ponieważ nie jestem wystarczająco ekspertem od Hibernacji, aby to zrobić – być może jest to tylko moja szczególna konfiguracja – ale z mojego doświadczenia wynika, że i tak były potrzebne:
hibernate.order_inserts = true
hibernate.order_updates = true
Te właściwości są dość słabo udokumentowane, ale uważam, że umożliwiły prawidłowe grupowanie instrukcji SQL INSERT i UPDATE do wykonywania wsadowego; Myślę, że to mogą być wielorzędowe wstawki, których szukasz. Nie strzelaj do mnie, jeśli się mylę, przypominam sobie z pamięci.
Pójdę również i założę, że ustawiłeś następującą właściwość; jeśli nie, powinno to służyć jako przypomnienie:
hibernate.jdbc.batch_size = xx
Gdzie xx to oczywiście pożądana wielkość partii.
