JPA: когда выбирать многозначную ассоциацию против Отображение коллекции элементов
Я хотел бы хотелось бы лучше понять различия между
(1) традиционной многозначной связью / ассоциацией
@Entity -> @OneToMany -> @Entity
и
(2) коллекцией встраиваемых (и базовых) типов JPA2
@Entity -> @ElementCollection -> @Embeddable
. синтаксические различия, но интересно, есть ли также последствия для производительности . Под капотом реализация базы данных выглядит очень похоже.
Наглядно, Я бы обычно использовал @ElementCollection для композиционных сценариев . Но даже это выглядит очень похоже на CascadeType = DELETE .
Я здесь упускаю суть? Является ли один более эффективным, чем другой, для определенных целей?
Спасибо, J.
2 ответа
Интуитивно я бы обычно использовал @ElementCollection для сценариев композиции. Но даже это кажется очень похожим, например CascadeType = DELETE
. Они похожи, с некоторыми небольшими отличиями. Страница ElementCollection из викибука Java Persistence довольно хорошо резюмирует это:
Добавленные коллекции
Отображение
ElementCollectionможет быть используется для определения набораВстраиваемыеобъекты. Это не типичное использованиеEmbeddableобъектов как объекты не встроены в таблица исходного объекта, но хранящаяся в отдельный сборный стол. Это аналогиченOneToMany, за исключением целевой объект - этоEmbeddableвместо объекта. Это позволяет коллекциям простых предметов, чтобы их было легко определены, не требуя простого объекты для определенияIdилиManyToOneобратное отображение.ElementCollectionможет также переопределить сопоставления или таблицу для их коллекции, так что вы можете иметь несколько сущностей ссылаются на одно и то жеВстраиваемыйкласс, но с каждым магазином их зависимые объекты в отдельные Таблица.Ограничения использования
ElementCollectionвместоOneToMany- целевые объекты нельзя запросить, сохранить, объединить независимо от родительского объекта. Они находятся в строго частной собственности. (зависимые) объекты, то же самое, что иВстроенное отображение. Их неткаскадвариант дляElementCollection, целевые объекты всегда сохраняются, объединены, удалены со своим родителем.ElementCollectionпо-прежнему может использовать выберите тип и по умолчаниюLAZYтак же, как и другие сопоставления коллекций.
См. Также
Спецификация JPA ясна
Встраиваемые объекты нельзя запрашивать, сохранять, объединять независимо от их родительского объекта. Это строго частные (зависимые) объекты
Вы должны использовать осторожно , потому что его продолжительность жизни ограничена продолжительностью жизни экземпляра владеющей сущности. Итак, если вы сохраните / объедините / удалите свой экземпляр объекта-владельца, все его встраиваемые экземпляры будут сохранены / объединены / удалены
Предположим, вы сделаете что-то вроде
/**
* Let's 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 properties , верно ??? Итак, ваш owning.getElementList () пуст . Поскольку owning.getElementList () пуст, JPA удалит все свои встраиваемые экземпляры . Имейте это в виду.
Обычно встраиваемый класс не имеет отношений, кроме его Собственной сущности. А при использовании набора встраиваемых файлов JPA всегда выбирает перед сохранением / обновлением, потому что ему нужно сравнивать одно за другим , используя свой метод equals . Таким образом, при использовании коллекции Set вам нужна согласованная реализация .
Здесь вы можете увидеть его аналог в Hibernate.