JPA: когда выбирать Multivalued Association vs. Element Collection Mapping

Я хотел бы лучше понять различия между

(1) традиционное многозначное отношение/ассоциация

   @Entity -> @OneToMany -> @Entity

(2) JPA2 Коллекция вложенных (и базовых) типов

  @Entity -> @ElementCollection -> @Embeddable

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

Интуитивно я обычно использовал сценарии @ElementCollection для компоновки. Но даже это очень похоже на CascadeType=DELETE.

Я пропустил суть здесь? Является ли более эффективным, чем другой, для определенных целей?

Спасибо, J.

Ответ 1

Интуитивно я обычно использовал сценарии @ElementCollection для компоновки. Но даже это очень похоже на CascadeType = DELETE

Они похожи, с небольшими различиями. Страница ElementCollection из Java Persistence wikibook суммирует ее довольно хорошо:

Emdedded Collections

Отображение ElementCollection может быть используется для определения набора Embeddable объектов. Это не типичное использование объектов Embeddable как объекты не встроены в исходной таблицы объектов, но хранится в отдельный коллекция таблица. Это аналогично a OneToMany, кроме целевым объектом является Embeddableот Entity. Это позволяет коллекции простых объектов определяется, не требуя простого объекты для определения Id или ManyToOneобратное отображение. ElementCollection может также переопределять сопоставления или таблицу для их сбора, чтобы вы могли несколько объектов ссылаются на одни и те же Embeddable класс, но каждый магазин их зависимые объекты в отдельном таблица.

Ограничения использования ElementCollection вместо OneToMany заключается в том, что целевые объекты не могут быть запрошены, сохранены, объединены независимо от их родительского объекта. Они строго конфиденциальны (зависимых) объектов, то же, что и Embedded. Их нет cascadeна ElementCollection, целевые объекты всегда сохраняются, объединены, удалены с родителями. ElementCollection все еще можно использовать тип выборки и по умолчанию - LAZYтак же, как и другие сопоставления коллекции.

См. также

Встраиваемые (агрегированные, композитные или компонентные объекты)

Ответ 2

Спецификация JPA понятна

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

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

Предположим, вы сделали что-то вроде

/**
  * Let suppose owning contains SIX embeddables instances
  */
Owning owning = manager.find(Owining.class, owningId);

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

/**
  * Usually your web framework Takes care of binding your submitted data
  */
Owning owning = new Owning();
owning.setProperty(request.getParameter("property"));

Затем вы можете объединить свои данные и вы думаете, что ваши экземпляры встраиваемых оболочек хранятся в базе данных. Хорошо, посмотрим

Как показано выше вы (или ваш веб-фреймворк) только что получили свойства собственности, правильно??? Таким образом, ваш owning.getElementList() пуст. Поскольку owning.getElementList() пуст, JPA удалит все его экземпляры вложенных оболочек. Имейте это в виду.

Обычно вложенный класс не имеет отношения к другому, кроме его Owning Entity. А при использовании набора вложений в JPA всегда выберите перед сохранением/обновлением, потому что ему нужно сравнить один за другим с помощью метода equals. Поэтому при использовании коллекции Set вам потребуется согласованная равная реализация.

Здесь вы можете увидеть его аналог в Hibernate.