Hibernate i Spring Data JPA od środka

Hibernate robi za ciebie bardzo dużo: tłumaczy obiekty na wiersze, pamięta, co zmieniłeś, i sam decyduje, kiedy wysłać SQL. Dlatego kod, który wygląda niewinnie, potrafi wysłać do bazy sto zapytań zamiast jednego. To kompendium nie jest listą adnotacji. Każdy rozdział pokazuje jeden mechanizm na klikalnej symulacji, a obok widzisz SQL, który ten mechanizm generuje, razem z licznikiem zapytań.

Kompendium ma poziomy. Rozdziały i bloki mają znaczek: L1 podstawy, L2 praktyk, L3 ekspert. Głębokość wybierasz przełącznikiem w lewym dolnym rogu; głębszy materiał chowa się, dopóki go nie zechcesz. Mapa poniżej przenosi cię do dowolnego rozdziału i odhacza to, co już przeczytałeś.

Na końcu są trzy rozdziały praktyczne: dobre praktyki, najczęstsze błędy i pytania na rozmowę rekrutacyjną, a po nich quiz i ściągawka.

Fakty sprawdzone w październiku 2026 z dokumentacją Hibernate ORM 7.4, specyfikacją Jakarta Persistence 3.2, dokumentacją Spring Data JPA 4.1, Spring Framework i Spring Boot. Szczegóły zmieniają się między wersjami, więc przy aktualizacji zajrzyj do przewodników migracji Hibernate.

Piszesz orderRepo.findById(7) i dostajesz zamówienie. Jedna linijka, ale pod spodem pracuje kilka warstw. Każda ma inną robotę, a większość nieporozumień z tego kursu bierze się z ich mylenia.

JDBC to najniższe piętro: standardowe API Javy do wysyłania SQL i czytania wierszy. Żadnych obiektów, tylko PreparedStatement i ResultSet.

JPA (Jakarta Persistence) to specyfikacja: zestaw interfejsów (EntityManager, EntityManagerFactory) i adnotacji (@Entity, @Id…). Sama nie robi nic. Potrzebuje implementacji.

Hibernate to ta implementacja, czyli ORM (Object-Relational Mapper): tłumaczy obiekty na wiersze i z powrotem, generuje SQL i woła JDBC. Jego natywny interfejs Session rozszerza EntityManager, więc obie nazwy opisują ten sam obiekt.

Spring Data JPA nie jest ORM-em. Generuje za ciebie repozytoria: piszesz interfejs, a Spring w czasie działania podstawia proxy, które deleguje do klasy SimpleJpaRepository. Ona z kolei woła zwykły EntityManager. Starter spring-boot-starter-data-jpa przynosi wszystkie trzy elementy: Hibernate, Spring Data JPA i Spring ORM.

Encja to klasa, której obiekty mają trwałą tożsamość (id) i odpowiadają wierszom w tabeli. Oznaczasz ją @Entity, a jej pole z kluczem głównym @Id.

JPA stawia encji kilka warunków. Klasa nie może być final (Hibernate tworzy podklasy-proxy), musi mieć konstruktor bez argumentów (JPA: public lub protected), a encją nie może być enum, record ani interfejs. Dodatkowe konstruktory możesz mieć dowolne.

@Entity
@Table(name = "orders")                 // "order" to słowo kluczowe SQL, więc zmieniamy nazwę
public class Order {
    @Id @GeneratedValue
    private Long id;

    @Enumerated(EnumType.STRING)
    private OrderStatus status;

    @Column(nullable = false, length = 100)
    private String customerEmail;

    private LocalDateTime createdAt;      // bez adnotacji też jest mapowane

    @Embedded
    private Address address;              // street + city lądują w tej samej tabeli

    protected Order() {}                  // dla Hibernate
}

Domyślnie każde pole jest mapowane na kolumnę. Tabela nazywa się jak encja (chyba że podasz @Table), a @Column bez atrybutów daje kolumnę nullable o długości 255. Spring Boot dodatkowo zamienia camelCase na snake_case małymi literami: customerEmail → customer_email.

@GeneratedValue bez strategii oznacza AUTO: Hibernate wybiera sekwencję, tabelę albo UUID zależnie od typu id i bazy. Strategiom i ich kosztom przyjrzysz się w rozdziale o zapisach wsadowych.

@Embeddable to „kawałek” encji bez własnej tożsamości, np. adres. Jego pola stają się kolumnami tabeli encji-właściciela. Może być zwykłą klasą albo rekordem Javy.

Obiekt encji zawsze jest w jednym z czterech stanów względem persistence context (kontekstu trwałości). Na razie myśl o nim jak o notesie EntityManager-a: lista obiektów, których zmiany Hibernate pilnuje. Szczegóły w następnym-następnym rozdziale.

persist i remove nie wysyłają SQL od razu. Planują INSERT lub DELETE na później, na flush (synchronizację z bazą, najczęściej tuż przed commitem). Metody update() nie ma wcale: zmiany w obiektach managed Hibernate wykrywa sam.

merge jest podchwytliwy. Nie „przyłącza” przekazanego obiektu. Kopiuje jego stan na egzemplarz managed (wczytany z bazy albo nowy) i zwraca tę kopię. Przekazany obiekt dalej jest detached.

Każdy EntityManager (czyli każda Session) ma własny persistence context. To mapa „typ + id → obiekt”: dla każdego wczytanego lub utrwalonego wiersza trzyma dokładnie jeden obiekt Javy. Hibernate nazywa ją też cache pierwszego poziomu.

Skutek pierwszy: drugie find(Order.class, 7) w tym samym kontekście nie idzie do bazy. Skutek drugi: dostajesz tę samą referencję, więc a == b daje true. Zmiana zrobiona w jednym miejscu kodu jest widoczna wszędzie w tej jednostce pracy.

Ile żyje kontekst? Zwykle tyle, co transakcja. W Springu wstrzyknięty EntityManager to współdzielone proxy, które deleguje do EntityManager-a bieżącej transakcji. Nowa transakcja to nowy, pusty kontekst. (Wyjątek: Open Session in View, który Spring Boot włącza domyślnie; patrz rozdział o OSIV.)

Wczytujesz zamówienie, robisz order.setStatus(SHIPPED) i… tyle. Nie wołasz save(). Po commicie w bazie i tak jest SHIPPED. To dirty checking.

Jak to działa? Przy wczytaniu encji Hibernate odkłada snapshot, czyli kopię jej stanu. Przy flush porównuje bieżące pola ze snapshotem i dla każdej zmienionej encji generuje UPDATE.

Kiedy następuje flush? W trybie domyślnym (AUTO) w trzech sytuacjach:

