ORM-маппинг в Hibernate

@Override public int hashCode() { return Objects.hash(id); }  // ловушка

var fresh = new Author("Новый");
Set<Author> set = new HashSet<>(); set.add(fresh);
// до сохранения:    id=null, set.contains(fresh) = true
// после сохранения: id=6,    set.contains(fresh) = false

Проверьте себя

Пять вопросов из банка по этой подтеме. Всего их 21, остальные разбираются в тренажёре.

1. #orm_mapping1 / 5
   Что помечает аннотация @Entity на классе?

   A)Класс, экземпляры которого автоматически сериализуются в JSON при возврате из контроллера REST

   B)Класс — сущность, отображаемая на таблицу БД и управляемая ORM

   C)Класс, который Hibernate делает неизменяемым: его поля не получится менять после создания объекта

   D)Класс-конфигурацию Hibernate, где перечисляют настройки подключения к базе данных приложения

   показать ответ и разбор

   +B)Класс — сущность, отображаемая на таблицу БД и управляемая ORM

   // разбор: @Entity помечает POJO как ПЕРСИСТЕНТНУЮ СУЩНОСТЬ: Hibernate отображает её на таблицу (имя = класс или @Table), поля — на колонки (@Column), а один @Id обязателен как первичный ключ. Экземпляры такой сущности могут управляться контекстом персистентности (сохраняться, отслеживаться, загружаться). Требования: непустой конструктор, не final. Часто путают роль @Entity (модель хранения) с DTO (модель передачи) — их обычно разделяют, чтобы не тащить особенности БД/ленивые связи в API.

2. #orm_mapping2 / 5
   Чем стратегии @GeneratedValue IDENTITY и SEQUENCE отличаются на практике?

   A)IDENTITY генерирует UUID на стороне приложения, а SEQUENCE берёт целочисленный ключ из таблицы-счётчика

   B)Они эквивалентны: обе позволяют Hibernate группировать вставки в один пакетный запрос

   C)IDENTITY — авто-инкремент БД (мешает батч-вставке); SEQUENCE — последовательность (можно батчить)

   D)SEQUENCE работает только в MySQL, а IDENTITY — только в PostgreSQL, поэтому выбор зависит от СУБД

   показать ответ и разбор

   +C)IDENTITY — авто-инкремент БД (мешает батч-вставке); SEQUENCE — последовательность (можно батчить)

   // разбор: IDENTITY использует авто-инкрементный столбец БД: id становится известен только ПОСЛЕ выполнения INSERT, поэтому Hibernate вынужден вставлять строки по одной — БАТЧИНГ вставок отключается (проблема на массовых сохранениях). SEQUENCE берёт значения из последовательности БД ЗАРАНЕЕ (и может выбирать пачками через allocationSize), поэтому позволяет группировать INSERT'ы в батчи. Для PostgreSQL/Oracle SEQUENCE обычно предпочтительнее по производительности. AUTO отдаёт выбор провайдеру, TABLE — медленный переносимый вариант.

3. #orm_mapping3 / 5
   Что означает mappedBy в двунаправленной связи @OneToMany(mappedBy = "...")?

   A)Эта сторона владеет связью и хранит внешний ключ, а mappedBy задаёт имя колонки этого ключа в таблице

   B)MappedBy включает каскадное удаление: при удалении родителя все связанные дочерние строки удаляются

   C)MappedBy создаёт отдельную соединительную таблицу для хранения связи между двумя сущностями

   D)Эта сторона — обратная (inverse); владелец связи и внешний ключ — на другой стороне

   показать ответ и разбор

   +D)Эта сторона — обратная (inverse); владелец связи и внешний ключ — на другой стороне

   // разбор: В двунаправленной связи ВЛАДЕЛЕЦ (owning side) — та сторона, что содержит внешний ключ; обычно это @ManyToOne с @JoinColumn. Противоположная @OneToMany-сторона помечается mappedBy="поле" и является INVERSE (обратной): она лишь отражает связь, но НЕ управляет её сохранением в БД. Частая ошибка: изменить только inverse-коллекцию (parent.getChildren().add(child)) и удивляться, что FK не записался — синхронизировать нужно OWNING-сторону (child.setParent(parent)). Забытый mappedBy приводит к лишней join-таблице и дублирующим апдейтам.

4. #orm_mapping4 / 5
   Какой fetch-тип по умолчанию у @ManyToOne и @OneToMany?

   A)@ManyToOne — EAGER, @OneToMany — LAZY

   B)Обе связи по умолчанию EAGER: Hibernate сразу подгружает связанные сущности вместе с корнем

   C)Обе связи по умолчанию LAZY, поэтому связанные данные не грузятся, пока к ним явно не обратятся

   D)Тип загрузки по умолчанию не задан спецификацией и зависит только от настроек конкретной СУБД

   показать ответ и разбор

   +A)@ManyToOne — EAGER, @OneToMany — LAZY

   // разбор: По спецификации JPA умолчания: связи «к одному» (@ManyToOne, @OneToOne) — EAGER (подгружаются сразу вместе с сущностью), связи «ко многим» (@OneToMany, @ManyToMany) — LAZY (грузятся при первом обращении). На практике EAGER у @ManyToOne часто вреден (тянет лишние джойны, порождает N+1 и неожиданные запросы), поэтому многие ЯВНО ставят fetch=LAZY даже на to-one и подгружают что нужно через JOIN FETCH/@EntityGraph. Понимание дефолтов — ключ к контролю над генерируемыми запросами.

5. #orm_mapping5 / 5
   Как правильно смоделировать связь «многие-ко-многим» в Hibernate?

   A)Хранить в одной из сущностей список идентификаторов другой в виде строки через запятую в одной колонке

   B)@ManyToMany с соединительной таблицей (@JoinTable) или отдельной entity-связкой

   C)Продублировать все поля одной сущности внутри другой, чтобы избежать создания дополнительных таблиц

   D)Связь многие-ко-многим в реляционной БД не выходит — её приходится разбивать на уровне приложения вручную

   показать ответ и разбор

   +B)@ManyToMany с соединительной таблицей (@JoinTable) или отдельной entity-связкой

   // разбор: Многие-ко-многим в реляционной модели реализуется ПРОМЕЖУТОЧНОЙ (join) таблицей с двумя внешними ключами. В Hibernate это @ManyToMany с @JoinTable (указывают имя таблицы и колонки-ключи), одна сторона — владелец, другая — mappedBy. Важный нюанс: если у самой связи есть АТРИБУТЫ (дата, количество, роль), чистый @ManyToMany не подходит — join-таблицу превращают в отдельную @Entity с двумя @ManyToOne (и своим ключом). Также @ManyToMany требует аккуратности с каскадами и производительностью (легко получить лишние удаления/вставки всей коллекции).