Hibernate: будет ли транзитивно объединять работу со многими объектами?

Question

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

а.) Итак, у меня есть несколько вопросов.

Если я выполняю платеж -> клиент (в однонаправленных отношениях «многие-к-одному») и я выполняю

Payment payment = Payment.class.cast (session.merge (oldPayment));

Будет ли объект клиента также присоединен к сеансу, или я должен сделать еще один вызов слияния для клиента.

б.) Что произойдет, если платеж -> клиент (двунаправленное отношение «многие-к-одному»).Что бы случилось, чем.

в.) Как насчет того, чтобы у меня были отношения более трех иерархий.
Пример: гостиница -> оплата -> клиент.

Если я сделаю Hotel hotel = Hotel.class.cast (session.merge (unmergeHotel)), будет ли платеж и объект клиента также объединены в сеанс?

Спасибо

Answer 1

Это определяется каскадными вариантами ваших отношений.

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

Связанный отрывок из спецификации JPA (я думаю, что интерфейс Session нативного Hibernate предлагает ту же семантику):

• Для всех объектов Y, на которые ссылаются отношения из X, имеющие значение элемента каскада cascade=MERGE или cascade=ALL, Y рекурсивно сливается как Y '. Для всех таких Y упоминается по X, X 'устанавливается на ссылку Y'. (Обратите внимание, что если X управляется, то X является тем же объектом, что и X».)
• Если X является сущностью, объединенной с X ', со ссылкой на другую сущность Y, где cascade=MERGE или cascade=ALL не указано, то навигация той же ассоциации из X 'дает ссылка на управляемый объект Y 'с той же постоянной идентификацией, что и Y.

Поставщик персистентности не должен объединять поля, помеченные как LAZY, которые не были получены: он должен игнорировать такие поля при объединении.

Смотри также:

• JSR 317: Java ™ Persistence 2.0
• 11,11. Переходное упорство