• przed commitem transakcji,
• przed zapytaniem, na którego wynik mogą wpłynąć niezapisane zmiany,
• gdy sam wołasz flush().

Zamówienie ma pozycje. W bazie to jeden klucz obcy: kolumna order_id w tabeli order_items. W Javie chcesz nawigować w obie strony, więc mapujesz relację dwukierunkową:

@Entity @Table(name = "order_items")
class OrderItem {
    @ManyToOne(fetch = FetchType.LAZY)
    @JoinColumn(name = "order_id")       // ta strona zapisuje FK
    private Order order;
}

@Entity @Table(name = "orders")
class Order {
    @OneToMany(mappedBy = "order", cascade = CascadeType.ALL, orphanRemoval = true)
    private List<OrderItem> items = new ArrayList<>();

    public void addItem(OrderItem i)    { items.add(i);    i.setOrder(this); }
    public void removeItem(OrderItem i) { items.remove(i); i.setOrder(null); }
}

Relacja dwukierunkowa ma stronę właścicielską (owning side) i stronę odwrotną (inverse). O tym, co trafi do bazy, decyduje tylko strona właścicielska. Przy one-to-many / many-to-one jest nią zawsze strona „wiele”, czyli @ManyToOne. Strona odwrotna wskazuje właściciela przez mappedBy. Zmiany zrobione tylko po stronie odwrotnej nigdy nie trafiają do bazy.

Stąd metody pomocnicze addItem/removeItem: ustawiają obie strony naraz, żeby obiekty w pamięci zgadzały się z tym, co pójdzie do bazy.

Cascade przenosi operację z rodzica na dzieci: persist(order) z PERSIST utrwala też pozycje. Do wyboru masz PERSIST, MERGE, REMOVE, REFRESH, DETACH i ALL (wszystkie naraz); domyślnie nic się nie kaskaduje. orphanRemoval idzie dalej: dziecko usunięte z kolekcji zostaje skasowane z bazy przy flush.

Piszesz interface OrderRepository extends JpaRepository<Order, Long> i… tyle. Nie ma klasy OrderRepositoryImpl. Mimo to wstrzykujesz orderRepo do serwisu i wołasz orderRepo.findById(42L). Kto to wykonuje?

Spring Data tworzy dla Twojego interfejsu proxy: obiekt, który implementuje ten interfejs i przekierowuje każde wywołanie w odpowiednie miejsce. W domyślnym trybie startu (spring.data.jpa.repositories.bootstrap-mode=default) proxy powstaje zachłannie, przy starcie kontekstu, jak każdy inny bean.

Gdzie trafia wywołanie? Metody CRUD (save, findById, delete…) wykonuje klasa SimpleJpaRepository, czyli domyślna implementacja JpaRepository. Ona z kolei woła EntityManager (persist, merge, find…), a ten należy do Hibernate'a. Metody, które dopisujesz sam (findByStatus), nie mają kodu w żadnej klasie: proxy buduje dla nich zapytanie z nazwy metody albo z adnotacji @Query (następny rozdział).

Hierarchia interfejsów jest krótka. Repository to znacznik: niczego nie deklaruje, tylko mówi „typ encji i typ id”. CrudRepository dodaje save, findById, findAll, count, delete, existsById. ListCrudRepository ma te same metody, ale zwraca List zamiast Iterable. PagingAndSortingRepository dodaje findAll(Sort) i findAll(Pageable). Na końcu JpaRepository łączy to wszystko i dorzuca rzeczy specyficzne dla JPA: flush(), saveAndFlush(), deleteAllInBatch(), getReferenceById().

I jeszcze transakcje. SimpleJpaRepository ma na poziomie klasy @Transactional(readOnly = true), więc odczyty CRUD biegną w transakcji tylko do odczytu. Metody zapisujące (save, delete…, flush) mają zwykłe @Transactional. Natomiast metody zadeklarowane przez Ciebie (findByStatus) domyślnie nie dostają żadnej konfiguracji transakcji.

Dopisujesz do repozytorium List<Order> findByStatusAndCreatedAtAfterOrderByIdDesc(OrderStatus s, Instant t). Bez ciała, bez SQL. Spring Data parsuje nazwę: odcina przedrostek find…By (to „podmiot” zapytania), a resztę czyta jako warunek („predykat”): właściwości encji połączone And/Or, operatory takie jak After, Between, Like, i na końcu opcjonalne OrderBy…Asc/Desc.

Każdy fragment nazwy musi trafić w właściwość encji (pole status, createdAt), nie w kolumnę tabeli. Z tego powstaje zapytanie JPQL, a z JPQL Hibernate robi SQL dla Twojej bazy. Zapytanie powstaje, gdy repozytorium jest tworzone (domyślnie przy starcie), więc literówka w nazwie wywali aplikację przy starcie, a nie na produkcji o 3 w nocy.

Domyślna strategia wyszukiwania zapytań to CREATE_IF_NOT_FOUND: najpierw szuka zapytania zadeklarowanego (@Query albo @NamedQuery o nazwie Order.findBy…), a dopiero gdy go nie ma, buduje je z nazwy metody. @Query na metodzie wygrywa z @NamedQuery.

—

Gdy nazwa robi się zbyt długa, piszesz zapytanie sam. @Query("select o from Order o where o.customerEmail = :email") to JPQL: operujesz na encjach i polach. Parametr nazwany wiążesz przez @Param("email"); jeśli kompilujesz z flagą -parameters, Spring odczyta nazwę parametru sam i @Param możesz pominąć.

Potrzebujesz czystego SQL-a (funkcja bazy, CTE)? @NativeQuery("SELECT * FROM orders WHERE customer_email = ?1") to w praktyce @Query(nativeQuery = true) z paroma dodatkowymi atrybutami. Tu piszesz nazwy tabel i kolumn, nie encji.

Zapytanie zmieniające dane (update, delete) w @Query oznaczasz @Modifying; bez tego Spring Data potraktuje je jak SELECT. @Modifying dotyczy tylko @Query: metody pochodne (deleteByStatus) go nie potrzebują.

save() nie jest operacją JPA. To decyzja Spring Data: jeśli encja jest nowa, woła entityManager.persist(…); jeśli nie, woła entityManager.merge(…). Cała zagadka sprowadza się do tego, skąd Spring Data wie, że encja jest nowa.

