ORM

Object Relational Mapping (ORM) — это концепция/процесс преобразования данных из объектно-ориентированного языка в реляционные БД и наоборот.

Например, в Java это делается с помощью рефлексии и JDBC.

JDBC (Java DataBase Connectivity) — API для работы с реляционными (зависимыми) БД.

Платформенно независимый промышленный стандарт взаимодействия Java-приложений с различными СУБД, реализованный в виде пакета java.sql, входящего в состав Java SE.

Предоставляет методы для получения и обновления данных. Не зависит от конкретного типа базы. Библиотека, которая входит в стандартную библиотеу, содержит: набор классов и интерфейсов для работы с БД (для нас разработчиков api) + интерфейсы баз данных.

JDBC реализует механизмы работы подключений к базе данных, создания запросов и обработки результатов.

JDBC Архитектура

JPA

Java Persistence API (JPA) - это спецификация (стандарт, технология), обеспечивающая объектно-реляционное отображение простых JAVA-объектов (Plain Old Java Object - POJO) и предоставляющая универсальный API для сохранения, получения и управления такими объектами.

Сам JPA не умеет ни сохранять, ни управлять объектами, JPA только определяет правила игры: как должен действовать каждый провайдер (Hibernate, EclipseLink, OJB, Torque и т.д.), реализующий стандарт JPA. Для этого JPA определяет интерфейсы, которые должны быть реализованы провайдерами. Также JPA определяет правила, как должны описываться метаданные отображения и как должны работать провайдеры. Каждый провайдер обязан реализовывать всё из JPA, определяя стандартное получение, сохранение и управление объектами. Помимо этого, провайдеры могут добавлять свои личные классы и интерфейсы, расширяя функционал JPA.

JPA

HIBERNATE

Hibernate - это провайдер, реализующий спецификацию JPA. Hibernate полностью реализует JPA плюс добавляет функционал в виде своих классов и интерфейсов, расширяя свои возможности по работе с сущностями и БД.

EntityManager

Это интерфейс JPA, используемый для взаимодействия с персистентным контекстом.

EntityManager описывает API для всех основных операций над Entity, а также для получения данных и других сущностей JPA.

По сути - главный API для работы с JPA.

Персистентный контекст - это набор экземпляров сущностей, загруженных из БД или только что созданных.

Персистентный контекст является своего рода кэшем данных в рамках транзакции - это и есть кэш первого уровня.

Внутри контекста персистентности происходит управление экземплярами сущностей и их жизненным циклом.

EntityManager автоматически сохраняет в БД все изменения, сделанные в его персистентном контексте, в момент коммита транзакции, либо при явном вызове метода flush().

Один или несколько EntityManager образуют или могут образовать persistence context.

Если проводить аналогию с обычным JDBC, то EntityManagerFactory будет аналогом DataSource, а EntityManager аналогом Connection.

Создание EntityManagerFactory довольно дорогая операция, поэтому обычно её создают один раз и на всё приложение. А чаще всего не создают сами, а делегируют это фреймворку, такому как Spring, например.

Интерфейс Session из Hibernate представлен в JPA как раз интерфейсом EntityManager.

Основные функции EntityManager

1. Операции над Entity:

   • persist (добавление Entity под управление JPA)
   • merge (изменение)
   • remove (удаление)
   • refresh (обновление данных)
   • detach (удаление из-под управления контекста персистентности)
   • lock (блокирование Entity от изменений в других thread)

2. Получение данных:

   • find (поиск и получение Entity)
   • createQuery
   • createNamedQuery
   • createNativeQuery
   • contains
   • createNamedStoredProcedureQuery
   • createStoredProcedureQuery

3. Получение других сущностей JPA

   • getTransaction
   • getEntityManagerFactory,
   • getCriteriaBuilder
   • getMetamodel
   • getDelegate

4. Работа с EntityGraph

   • createEntityGraph
   • getEntityGraph

5. Общие операции

   • close
   • isOpen
   • getProperties
   • setProperty
   • clear

Объекты EntityManager не являются потокобезопасными.

