Вопрос каскадный JPA

Как сказано

Когда я пытаюсь удалить объект UserProfile, соответствующий объект User все еще остается

Возможно, когда вы пытаетесь удалить UserProfile, вы получаете нарушение ограничения целостности из базы данных - вы используете движок MyISAM в MySQL?

Но как вы об этом ничего не говорит. Возможно, ваш объект UserProfile не имеет ссылки на объект User.

Как сказано в спецификации JPA

, операция удаления каскадируется к объектам, на которые ссылается X , если связь от X к этим другим объектам аннотируется с помощью значения элемента аннотации cascade = REMOVE или cascade = ALL.

Что-то вроде

UserProfile up = entityManager.find(UserProfile.class, id);

entityManager.close();

// Notice User is null outside a persistence context 
// So user will be not removed from the database because UserProfile does not have a reference to it
up.setUser(null);

entityManager.getTransaction().begin();

entityManager.remove(up);

entityManager.getTransaction().commit();

Или у вас есть что-то вроде

entityManager.getTransaction().begin();

UserProfile up = entityManager.find(UserProfile.class, id);

// throws UPDATE USER_PROFILE SET USER_ID = NULL
up.setUser(null);

// up.getUser() is null
// So user is not removed
entityManager.remove(up);

entityManager.getTransaction().commit();

В ответ на комментарий ChhsPly:

В книге Java Persistence with Hibernate вы видите следующее

Атрибут cascade является направленным: Применяется только к одному концу ассоциации .

Думаю, было бы лучше, поскольку

Он применяется только к одному концу ассоциации на операцию

Таким образом, вы можете поместить атрибут каскада в обе стороны одновременно, даже в двунаправленной связи. Итак, ChssPly прав.

Атрибут mappdeBy устанавливает двунаправленную связь . Атрибут mappedBy определяет объект Address как обратную сторону отношения. Это означает, что объект Customer является стороной-владельцем отношения.

ChssPly прав, когда говорит, что mappedBy не имеет ничего общего с каскадом

Это верно, когда у вас двусторонние отношения: владелец диктует правила каскада, поскольку он «владелец». «Принадлежащая» сущность по существу следует приказам, она не может отдавать приказы, так сказать.

Ваш вопрос неверен сам по себе, отсюда и вся путаница. Артур хорошо поработал со своим ответом, но из комментариев ясно, что путаница все еще сохраняется, поэтому позвольте мне попробовать ее здесь.

Каскады сохраняются только тогда, когда я укажу их на юридическом лице, владеющем взаимосвязь?

«каскад» - это атрибут, который вы указываете на одном (или, возможно, на обоих в случае двунаправленного) конце отношения. Он определяет, какие действия выполнялись на , который конец будет распространен на другой конец. Существует много различных типов этих действий, определенных в JPA, и даже больше , определенных в расширениях Hibernate. Это важное различие - вы должны говорить только о распространяемом конкретном поведении, а не о «каскаде» в целом.

PERSIST, MERGE, REFRESH распространяются нормально (с конца, который они были объявлены, на другой) .

УДАЛИТЬ, однако, сложно, потому что оно может означать две разные вещи. Если у вас есть отношения между A и B и вы » Hibernate делает четкое различие между ними - вы можете объявить каскадные типы REMOVE (DELETE) и DELETE_ORPHAN отдельно; В спецификации JPA нет. Обратите внимание, что DELETE_ORPHAN не поддерживается для однозначных отношений (OneToOne / ManyToOne).

Таким образом, распространение REMOVE (само по себе или когда оно является частью ALL) зависит от того, есть ли у отношения явный владелец ( однонаправленный всегда работает; двунаправленный действует, если он отображается с помощью mappedBy , и нет, если он отображается с помощью таблицы соединений ), и в этом случае он распространяется от владельца к собственному ИЛИ без владельца в в этом случае он распространяется в любом направлении, но без семантики DELETE_ORPHAN , если это не было явно указано. Типичным примером последнего является двунаправленное соединение "многие ко многим".