Najpierw Spring Data sprawdza, czy encja implementuje Persistable: jeśli tak, decyduje jej metoda isNew() i nic więcej nie jest brane pod uwagę. W przeciwnym razie działa domyślna reguła w dwóch krokach. Czy encja ma pole @Version typu obiektowego (Long, Integer)? Jeśli tak, encja jest nowa, gdy wersja to null. Jeśli pola wersji nie ma, Spring Data patrzy na @Id: null znaczy „nowa”. Dla id typu prymitywnego (long) nowa jest encja z id równym 0.

Dlaczego wersja prymitywna (long version) się nie liczy? Bo w JPA 0 to pierwsza zapisana wersja encji, więc zero nie odróżnia nowej encji od zapisanej.

Co robi merge? Kopiuje stan obiektu na egzemplarz zarządzany. Jeśli w persistence context nie ma encji o tym id, Hibernate najpierw ją ładuje z bazy (SELECT), a gdy wiersza nie ma, tworzy nową i robi INSERT. merge zwraca inny obiekt niż ten, który mu dałeś. Dlatego zawsze używaj wartości zwróconej przez save: order = repo.save(order);.

—

@MappedSuperclass
public abstract class AbstractEntity<ID> implements Persistable<ID> {
  @Transient
  private boolean isNew = true;

  @Override
  public boolean isNew() { return isNew; }

  @PostPersist
  @PostLoad
  void markNotNew() { this.isNew = false; }
}

Lista zamówień pokazuje numer i status. Metoda List<Order> findByCustomerEmail(…) pobierze jednak wszystkie kolumny, zrobi z nich encje i wrzuci je do persistence context (ze snapshotami do dirty checkingu). Projekcja to typ wyniku, który mówi Spring Data: „potrzebuję tylko tych pól”.

Projekcja interfejsowa zamknięta: interfejs, którego wszystkie gettery odpowiadają właściwościom encji, np. interface OrderSummary { Long getId(); OrderStatus getStatus(); }. Spring Data zna wszystkie potrzebne pola, więc może zawęzić SELECT. Wynik to proxy tego interfejsu, zbudowane (w JPA) zwykle z zapytania typu Tuple.

Projekcja otwarta: getter z @Value("#{target.id + ' / ' + target.status}"), czyli wyrażeniem SpEL. Wyrażenie może sięgnąć do dowolnego pola, więc Spring Data nie może zoptymalizować zapytania: ładuje całą encję.

Projekcja klasowa (DTO): zwykła klasa albo record OrderTotal(Long id, BigDecimal total). Pola do pobrania Spring Data ustala z nazw parametrów konstruktora; nie ma proxy i nie ma zagnieżdżonych projekcji. W JPA działa to przez constructor expression (select new com.example.OrderTotal(o.id, o.total) …).

Projekcja dynamiczna: <T> List<T> findByCustomerEmail(String email, Class<T> type). Typ wyniku wybierasz przy wywołaniu: repo.findByCustomerEmail(e, OrderSummary.class).

—

Do metody repozytorium dodajesz parametr Pageable, a w wywołaniu podajesz PageRequest.of(1, 20, Sort.by("id")). Numeracja stron zaczyna się od zera, więc to druga strona po 20 wierszy, posortowana po id. Samo sortowanie bez stron? Parametr Sort.

Typ wyniku decyduje, ile zapytań poleci. Page<Order> zna liczbę wszystkich elementów i stron, więc infrastruktura wysyła dodatkowe zapytanie COUNT. Slice<Order> wie tylko, czy jest następna porcja: pobiera rozmiar strony + 1 wiersz i bez COUNT sprawdza, czy ten „nadmiarowy” istnieje. List<Order> z Pageable też nie liczy.

Wszystkie trzy opierają się na OFFSET: „pomiń 980 wierszy, daj 20”. Baza i tak musi przejść te 980 wierszy, żeby je pominąć. Alternatywą jest przewijanie keyset (Window<Order> + ScrollPosition.keyset()): zamiast offsetu zapytanie dostaje warunek where id > ostatnie_widziane_id i może skoczyć prosto w indeks.

Ekran wyszukiwania ma cztery opcjonalne filtry: status, data od, minimalna kwota, fragment e-maila. Metoda pochodna na każdą kombinację to 16 metod. @Query z warunkami (:status is null or o.status = :status) szybko staje się nieczytelne. Potrzebujesz zapytania składanego w czasie działania.

Specification to predykat nad encją zbudowany Criteria API. Repozytorium rozszerzasz o JpaSpecificationExecutor<Order> i dostajesz findAll(spec), count(spec), findAll(spec, pageable). Od Spring Data JPA 4.0 masz też PredicateSpecification: prostszy interfejs (toPredicate(From, CriteriaBuilder)) niezależny od typu zapytania. Klasyczne Specification jest związane z SELECT-em; dla UPDATE i DELETE są UpdateSpecification i DeleteSpecification.

static PredicateSpecification<Order> hasStatus(OrderStatus s) {
  return (from, cb) -> cb.equal(from.get(Order_.status), s);
}
static PredicateSpecification<Order> totalAbove(BigDecimal min) {
  return (from, cb) -> cb.greaterThan(from.get(Order_.total), min);
}
// składanie:
orderRepo.findAll(hasStatus(PAID).and(totalAbove(new BigDecimal("100"))));

Specyfikacje składasz przez and, or, not i allOf(…). Specyfikacja, która nic nie ogranicza (Specification.unrestricted(), zwraca predykat null), jest przy składaniu pomijana. To wygodne przy filtrach opcjonalnych, ale ma konsekwencję, którą zobaczysz w figurze.

—

Query by Example (QBE) to lżejsza droga: wypełniasz „wzorcowy” obiekt i pytasz o podobne. Example.of(probe, matcher) i orderRepo.findAll(example) (JpaRepository dziedziczy QueryByExampleExecutor). Pola z wartością null są domyślnie pomijane, a pola prymitywne (int, double) zawsze biorą udział w warunku, chyba że je zignorujesz. ExampleMatcher zmienia te reguły: withIgnorePaths("total"), withStringMatcher(StringMatcher.CONTAINING), withIncludeNullValues().

Ograniczenia QBE: tylko równość dla nie-tekstów (żadnego „kwota > 100”), brak grup typu a = ?1 or (b = ?2 and c = ?3), brak dopasowań na kolekcjach i mapach. Do prostych formularzy „szukaj po polach” wystarczy; do zakresów i OR-ów potrzebujesz Specification.

Oznaczasz metodę serwisu @Transactional. Spring (w domyślnym trybie proxy) opakowuje bean w obiekt pośredniczący. Gdy ktoś z zewnątrz woła orderService.placeOrder(), najpierw trafia do proxy: ono otwiera transakcję, wywołuje Twoją metodę, a na końcu robi commit albo rollback. Sama adnotacja to tylko metadane; pracę wykonuje proxy.