Это означает, что каждый поток должен получить свой экземпляр EntityManager, поработать с ним и закрыть его в конце.

Entity

Сущность (entity) - это объект персистентной области.

Как правило, сущность представляет таблицу в реляционной базе данных, и каждый экземпляр сущности соответствует строке в этой таблице.

Основным программным представлением сущности является класс сущности.

Класс сущности может использовать другие классы, которые служат вспомогательными классами или используются для представления состояния сущности (например embedded).

Персистентное состояние сущности представлено персистентными полями или персистентными свойствами.

Персистентное поле - поле сущности, которое отражается в БД в виде столбца таблицы.

Персистентное свойство - это методы, которые аннотированы вместо полей для доступа провайдера к ним (полям).

Эти поля или свойства используют аннотации объектно-реляционного сопоставления (маппинга) для сопоставления сущностей и отношений между ними с реляционными данными в хранилище данных.

Примеры аннотаций: @OneToOne, @OneToMany, @ManyToOne, @ManyToMany.

Есть два вида доступа к состоянию сущности:

• Доступ по полю, когда аннотации стоят над полями.

  В этом случае провайдер, например, Hibernate, обращается к полям класса напрямую, используя Reflection.

• Доступ по свойству, когда аннотации стоят над методами-геттерами.

  В этом случае провайдер, например, Hibernate, обращается к полям класса через методы.

В JPA принято называть эти персистентные поля и свойства атрибутами класса-сущности.

Требования к Entity классу в JPA

• Entity класс должен быть помечен аннотацией @Entity или описан в XML файле конфигурации JPA.
• Entity класс должен содержать public или protected конструктор без аргументов (он также может иметь конструкторы с аргументами).
• Entity класс должен быть классом верхнего уровня (top-level class).
• Перечисление (enum) или интерфейс (interface) не могут быть определены как сущность.

• Entity класс не может быть финальным классом (final class).

  Entity класс не может содержать финальные поля или методы, если они участвуют в маппинге (persistent final methods or persistent final instance variables).

• Если объект Entity класса будет передаваться по значению как отделённый от контекста персистентности объект (detached object), например через удаленный интерфейс (through a remote interface), то он также должен реализовывать интерфейс Serializable (чтобы объекты, которые достаются из базы, могли сохраняться в кэше).

• Как обычный так и абстрактный класс может быть Entity.

  Entities могут наследоваться как от не Entity классов, так и от Entity классов.

  А не Entity классы могут наследоваться от Entity классов.

• Поля Entity класса должны быть объявлены private, protected или package-private, быть напрямую доступными только методам самого Entity класса и не должны быть напрямую доступны другим классам, использующим этот Entity.

  Другие классы должны обращаться только к специальным методам Entity класса, предоставляющим доступ к этим полям (getter/setter-методам или другим методам бизнес-логики в Entity классе).

• Entity класс должен содержать первичный ключ, то есть атрибут или группу атрибутов, которые уникально определяют запись этого Entity класса в базе данных.

Требования к Entity классу в Hibernate

Hibernate не так строг в своих требованиях. Вот отличия от требований JPA:

1. Класс сущности должен иметь конструктор без аргументов, который может быть не только public или protected, но и package visibility (default).
2. Класс сущности необязательно должен быть классом верхнего уровня.

3. Технически Hibernate может сохранять финальные классы или классы с финальными методами (getter / setter).

   Однако, как правило, это не очень хорошая идея, так как это лишит Hibernate возможности генерировать прокси для отложенной загрузки сущности.

4. Hibernate не запрещает разработчику приложения открывать прямой доступ к переменным экземпляра и ссылаться на них извне класса сущности.

   Однако обоснованность такого подхода спорна.

Может ли Entity класс наследоваться от не Entity классов (non-entity classes)?

Да, сущности могут наследоваться от не Entity классов, которые, в свою очередь, могут быть как абстрактными, так и обычными.

Состояние (поля) не Entity суперкласса не является персистентным, то есть не хранится в БД и не обрабатывается провайдером (Hibernate), поэтому любое такое состояние (поля), унаследованное Entity классом, также не будет отображаться в БД.

