JPA: когда выбрать многозначную ассоциацию против сопоставления коллекции элементов - PullRequest
34 голосов
/ 05 августа 2010

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

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

   @Entity -> @OneToMany -> @Entity

и

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

  @Entity -> @ElementCollection -> @Embeddable

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

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

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

Спасибо, Дж.

Ответы [ 2 ]

16 голосов
/ 06 августа 2010

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

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

Законченные коллекции

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

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

Смотри также

8 голосов
/ 06 августа 2010

JPA спецификация ясна

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

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

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

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

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

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

. Затем вы можете объединить отправленные данные, и Think ваши экземпляры встраиваемых файлов еще сохраняются в базе данных .Что ж, давайте посмотрим

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

Обычно встраиваемый класс не связан ни с чем, кроме его Владельца.А при использовании набора встраиваемых файлов JPA всегда выбирают перед сохранением / обновлением, поскольку необходимо сравнить одно за другим , используя метод равных .Таким образом, вам нужна согласованная реализация равных при использовании коллекции Set.

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

...