Stąd najważniejsza reguła: przechwytywane są tylko wywołania z zewnątrz, przez proxy. Jeśli metoda checkout() w tej samej klasie woła this.placeOrder(), wywołanie omija proxy i żadna transakcja nie powstaje, mimo adnotacji. To self-invocation.

Domyślne ustawienia @Transactional: propagacja REQUIRED (dołącz do istniejącej transakcji albo zacznij nową), izolacja DEFAULT (taka jak domyślna w bazie), transakcja read-write, timeout taki jak w systemie transakcyjnym (albo brak).

I reguła, która zaskakuje najczęściej: rollback powodują tylko RuntimeException i Error. Wyjątek sprawdzany (IOException, Twój PaymentDeclinedException extends Exception) nie cofa transakcji: Spring zrobi commit i dopiero potem przepuści wyjątek dalej. Zmieniasz to przez rollbackFor = Exception.class (albo noRollbackFor w drugą stronę).

readOnly = true to wskazówka, nie zabezpieczenie: nie blokuje zapytań modyfikujących (choć niektóre bazy odrzucą INSERT/UPDATE w transakcji tylko do odczytu). Spring przekazuje ją sterownikowi JDBC, a przy Hibernate ustawia flush mode na MANUAL, więc Hibernate pomija dirty checking. Przy dużych grafach obiektów to odczuwalna oszczędność.

REQUIRED vs REQUIRES_NEW. Przy REQUIRED metoda wewnętrzna dołącza do transakcji zewnętrznej: to jedna fizyczna transakcja. Jeśli metoda wewnętrzna oznaczy ją jako „tylko do wycofania” (rzuci wyjątek, który zewnętrzna złapie i zignoruje), zewnętrzna przy commicie dostanie UnexpectedRollbackException. REQUIRES_NEW zawsze otwiera osobną fizyczną transakcję z własnym połączeniem: wewnętrzna commituje lub wycofuje się niezależnie. Koszt: drugie połączenie z puli na czas trwania obu, co przy małej puli i wielu wątkach grozi zakleszczeniem. Więcej w rozdziale o propagacji.

@Service
public class InvoiceService {
  public void issueAll(List<Long> ids) {
    for (Long id : ids) issue(id);
  }
  @Transactional
  public void issue(Long id) throws InvoiceException { … }
}

Twoje encje tworzą graf: zamówienie wskazuje klienta, klient ma adresy, adresy mają kraj… Gdyby Hibernate przy każdym find() ładował wszystko, do czego da się dojść po referencjach, ściągnąłbyś pół bazy. Musi więc gdzieś przeciąć graf.

Do wyboru są dwa tryby. EAGER („chciwie”) znaczy: załaduj od razu, razem z właścicielem. LAZY („leniwie”) znaczy: załaduj później, przy pierwszym dostępie.

Jeśli nic nie napiszesz, obowiązują domyślne ustawienia ze specyfikacji JPA. Łatwo je zapamiętać: „*ToOne” jest EAGER, „*ToMany” jest LAZY.

Jak Hibernate „czeka” z ładowaniem? Zamiast prawdziwego obiektu wkłada w pole proxy: obiekt, który udaje encję (albo kolekcję), ale nie ma jeszcze danych. Gdy wywołasz na nim metodę, Hibernate wysyła SELECT, wypełnia dane i dopiero wtedy przepuszcza wywołanie dalej.

Jest jeden wyjątek, który warto znać: getId() na proxy nie idzie do bazy, bo identyfikator proxy zna od początku.

Proxy działa tylko wtedy, gdy encja jest podpięta do otwartego persistence context (czyli sesji). Po zamknięciu sesji proxy nie ma już skąd wziąć danych i rzuca znienawidzony LazyInitializationException.

Rekomendacja z dokumentacji Hibernate brzmi tak: wszystkie asocjacje ustaw na fetch = LAZY. Dla @ManyToOne i @OneToOne musisz to napisać jawnie, bo domyślnie są EAGER. A potrzebne dane pobieraj z góry, na początku jednostki pracy, przez join fetch albo EntityGraph (zobaczysz je w następnym rozdziale).

@Entity @Table(name = "orders")
class Order {
  @Id Long id;
  String status;

  @ManyToOne(fetch = FetchType.LAZY)   // jawnie! domyślnie byłoby EAGER
  Customer customer;

  @OneToMany(mappedBy = "order")        // LAZY już domyślnie
  List<OrderItem> items = new ArrayList<>();
}

Dokumentacja Hibernate nazywa N+1 „bez wątpienia najczęstszą przyczyną” wolnego dostępu do danych w Javie. Mechanizm jest prosty: 1 zapytanie pobiera listę N wierszy, a potem N kolejnych zapytań dociąga powiązaną encję dla każdego wiersza z osobna.

List<Order> orders = orderRepository.findByStatus("NEW");   // 1 zapytanie
for (Order o : orders) {
  print(o.getId() + " " + o.getCustomer().getName());       // + 1 zapytanie na każde zamówienie
}

To nie jest błąd Hibernate. Ten sam problem ma ręcznie pisany kod JDBC w DAO. Tylko Ty wiesz z góry, jakich danych potrzebuje dany kawałek kodu, więc tylko Ty możesz go rozwiązać. Hibernate daje do tego narzędzia. Zobacz je w akcji:

Masz cztery narzędzia. Hibernate wymienia trzy strategie (outer join, batch, subselect) i dodaje: prawie zawsze używaj złączenia.

interface OrderRepository extends JpaRepository<Order, Long> {
  @Query("select o from Order o join fetch o.customer where o.status = :status")
  List<Order> findWithCustomerByStatus(String status);

  @EntityGraph(attributePaths = "customer")
  List<Order> findByStatus(String status);
}

Batch i subselect fetching są domyślnie wyłączone. W Spring Boot włączysz batch globalnie przez spring.jpa.properties.hibernate.default_batch_fetch_size=16 (liczba przykładowa). Dokumentacja jest tu szczera: batch fetching łagodzi N+1, ale go nie rozwiązuje. Rozwiązaniem jest pobranie asocjacji złączeniem.

Jak wykryć N+1? Włącz log SQL (spring.jpa.show-sql=true, domyślnie false, albo logger org.hibernate.SQL na DEBUG) i policz zapytania na jeden request. W testach integracyjnych warto to liczenie zautomatyzować (opinia: to najtańszy strażnik wydajności).

Złączenie do relacji *ToOne jest bezpieczne: jedno zamówienie to jeden wiersz. Złączenie do kolekcji mnoży wiersze. Zamówienie z trzema pozycjami wraca z bazy jako trzy wiersze.