Не Entity суперклассы не могут участвовать в операциях EntityManager или Query. Любые маппинги или аннотации отношений в не Entity суперклассах игнорируются.

Может ли Entity класс наследоваться от Entity классов?

Да, может.

Может ли не Entity класс наследоваться от Entity класса?

Да, может.

Встраиваемый (Embeddable) класс

Это класс, который не используется сам по себе, а только как часть одного или нескольких Entity классов.

Hibernate называет эти классы компонентами.

JPA называет их встраиваемыми.

В любом случае, концепция одна и та же: композиция значений.

Встраиваемый класс помечается аннотацией @Embeddable.

Встраиваемый класс может быть встроен в несколько классов-сущностей, но встроенный объект с конкретным состоянием принадлежит исключительно владеющей им сущности и не может использоваться одновременно другими сущностями, он не является общим для нескольких сущностей.

То есть, если класс Person с полями name и age встроен и в класс Driver, и в класс Baker, то у обоих последних классов появятся оба поля из класса Person. Но если у объекта Driver эти поля будут иметь значения "Иван" и "35", то эти же поля у объекта Baker могут иметь совершенно иные значения, никак не связанные с объектом Driver.

В целом, встраиваемый класс служит для того, чтобы выносить определение общих атрибутов для нескольких сущностей, можно считать что JPA просто встраивает в сущность вместо объекта такого класса те атрибуты, которые он содержит.

Особенности встраиваемых классов

• все поля встраиваемого класса, даже коллекции, станут полями класса, в который происходит встраивание;
• встраиваемые классы могут быть встроены в одну и ту же сущность несколько раз, нужно только поменять имена полей;
• экземпляры встраиваемых классов, в отличие от экземпляров сущностей, не имеют собственного персистентного состояния, вместо этого они существуют только как часть состояния объекта, которому они принадлежат;
• экземпляры встраиваемых классов, в отличие от экземпляров сущностей, не имеют собственного персистентного состояния, вместо этого они существуют только как часть состояния объекта, которому они принадлежат;

• встраиваемые классы могут использовать в качестве полей:

  • базовые типы;
  • коллекции базовых типов (с аннотацией @ElementCollection);
  • другие встраиваемые классы;
  • коллекции других встраиваемых классов (с аннотацией @ElementCollection);
  • сущности;
  • коллекции сущностей;
• сущность может использовать в качестве полей одиночные встраиваемые классы и коллекции встраиваемых классов;
• встраиваемые классы могут использоваться в качестве ключей и значений Map.

Требования к встраиваемым классам

• Должны соответствовать требованиям для сущностей, за исключением того, что у встраиваемых классов не ставится аннотация @Entity и может отсутствовать первичный ключ @Id.
• Должны быть аннотированы @Embeddable.

Например, у нас может быть встраиваемый класс ClassA, который представляет собой композицию строкового и числового значений, и эти два поля будут добавлены в класс EntityA:

@Entity

public class EntityA {

@Id

@GeneratedValue

private int id;

...

@Embedded

private ClassA classARef;

...

}

@Embeddable

public class ClassA {

private String myStr;

private int myInt;

...

}

Так как мы можем встраивать классы в неограниченное количество других классов, то у каждого класса, содержащего встраиваемый класс, мы можем изменить названия полей из встраиваемого класса.

Например, у класса Driver поля из встраиваемого класса Person будут изменены с name на driver_name и с age на driver_age:

@Embeddable

public class Person {

private String name;

name; private int age;

}

@Entity

public class Driver {

@Embedded

@AttributeOverrides({

@AttributeOverride(name = "name", column = @Column(name = "driver_name")),

@AttributeOverride(name = "age", column = @Column(name = "driver_age")),

})

private Person person;

...

}

Сущности, которые имеют встраиваемые классы, могут аннотировать поле или свойство аннотацией @Embedded, но не обязаны это делать.

Mapped Superclass