Niespodzianka 1: duplikaty. Kiedyś trzeba było pisać select distinct. Od Hibernate 6 duplikaty wynikające z join fetch są usuwane automatycznie w pamięci, a dokumentacja wprost mówi, żeby nie używać do tego distinct.

Niespodzianka 2: paginacja. LIMIT 2 liczy wiersze, a nie zamówienia. Gdyby baza ucięła wynik po dwóch wierszach, dostałbyś jedno zamówienie z obciętą listą pozycji. Przed Hibernate 7.4 limity źle współpracowały z kolekcjami w join fetch. W 7.4 jest to naprawione na bazach, które wspierają limit i offset w podzapytaniu. Na bazie bez tej możliwości (dokumentacja podaje Sybase ASE) Hibernate pobiera wszystkie pasujące wiersze i stronicuje w pamięci.

Niespodzianka 3: dwie listy. Dwie kolekcje typu List (w żargonie Hibernate: bag, czyli kolekcja bez kolejności, mogąca mieć duplikaty) w jednym join fetch kończą się MultipleBagFetchException. Zamiana na Set usuwa wyjątek, ale nie problem: dwie kolekcje dołączone równolegle dają iloczyn kartezjański.

Każda podróż do bazy (round trip) kosztuje czas sieci. Gdy zapisujesz 100 encji, możesz wysłać 100 osobnych INSERT-ów albo kilka paczek JDBC (batch) po kilkadziesiąt. Hibernate potrafi to robić sam, wystarczy jedna właściwość:

# application.properties (Spring Boot)
spring.jpa.properties.hibernate.jdbc.batch_size=25
spring.jpa.properties.hibernate.order_inserts=true
spring.jpa.properties.hibernate.order_updates=true

Jest jeden haczyk i siedzi w @Id. Generator IDENTITY (kolumna auto-increment) zakłada, że identyfikator powstaje dopiero przy INSERT. Hibernate musi więc wykonać każdy INSERT osobno, żeby poznać id, i po cichu wyłącza batch insert dla takiej encji.

SEQUENCE działa inaczej: Hibernate pobiera z sekwencji cały blok identyfikatorów (allocationSize, w JPA domyślnie 50) i przydziela je w pamięci. Do bazy wraca dopiero, gdy blok się wyczerpie. Tym zajmuje się optymalizator, domyślnie pooled. Bez jawnej nazwy sekwencji Hibernate przyjmie nazwę tabeli z sufiksem _seq.

UUID (GenerationType.UUID, albo samo @GeneratedValue UUID id, bo AUTO wybiera wtedy UUID po typie pola) powstaje w kodzie Javy, więc nie wymaga żadnej podróży do bazy. Masowe zmiany wielu wierszy naraz najlepiej zrobić jednym update/delete w HQL zamiast ładować i zmieniać encje po kolei. A żeby sprawdzić, czy batching w ogóle działa, włącz logowanie TRACE dla kategorii org.hibernate.orm.jdbc.batch.

Uruchamiasz aplikację webową na Spring Boot i w logu widzisz ostrzeżenie:

WARN … spring.jpa.open-in-view is enabled by default. Therefore, database queries may be
performed during view rendering. Explicitly configure spring.jpa.open-in-view to disable this warning

Za tym stoi wzorzec Open EntityManager in View (w świecie Hibernate: Open Session in View, OSIV). W aplikacji webowej Spring Boot domyślnie rejestruje OpenEntityManagerInViewInterceptor (spring.jpa.open-in-view=true). Interceptor wiąże EntityManager z wątkiem na cały czas obsługi requestu, a nie tylko na czas transakcji w serwisie.

Efekt: LazyInitializationException „znika”. Kontroler, szablon albo Jackson serializujący encję do JSON-a mogą dotknąć leniwej asocjacji, a ta po cichu wyśle SELECT. To dokładnie te zapytania „podczas renderowania widoku”, przed którymi ostrzega log.

Co w tym złego? Po pierwsze, N+1 przenosi się do warstwy, w której nikt go nie szuka: do serializacji odpowiedzi. Po drugie, te zapytania lecą już po zakończeniu transakcji z serwisu. Po trzecie (opinia, ale powszechna): EntityManager żyjący przez cały request może dłużej przytrzymywać zasoby, w tym połączenie z puli, co pod obciążeniem zjada pulę połączeń.

Typowa decyzja w nowych projektach to spring.jpa.open-in-view=false, a w serwisie pobieranie wszystkiego, czego potrzebuje odpowiedź: join fetch, @EntityGraph albo od razu projekcja do DTO.

Persistence context to cache pierwszego poziomu: żyje tyle, co jedna sesja. Cache drugiego poziomu (L2) jest dzielony między sesjami, więc druga sesja może dostać encję bez SQL-a.

Brzmi jak darmowa wydajność, ale nie jest darmowa. Zmiany w cache i w bazie nie są atomowe (nie ma między nimi dwufazowego commitu), więc L2 osłabia gwarancje ACID. Dlatego w Hibernate caching jest domyślnie wyłączony, a każdą encję musisz oznaczyć jawnie.

@Entity
@Cache(usage = CacheConcurrencyStrategy.READ_WRITE)   // org.hibernate.annotations.Cache
class Customer { … }

# application.properties
spring.jpa.properties.hibernate.cache.region.factory_class=jcache
# + implementacja JCache na classpath (np. EHCache albo Caffeine)

Hibernate nie ma własnej implementacji cache, więc potrzebny jest zewnętrzny dostawca: najczęściej JCache (EHCache, Caffeine) albo Infinispan. Cache dzieli się na regiony, po jednym na hierarchię encji i na rolę kolekcji. Domyślna nazwa regionu to nazwa klasy albo roli kolekcji. Polityki wygasania i rozmiaru konfigurujesz u dostawcy, nie w Hibernate. @Cache stawiasz na klasie bazowej hierarchii dziedziczenia; na podklasie to błąd.

L2 obsługuje tylko wyszukiwanie po id: find() i rozwiązywanie asocjacji po kluczu. Zapytanie HQL/JPQL i tak idzie do bazy. Na to jest osobny query cache: hibernate.cache.use_query_cache=true plus setCacheable(true) na zapytaniu. Wyniki lądują w regionie default-query-results-region. Ważność sprawdza się przez logiczne znaczniki czasu ostatniej zmiany każdej tabeli, trzymane w regionie default-update-timestamps-region; ten region nie powinien nigdy wygasać. Dokumentacja Hibernate pisze, że cache’owanie wyników zapytań „rzadko” się opłaca.

Ala otwiera zamówienie #101, żeby oznaczyć je jako opłacone. W tej samej sekundzie Bartek otwiera to samo zamówienie, żeby poprawić literówkę w e-mailu klienta. Oboje czytają ten sam wiersz, oboje coś zmieniają, oboje zapisują.

Domyślnie Hibernate w UPDATE ustawia wszystkie kolumny encji poza identyfikatorem, nie tylko te zmienione. Bartek zapisuje więc także stary status NEW, który przeczytał przed zmianą Ali. Zmiana Ali znika bez śladu. To jest lost update, czyli zgubiona aktualizacja: nikt nie dostał błędu, a dane są złe.

Lekarstwo to jedno pole z adnotacją @Version. Hibernate nadaje mu wartość przy persist (dla liczby: 0) i zwiększa je przy każdym zapisie encji. Każdy UPDATE i DELETE dostaje w WHERE warunek „i wersja jest nadal taka, jaką przeczytałem”.

@Entity
@Table(name = "orders")
public class Order {
    @Id @GeneratedValue
    private Long id;

    @Version
    private Long version;      // Hibernate sam ustawia i podbija; Ty tylko czytasz

    @Enumerated(EnumType.STRING)
    private OrderStatus status;
    private String customerEmail;
    // ...
}

Jeśli UPDATE … WHERE id=? AND version=? zmieni zero wierszy, Hibernate wie, że ktoś inny zapisał encję w międzyczasie. Rzuca OptimisticLockException i transakcja idzie do wycofania. Nazwa „optymistyczne” bierze się stąd, że nic nie jest blokowane: zakładasz, że konfliktu nie będzie, i tylko sprawdzasz to przy zapisie.

W Springu nie złapiesz gołego OptimisticLockException. Warstwa repozytoriów tłumaczy wyjątki dostawcy na hierarchię Springa, więc dostajesz ObjectOptimisticLockingFailureException (przy JPA czasem jej podklasę JpaOptimisticLockingFailureException). Obie dziedziczą po OptimisticLockingFailureException i ten typ warto łapać.

Co zrobić z konfliktem? Masz dwie uczciwe odpowiedzi. Albo pokazujesz użytkownikowi „ktoś zmienił to zamówienie, odśwież i spróbuj ponownie”, albo ponawiasz całą transakcję: wczytujesz świeży stan, nakładasz zmianę jeszcze raz i zapisujesz. Ponawiać trzeba od nowa, z nową transakcją i nowym persistence context, bo po wyjątku stary kontekst jest „zatruty”.

@Service
class OrderEmailFixer {                       // osobny bean: ponawia z zewnątrz
    private final OrderService service;       // tu jest @Transactional fixEmail(...)
    OrderEmailFixer(OrderService service) { this.service = service; }

    @Retryable(includes = OptimisticLockingFailureException.class, maxRetries = 3)
    public void fixEmail(long orderId, String email) {
        service.fixEmail(orderId, email);     // każda próba = nowa transakcja
    }
}   // @Retryable (Spring Framework 7) działa po włączeniu @EnableResilientMethods

Optymizm ma swoją cenę: przegrany konflikt to wyjątek i ponowienie. Jeśli konflikty są częste, a powtarzanie pracy drogie (na przykład dwa procesy wysyłki biorą to samo zamówienie), wolisz, żeby druga transakcja po prostu poczekała.

Do tego służy blokada pesymistyczna. Hibernate prosi bazę o zablokowanie wiersza już przy odczycie, zwykle przez SELECT … FOR UPDATE. Blokada trwa do końca transakcji (commit albo rollback). Każda inna transakcja, która chce ten sam wiersz zablokować, czeka.

public interface OrderRepository extends JpaRepository<Order, Long> {

    @Lock(LockModeType.PESSIMISTIC_WRITE)
    @Query("select o from Order o where o.id = :id")
    Optional<Order> findForShipping(Long id);
}

@Lock ze Spring Data działa na metodach zapytań: tych z @Query i tych wyprowadzanych z nazwy. Możesz też przedeklarować metodę CRUD (np. findById) w interfejsie i dodać jej @Lock. Bez otwartej transakcji blokada nie ma sensu, bo zniknęłaby od razu po zapytaniu, więc wołaj takie metody w @Transactional.

Timeout. Domyślnie czekanie na blokadę trwa tyle, ile pozwala baza. Limit ustawisz wskazówką jakarta.persistence.lock.timeout w milisekundach, w Spring Data przez @QueryHints. Dialekt tłumaczy ją na składnię bazy, na przykład w Oracle na FOR UPDATE wait 2. Gdy sterownik tego nie obsługuje, Hibernate wskazówkę ignoruje.

@Lock(LockModeType.PESSIMISTIC_WRITE)
@QueryHints(@QueryHint(name = "jakarta.persistence.lock.timeout", value = "2000"))
@Query("select o from Order o where o.id = :id")
Optional<Order> findForShipping(Long id);

Gdy blokady nie da się zdobyć, JPA rozróżnia dwa przypadki. Jeśli baza wycofała tylko jedno polecenie, leci LockTimeoutException i transakcja nie jest oznaczana do wycofania. Jeśli baza wycofała całą transakcję, leci PessimisticLockException i transakcja jest oznaczona do wycofania. Spring tłumaczy je odpowiednio na CannotAcquireLockException i PessimisticLockingFailureException. Dokumentacja Springa radzi łapać ogólne PessimisticLockingFailureException, nie konkretne podklasy.

Zamówienie można opłacić kartą albo przelewem. W Javie naturalnie robisz klasę bazową Payment (kwota, zamówienie) i dwie podklasy: CardPayment (ostatnie 4 cyfry karty) i BankTransfer (IBAN). Baza relacyjna nie zna dziedziczenia, więc ktoś musi zdecydować, jak tę hierarchię rozłożyć na tabele.

Najpierw rozróżnij dwie rzeczy. @MappedSuperclass to tylko wspólne pola do skopiowania w podklasy (typowo id, version, daty audytu). Taka klasa nie jest encją: nie ma własnej tabeli i nie zapytasz o nią polimorficznie. @Entity na klasie bazowej plus @Inheritance to prawdziwa hierarchia encji: możesz napisać select p from Payment p i dostać mieszankę kart i przelewów.

@Entity                                   // brak @Inheritance = SINGLE_TABLE
@DiscriminatorColumn(name = "dtype")      // domyślnie i tak "DTYPE", typ STRING
public abstract class Payment {
    @Id @GeneratedValue Long id;
    BigDecimal amount;
    @ManyToOne(fetch = FetchType.LAZY) Order order;
}
@Entity class CardPayment extends Payment { String cardLast4; }
@Entity class BankTransfer extends Payment { String iban; }