Mapped Superclass (сопоставленный суперкласс) - это класс, от которого наследуются Entity, он может содержать аннотации JPA, однако сам такой класс не является Entity, ему не обязательно выполнять все требования, установленные для Entity (например, он может не содержать первичного ключа).

Эти суперклассы чаще всего используются, когда у нас есть общая для нескольких классов сущностей информация о состоянии и отображении, которую можно вынести в Mapped Superclass.

Особенности Mapped Superclass

• Должен быть помечен аннотацией @MappedSuperclass или описан в xml файле.
• Не может использоваться в операциях EntityManager или Query, вместо этого нужно использовать классы-наследники.
• Не может состоять в отношениях с другими сущностями (в сущности нельзя создать поле с типом сопоставленного суперкласса).
• Может быть абстрактным.
• Не имеет своей таблицы в БД.

Для того, чтобы использовать Mapped Superclass, достаточно унаследовать его в классах-потомках:

В указанном примере кода в БД будут таблицы FULL_TIME_EMPLOYEE и PART_TIME_EMPLOYEE, но таблицы EMPLOYEE не будет:

Это похоже на стратегию наследования “Таблица для каждого конкретного класса сущностей”, но в модели данных нет объединения таблиц или наследования. Также тут нет таблицы для Mapped Superclass. Наследование существует только в объектной модели.

Основным недостатком использования сопоставленного суперкласса является то, что полиморфные запросы невозможны, то есть мы не можем загрузить всех наследников Mapped Superclass.

Mapped Superclass vs. Embeddable class

Сходства:

• не являются сущностями и могут иметь все аннотации, кроме @Entity;
• не имеют своих таблиц в БД;
• не могут использоваться в операциях EntityManager или Query.

Различия:

• MappedSuperclass - наследование, Embeddable class - композиция (экземпляр «части» может входить только в одно целое (или никуда не входить));
• поля из Mapped Superclass могут быть у сущности в одном экземпляре, полей из Embeddable class может быть сколько угодно (встроив в сущность Embeddable class несколько раз и поменяв имена полей);
• в сущности нельзя создать поле с типом сопоставленного суперкласса, а с Embeddable можно и нужно.

Entity Inheritance Mapping Strategies

Стратегии наследования нужны для того, чтобы дать понять провайдеру (Hibernate) как ему отображать в БД сущности-наследники.

Для этого нам нужно декорировать родительский класс аннотацией @Inheritance и указать один из типов отображения.

Следующие три стратегии используются для отображения данных сущности-наследника и родительской сущности:

1. SINGLE_TABLE

   Одна таблица на всю иерархию классов.

2. JOINED

   Стратегия "соединения", при которой поля или свойства, специфичные для подклассов, отображаются в таблицах этих подклассов, а поля или свойства родительского класса отображаются в таблице родительского класса.

3. TABLE_PER_CLASS

   Таблица для каждого конкретного класса сущностей.

SINGLE TABLE

Одна таблица на всю иерархию классов

Является стратегией по умолчанию и используется, когда аннотация @Inheritance не указана в родительском классе или когда она указана без конкретной стратегии.

Все entity, со всеми наследниками записываются в одну таблицу.

Для идентификации типа entity (наследника) определяется специальная колонка "discriminator column".

Минусом стратегии является невозможность применения ограничения NOT NULL для тех колонок таблицы, которые характерны только для классов-наследников.

Например, если есть entity Employee c классами-потомками FullTimeEmployee и PartTimeEmployee, то при такой стратегии все FullTimeEmployee и PartTimeEmployee записываются в таблицу Employee, и при этом в таблице появляется дополнительная колонка с именем DTYPE, в которой будут записаны значения, определяющие принадлежность к классу.

По умолчанию эти значения формируются из имён классов, в нашем случае - либо «FullTimeEmployee» либо «PartTimeEmployee».

Но мы можем их поменять в аннотации у каждого класса-наследника: @DiscriminatorValue("F").

Если мы хотим поменять имя колонки, то мы должны указать её новое имя в параметре аннотации у класса-родителя: @DiscriminatorColumn(name=EMP_TYPE) .

Эта стратегия обеспечивает хорошую поддержку полиморфных отношений между сущностями и запросами, которые охватывают всю иерархию классов сущностей:

JOINED

Стратегия "соединения"

В данной стратегии корневой класс иерархии представлен отдельной таблицей, а каждый класс-наследник имеет свою таблицу, в которой отображены только поля этого класса-наследника.

То есть таблица подкласса не содержит столбцы для полей, унаследованных от родительского класса, за исключением поля для первичного ключа @Id, который должен быть определен только в родительской таблице.

Столбец первичного ключа в таблице подкласса служит внешним ключом первичного ключа таблицы суперкласса.

Также в таблице родительского класса добавляется столбец DiscriminatorColumn с DiscriminatorValue для определения типа наследника.

Эта стратегия обеспечивает хорошую поддержку полиморфных отношений, но требует выполнения одной или нескольких операций соединения таблиц при создании экземпляров подклассов сущностей.

В глубоких иерархиях классов это может привести к недопустимому снижению производительности.

Точно так же запросы, которые покрывают всю иерархию классов, требуют операций соединения между таблицами подклассов, что приводит к снижению производительности:

TABLE PER CLASS

Таблица для каждого класса сущностей

Каждый класс-наследник имеет свою таблицу. Во всех таблицах подклассов хранятся все поля этого класса плюс те, которые унаследованы от суперкласса.

Минусом является плохая поддержка полиморфизма (polymorphic relationships) и то, что для выборки всех классов иерархии потребуется большое количество отдельных sql-запросов для каждой таблицы-наследника или использование UNION-запроса для соединения таблиц всех наследников в одну таблицу.

Также недостатком этой стратегии является повторение одних и тех же атрибутов в таблицах.

При TABLE PER CLASS не работает стратегия генератора первичных ключей IDENTITY, поскольку может быть несколько объектов подкласса, имеющих один и тот же идентификатор, и запрос базового класса приведет к получению объектов с одним и тем же идентификатором (даже если они принадлежат разным типам).

По порядковым номерам

Если мы сохраняем в БД сущность, у которой есть поле-перечисление (Enum), то в таблице этой сущности создаётся колонка для значений этого перечисления и по умолчанию в ячейки сохраняется порядковый номер этого перечисления (ordinal).

В JPA типы Enum могут быть помечены аннотацией @Enumerated, которая может принимать в качестве атрибута EnumType.ORDINAL или EnumType.STRING, определяющий, отображается ли перечисление (enum) на столбец с типом Integer или String соответственно.

@Enumerated(EnumType.ORDINAL) - значение по умолчанию, говорит о том, что в базе будут храниться порядковые номера Enum (0, 1, 2…).

Проблема с этим типом отображения возникает, когда нам нужно изменить наш Enum.

Если мы добавим новое значение в середину или просто изменим порядок перечисления, мы сломаем существующую модель данных.

Такие проблемы могут быть трудно уловимыми, и нам придется обновлять все записи базы данных.

По именам

@Enumerated(EnumType.STRING) - означает, что в базе будут храниться имена Enum.

Мы можем безопасно добавлять новые значения перечисления или изменять порядок перечисления.

Однако переименование значения enum все равно нарушит работу базы данных.

Кроме того, даже несмотря на то, что это представление данных гораздо более читаемо по сравнению с параметром @Enumerated(EnumType.ORDINAL), оно потребляет намного больше места, чем необходимо.

Это может оказаться серьезной проблемой, когда нам нужно иметь дело с большим объемом данных.

@PostLoad и @PrePersist

Другой вариант - использование стандартных методов обратного вызова из JPA.

Мы можем смапить наши перечисления в БД и обратно в методах с аннотациями @PostLoad и @PrePersist.

Идея состоит в том, чтобы в сущности иметь не только поле с Enum, но и вспомогательное поле. Поле с Enum аннотируем @Transient, а в БД будет храниться значение из вспомогательного поля.

Создадим Enum с полем priority содержащем числовое значение приоритета:

Мы добавили метод Priority.of(), чтобы упростить получение экземпляра Priority на основе его значения int.