Wewnątrz jednej sesji Hibernate gwarantuje, że ten sam wiersz to ta sama instancja: dwa find(Order.class, 101L) zwrócą ten sam obiekt. Domyślne equals z Object (porównanie referencji) wystarcza. Kłopot zaczyna się, gdy mieszasz obiekty z różnych sesji albo wkładasz nowe encje do HashSet.

HashSet trzyma obiekt w „kubełku” wyznaczonym przez hashCode() w chwili wstawienia. Kontrakt Set mówi: hashCode obiektu nie może się zmienić, dopóki obiekt jest w zbiorze. A jeśli hashCode liczysz z generowanego id, to zmienia się on dokładnie przy persist: przed nim id jest null, po nim liczbą.

Dokumentacja Hibernate daje kilka zasad. Nie wkładaj do hashCode pól zmiennych. Generowane id da się użyć, ale musisz uważać, by nie wkładać encji do zbiorów przed nadaniem id. Najbezpieczniej oprzeć equals/hashCode na kluczu naturalnym: niezmiennym polu, które w świecie biznesu jednoznacznie wskazuje rzecz (SKU produktu, ISBN książki). Hibernate oznacza go adnotacją @NaturalId i sam generuje na tych kolumnach ograniczenie UNIQUE.

@Entity
public class Product {
    @Id @GeneratedValue Long id;
    @NaturalId String sku;               // domyślnie niezmienny (mutable = false)
    String name;

    @Override public boolean equals(Object o) {
        return o instanceof Product p           // instanceof, nie getClass(): o może być proxy
            && sku.equals(p.getSku());          // przez getter, nie pole: proxy ma puste pola
    }
    @Override public int hashCode() { return sku.hashCode(); }
}

OrderService.placeOrder() ma @Transactional i w środku woła AuditLog.record(), który też ma @Transactional. Czy to jedna transakcja, czy dwie? Odpowiada atrybut propagation metody wewnętrznej. Domyślnie to REQUIRED.

Spring rozróżnia transakcję fizyczną (prawdziwa transakcja na połączeniu z bazą) i logiczną (zakres jednej metody z @Transactional). Przy REQUIRED kilka zakresów logicznych dzieli jedną fizyczną: każdy może ją oznaczyć jako „tylko do wycofania” (rollback-only), ale commit jest jeden.

Izolacja (isolation) mówi, jakie anomalie współbieżności baza dopuszcza: READ_UNCOMMITTED, READ_COMMITTED, REPEATABLE_READ, SERIALIZABLE. Domyślne DEFAULT znaczy „to, co ustawia baza”, a to zależy od produktu. HibernateJpaDialect ustawia poziom izolacji na połączeniu JDBC, więc z Hibernate własny poziom per transakcja działa. Pamiętaj, że izolacja, timeout i readOnly liczą się tylko tam, gdzie transakcja fizyczna startuje.

readOnly = true z Hibernate: HibernateJpaDialect przestawia sesję na FlushMode.MANUAL (brak automatycznego flush, więc i dirty checkingu przy commicie) i ustawia sesję w tryb tylko do odczytu, a połączeniu JDBC przekazuje flagę read-only.

Persistence context to wygoda: pamięta każdą encję, którą dotknąłeś, i przy flush porównuje jej stan z migawką. Przy 20 encjach na request to nic nie kosztuje. Przy nocnym imporcie 100 000 wierszy ta sama wygoda zjada pamięć: każda zapisana encja zostaje w kontekście do końca transakcji, aż do OutOfMemoryError.

Klasyczne lekarstwo to flush i clear co N encji: wysyłasz zaległe INSERT-y i opróżniasz kontekst. Dobierz N do hibernate.jdbc.batch_size (więcej o batchach w rozdziale o zapisach wsadowych).

@Transactional
public void importOrders(List<OrderDto> rows) {
    for (int i = 0; i < rows.size(); i++) {
        em.persist(toOrder(rows.get(i)));
        if (i > 0 && i % 50 == 0) {   // 50 = hibernate.jdbc.batch_size
            em.flush();                 // wyślij zaległe INSERT-y
            em.clear();                 // zapomnij zapisane encje
        }
    }
}

StatelessSession to drugie API Hibernate, bez persistence context. Nie ma w nim cache pierwszego poziomu, odroczonego zapisu (write-behind), automatycznego dirty checkingu ani kaskad. insert, update, delete idą do bazy od razu i jawnie; leniwą asocjację dociągasz wprost przez fetch(). W Hibernate 7 hibernate.jdbc.batch_size nie działa na sesję bezstanową; zamiast tego użyj insertMultiple(List).

try (StatelessSession ss = entityManagerFactory.unwrap(SessionFactory.class).openStatelessSession()) {
    Transaction tx = ss.beginTransaction();
    for (List<Order> chunk : chunks(orders, 50)) {
        ss.insertMultiple(chunk);       // jawny batch
    }
    tx.commit();
}

Przy czytaniu dużych zbiorów działa to samo: nie ładuj wszystkiego do List. Spring Data pozwala zwrócić Stream<Order> z metody repozytorium; strumień trzyma zasoby bazy, więc zamknij go (try-with-resources). Natywnie Hibernate ma ScrollableResults (kursor po stronie serwera). Przy obu nadal czyść kontekst co N encji, bo odczytane encje też w nim zostają.

Dwa pytania z każdego audytu: kto i kiedy ostatnio zmienił zamówienie oraz jak wyglądało w zeszły wtorek. Na pierwsze odpowiada Spring Data JPA Auditing (kolumny w tej samej tabeli). Na drugie Hibernate Envers (osobna tabela historii).

@Configuration
@EnableJpaAuditing                         // bez tego adnotacje poniżej nic nie robią
class AuditConfig {
    @Bean AuditorAware<String> auditor() {  // „kto”: np. z Spring Security
        return () -> Optional.ofNullable(SecurityContextHolder.getContext().getAuthentication())
                             .map(Authentication::getName);
    }
}

@MappedSuperclass
@EntityListeners(AuditingEntityListener.class)
public abstract class Auditable {
    @CreatedDate      Instant createdAt;
    @CreatedBy        String  createdBy;
    @LastModifiedDate Instant lastModifiedAt;
    @LastModifiedBy   String  lastModifiedBy;
}

@Entity @Audited @Table(name = "orders")   // @Audited = Envers
public class Order extends Auditable { /* ... */ }

AuditingEntityListener to listener JPA, który przed zapisem wypełnia pola z adnotacjami. Daty bierze z DateTimeProvider (domyślnie bieżący czas), a „kto” z Twojego beana AuditorAware. Jeśli śledzisz tylko daty, AuditorAware nie jest potrzebny. Atrybut modifyOnCreate w @EnableJpaAuditing ma domyślnie true: przy tworzeniu wypełniane są też pola „last modified”.

Envers wymaga jarki hibernate-envers na classpath i @Audited na encji; listenery rejestrują się same. Dla każdej audytowanej encji powstaje tabela z sufiksem _AUD (tu orders_AUD) z kolumnami encji plus REV (numer rewizji) i REVTYPE (0 = ADD, 1 = MOD, 2 = DEL). Do tego globalna tabela REVINFO: jeden wiersz na każdy commit, który zmienił dane audytowane.

Przez dwadzieścia sześć rozdziałów uczyłeś się, jak działa JPA. Czas na niewygodne pytanie: czy w Twoim projekcie w ogóle jej potrzebujesz?

JPA robi za Ciebie bardzo dużo. Śledzi zmiany encji (dirty checking z rozdziału o flush), dociąga dane leniwie (lazy loading), trzyma persistence context i pozwala zmapować prawie każdy układ obiektów na prawie każdy schemat. Twórcy Spring Data JDBC piszą wprost, że to świetne, ale że często trudno zrozumieć, dlaczego JPA zrobiła to, co zrobiła.

W ekosystemie Springa masz cztery popularne drogi do relacyjnej bazy. Różnią się tym, ile „magii” dostajesz i ile SQL-a piszesz sam.

Zwróć uwagę na wynik dla Spring Data JDBC. Dokumentacja opisuje to wprost: jeśli korzeń agregatu nie jest nowy, wszystkie encje, do których się odwołuje, są usuwane, korzeń jest aktualizowany, a encje podrzędne wstawiane od nowa. To cena prostoty: brak dirty checkingu oznacza, że framework nie wie, która pozycja się zmieniła.

To nie jest wybór „na zawsze i dla całej aplikacji”. JpaTransactionManager pozwala zwykłemu kodowi JDBC korzystającemu z tego samego DataSource uczestniczyć w transakcji JPA. Encje do logiki domenowej, JdbcClient albo jOOQ do raportu: to częsty i rozsądny układ.

Każdy rozdział tej strony kończył się kilkoma zasadami. Tu masz je zebrane w jedną listę, pogrupowaną według tego, czego dotyczą: mapowania, pobierania danych, transakcji, zapisów oraz schematu i testów.

Przejdź listę z otwartym kodem swojego projektu. Każdy punkt prowadzi do rozdziału, który wyjaśnia, dlaczego warto. Punkty dla zaawansowanych pojawiają się dopiero przy większej głębokości strony.

Kilka punktów zasługuje na słowo komentarza, bo nie miały w tej stronie osobnego rozdziału.

Schemat. spring.jpa.hibernate.ddl-auto przyjmuje wartości none, validate, update, create i create-drop. Spring Boot sam wybiera create-drop tylko dla bazy wbudowanej (H2, HSQLDB, Derby), gdy nie wykryje Flyway ani Liquibase; w pozostałych przypadkach domyślnie jest none. Dokumentacja Hibernate zaznacza, że generowanie schematu z mapowań jest przydatne do testów i prototypów, ale na produkcji schematem lepiej zarządzać przyrostowymi skryptami migracji. Spring Boot dodaje: jeśli używasz Flyway lub Liquibase, niech tylko one tworzą schemat.

Testy. @DataJpaTest uruchamia tylko komponenty JPA. Domyślnie każdy test jest transakcyjny i na końcu wycofywany, a zapytania SQL są logowane (spring.jpa.show-sql=true, można to wyłączyć atrybutem showSql). Do przygotowania danych możesz wstrzyknąć TestEntityManager.

Liczenie zapytań. Ustaw hibernate.generate_statistics=true, a obiekt Statistics z sessionFactory.getStatistics() powie Ci m.in., ile instrukcji przygotowano (getPrepareStatementCount()). Asercja „ta metoda wysyła najwyżej 2 zapytania” to najtańszy strażnik przed powrotem N+1.

@DataJpaTest(properties = "spring.jpa.properties.hibernate.generate_statistics=true")
class OrderRepositoryTest {
  @Autowired OrderRepository orders;
  @Autowired EntityManagerFactory emf;

  @Test
  void listWithCustomersUsesOneQuery() {
    Statistics stats = emf.unwrap(SessionFactory.class).getStatistics();
    stats.clear();
    orders.findAllWithCustomer();          // join fetch
    assertThat(stats.getPrepareStatementCount()).isEqualTo(1);
  }
}

Większość problemów z JPA w prawdziwych projektach to te same kilkanaście błędów. Każdy ma charakterystyczny objaw, który widzisz w logu albo w zgłoszeniu od użytkownika. Kiedy nauczysz się go rozpoznawać, diagnoza zajmuje minutę zamiast dnia.

Kliknij kartę, żeby zobaczyć przyczynę, poprawkę i SQL przed oraz po. Przycisk 💥 „wstrzykuje” anty-wzorzec z zaznaczonej karty. Zacznij od N+1 i obserwuj licznik.

// przed
List<Order> findByStatus(Status s);
// po
@EntityGraph(attributePaths = "customer")
List<Order> findByStatus(Status s);

// przed: Order z serwisu, w kontrolerze
order.getItems().size();   // 💥 sesja zamknięta
// po: serwis zwraca DTO zbudowane w transakcji
return new OrderView(o.getId(), o.getItems().size());

// przed
@Data @Entity class Order { @OneToMany(mappedBy = "order") List<OrderItem> items; }
// po
@Getter @Setter @Entity class Order {
  @ToString.Exclude @OneToMany(mappedBy = "order") List<OrderItem> items; }

// przed
@ManyToOne(cascade = CascadeType.ALL) Customer customer;
// po
@ManyToOne(fetch = FetchType.LAZY) Customer customer;

// przed (w OrderService)
public void place(Order o) { ...; this.audit(o); }
// po
public void place(Order o) { ...; auditService.audit(o); }

Poniżej masz pytania, które często padają na rozmowach o Hibernate i Spring Data JPA. Każda fiszka ma poziom: L1 (podstawy), L2 (praktyk) i L3 (ekspert). Najpierw odpowiedz na głos, potem odkryj odpowiedź.

Odpowiedzi są celowo krótkie, tyle, ile zmieścisz w minucie rozmowy. Link przy każdej prowadzi do rozdziału z pełnym wyjaśnieniem i animacją.

Ściągawka