Теперь, чтобы использовать его в нашем классе Article, нам нужно добавить два атрибута и реализовать методы обратного вызова:

Несмотря на то, что этот вариант дает нам большую гибкость по сравнению с ранее описанными решениями, он не идеален. Просто кажется неправильным иметь в сущности целых два атрибута, представляющих одно перечисление.

Кроме того, если мы используем этот вариант, мы не сможем использовать значение Enum в запросах JPQL.

Converter

В JPA с версии 2.1 можно использовать Converter для конвертации Enum’а в некое его значение для сохранения в БД и получения из БД.

Все, что нам нужно сделать, это создать новый класс, который реализует javax.persistence.AttributeConverter и аннотировать его с помощью @Converter.

Мы установили @Converter(autoApply=true), чтобы JPA автоматически применял логику преобразования ко всем сопоставленным атрибутам типа Category.

В противном случае нам пришлось бы поместить аннотацию @Converter непосредственно над полем Category у каждой сущности, где оно имеется.

В результате в столбце таблицы будут храниться значения: "S", "M" или "T".

Как мы видим, мы можем просто установить наши собственные правила преобразования перечислений в соответствующие значения базы данных, если мы используем интерфейс AttributeConverter.

Более того, мы можем безопасно добавлять новые значения enum или изменять существующие, не нарушая уже сохраненные данные.

Это решение просто в реализации и устраняет все недостатки с @Enumerated(EnumType.ORDINAL), @Enumerated(EnumType.STRING) и методами обратного вызова.

java.sql

Hibernate позволяет отображать различные классы даты/времени из Java в таблицах баз данных.

Стандарт SQL определяет три типа даты/времени:

1. DATE- Представляет календарную дату путем хранения лет, месяцев и дней.

   Эквивалентом JDBC является java.sql.Date.

2. TIME - Представляет время дня и хранит часы, минуты и секунды.

   Эквивалентом JDBC является java.sql.Time.

3. TIMESTAMP - Хранит как DATE, так и TIME плюс наносекунды.

   Эквивалентом JDBC является java.sql.Timestamp.

Поскольку эти типы соответствуют SQL, их сопоставление относительно простое. Мы можем использовать аннотацию @Basic или @Column:

Затем мы могли бы установить соответствующие значения следующим образом:

Обратите внимание, что использование типов java.sql для полей сущностей не всегда может быть хорошим выбором.

Эти классы специфичны для JDBC и содержат множество устаревших функций.

Чтобы избежать зависимостей от пакета java.sql, начали использовать классы даты/времени из пакета java.util вместо классов java.sql.Timestamp и java.sql.Time.

java.util

Точность представления времени составляет одна миллисекунда.

Для большинства практических задач этого более чем достаточно, но иногда хочется иметь точность повыше.

Поскольку классы в данном API изменяемые (не immutable), использовать их в многопоточной среде нужно с осторожностью.

В частности java.util.Date можно признать «эффективно» потоко-безопасным, если вы не вызываете у него устаревшие методы.

java.time

Начиная с Java 8, доступен новый API даты и времени для работы с временными значениями.

Этот API-интерфейс устраняет многие проблемы классов java.util.Date и java.util.Calendar.

Все классы в новом API неизменяемые (immutable) и, как следствие, потоко-безопасные.

Точность представления времени составляет одна наносекунда, что в миллион раз точнее чем в пакете java.util.

Типы данных из пакета java.time напрямую отображаются (маппятся) на соответствующие типы SQL.

Поэтому нет необходимости явно указывать аннотацию @Temporal:

1. LocalDate соответствует DATE.
2. LocalTime и OffsetTime соответствуют TIME.
3. Instant, LocalDateTime, OffsetDateTime и ZonedDateTime соответствуют TIMESTAMP.

Это означает, что мы можем пометить эти поля только аннотацией @Basic (или @Column), например:

Каждый временной класс в пакете java.time имеет статический метод parse() для анализа предоставленного значения типа String с использованием соответствующего формата.

Вот как мы можем установить значения полей сущности:

Если у нашей сущности есть поле с коллекцией, то мы привыкли ставить над ним аннотации @OneToMany либо @ManyToMany. Но данные аннотации применяются в случае, когда это коллекция других сущностей (entities).

Но что, если у нашей сущности коллекция не других сущностей, а базовых или встраиваемых (embeddable) типов, то есть коллекция элементов?

Для этих случаев в JPA имеется специальная аннотация @ElementCollection, которая указывается в классе сущности над полем коллекции базовых или встраиваемых типов.

Конфигурация для таблицы коллекции элементов указывается с помощью аннотации @CollectionTable, которая используется для указания имени таблицы коллекции и JoinColumn, который ссылается на первичную таблицу.

Коллекции могут иметь тип java.util.Map, которые состоят из ключа и значения.

Для этого типа коллекций применяются следующие правила:

1. Ключ или значение Map может быть базовым типом языка программирования Java, встраиваемым классом или сущностью.

2. Если значение Map является встраиваемым классом или базовым типом, используйте аннотацию @ElementCollection.

   пример

3. Если значение Map является сущностью, используйте аннотацию @OneToMany или @ManyToMany.

   пример

4. Использовать тип Map только на одной стороне двунаправленной связи.

Аннотация @MapKeyColumn позволяет настроить столбец «ключ» в таблице Map.

Аннотация @Column позволяет настроить столбец «значение» в таблице Map.

пример

Использование коллекций элементов имеет один большой недостаток:

элементы коллекции не имеют идентификатора, и Hibernate не может обращаться индивидуально к каждому элементу коллекции. Когда мы добавляем новый объект в коллекцию или удаляем из коллекции существующий элемент, Hibernate удаляет все строки из таблицы элементов и вставляет новые строки по одной для каждого элемента в коллекции.

То есть при добавлении одного элемента в коллекцию Hibernate не добавит одну строку в таблицу коллекции, а очистит её и заполнит по новой всеми элементами.

Поэтому коллекции элементов следует использовать только для очень маленьких коллекций, чтобы Hibernate не выполнял слишком много операторов SQL.

Во всех других случаях рекомендуется использовать коллекции сущностей с @OneToMany

Множественность в отношениях сущностей

Существуют следующие четыре типа связей между сущностями:

1. OneToOne - когда один экземпляр Entity может быть связан не больше чем с одним экземпляром другого Entity.

2. OneToMany - когда один экземпляр Entity может быть связан с несколькими экземплярами других Entity.

3. ManyToOne - обратная связь для OneToMany. Несколько экземпляров Entity могут быть связаны с одним экземпляром другого Entity.

4. ManyToMany - экземпляры Entity могут быть связаны с несколькими экземплярами друг друга.

Направление в отношениях сущностей

Направление отношений может быть как двунаправленным, так и однонаправленным.

Сторона-владелец отношения определяет, как среда выполнения Persistence обновляет отношение в базе данных.

Двунаправленные отношения имеют как сторону-владельца, так и владеемую сторону.

Однонаправленные отношения имеют только сторону-владельца.

Запросы и направление отношений

Язык запросов Java Persistence и запросы API Criteria часто перемещаются между отношениями.

Направление отношений определяет, может ли запрос перемещаться от одной сущности к другой.

Например:

• в двунаправленных отношениях запрос может перемещаться как от первой сущности ко второй, так и обратно.
• в однонаправленных отношениях запрос может перемещаться только в одну сторону - от владеющей сущности к владеемой.

Владелец связи и владеемый

По сути, у кого есть внешний ключ на другую сущность - тот и владелец связи. То есть, если в таблице одной сущности есть колонка, содержащая внешние ключи от другой сущности, то первая сущность признаётся владельцем связи, вторая сущность - владеемой.

В однонаправленных отношениях сторона, которая имеет поле с типом другой сущности, является владельцем этой связи по умолчанию, например:

@Entity
public class LineItem {
    @Id
    private Long id
    @OneToOne
    private Product product;
}

@Entity
public class Product {
    @Id
    private Long id;
    private String name;
    private Double price;
}

Родительская сущность (таблица)

Это сущность (таблица), на которую ссылается внешний ключ из дочерней сущности (таблицы).

Дочерняя сущность (таблица)

Это сущность (таблица), в которой есть колонка с внешним ключом, ссылающимся на родительскую сущность (таблицу).

Каскадные операции и отношения

Сущности, между которыми есть отношения, часто зависят от существования друг друга.

Например, позиции (LineItem) являются частью заказа (CustomerOrder), и если заказ удален, все позиции также должны быть удалены.

Это называется - каскадным удалением.

JPA позволяет распространять операции с сущностями (например, persist или remove) на связанные сущности. Это означает, что при включенном каскадировании, если сущность A сохраняется или удаляется, тогда сущность B (связанная с A отношением, например через ManyToOne) также будет сохраняться или удаляться без явных команд сохранения или удаления.

Каскадирования можно добиться, указав у любой из аннотаций @OneToOne, @ManyToOne, @OneToMany, @ManyToMany элемент cascade и присвоив ему одно или несколько значений из перечисления CascadeType (ALL, DETACH, MERGE, PERSIST, REFRESH, REMOVE).

Как правило каскадные операции применяются от родительской сущности к дочерним, но они могут распространяться и в обратном направлении - от дочерней к родительской.

Конечно это не всегда нужно, а зачастую совсем не нужно, но главное условие для этого - чтобы между ними было двунаправленное отношение, иначе каскадные операции выполняются только в одном направлении.

Удаление сирот в отношениях (Orphan Removal)

Представим, что у нас есть класс Customer, у которого есть коллекция Order:

@Entity
public class Customer {
    @OneToMany(cascade = CascadeType.ALL, orphanRemoval = true)
    private List<Order> orders = new ArrayList<>();
    // other mappings, getters and setters
}

Пусть у нас есть один объект Customer - родитель, в коллекции которого есть 4 объекта Order - дети, и мы установили атрибут orphanRemoval = true над этой коллекцией. В нашей базе данных в таблице Customer будет одна строка, а в таблице Order будет четыре строки. Также в таблице Order будет колонка с внешними ключами на таблицу Customer. В каждой из четырех ячеек этой колонки будут ссылки на один и тот же первичный ключ объекта Customer.

Например, мы удалим из коллекции orders один объект Order - любой из четырех, в результате чего у объекта Customer останется три объекта Order:

Customer customer = entityManager.find(Customer.class, 1L);
Order order = customer.getOrders().get(0);
customer.getOrders().remove(order);
flushAndClear();

persist()

new → managed
объект будет сохранен в базу при commit-е транзакции или в результате flush-операции.

managed → {ignored}
операция игнорируется, однако связанные entity могут поменять статус на managed, если у них есть аннотации каскадных изменений.

removed → managed

detached → {exception}
исключение сразу или на этапе commit-а транзакции (так как у detached уже есть первичный ключ).

remove()

new → {ignored}
операция игнорируется, однако связанные entity могут поменять статус на removed, если у них есть аннотации каскадных изменений и они имели статус managed

managed → removed
запись в базе данных будет удалена при commit-е транзакции (также произойдут операции remove для всех каскадно зависимых объектов)

removed → {ignored}
операция игнорируется

detached → {exception}
исключение сразу или на этапе commit-а транзакции

merge()

new → ...
будет создана новая managed entity, в которую будут скопированы данные объекта.

managed → {ignored}
операция игнорируется, однако операция merge сработает на каскадно зависимых entity, если их статус не managed.

removed → {exception}
исключение сразу или на этапе commit-а транзакции.

detached → ...
либо данные будут скопированы в существующую БД managed entity с тем же первичным ключом,
либо создана новая managed entity, в которую скопируются данные.

refresh()

managed → ...
будут восстановлены все изменения из базы данных данного entity, также произойдет refresh всех каскадно зависимых объектов

new, removed, detached → {exception}
будет вызвано исключение.

detach()

managed, removed → detached

new, detached → {ignored}
операция игнорируется.