Требуется ли удалить объект из его обратной коллекции, когда ссылка на родителя уже установлена ​​в значение null в сущности при слиянии?

Question

обратная сторона (департамент):

@OneToMany(mappedBy = "department", fetch = FetchType.LAZY, cascade = {CascadeType.PERSIST, CascadeType.MERGE, CascadeType.REFRESH, CascadeType.DETACH}) 
private List<Employee> employeeList = new ArrayList<Employee>(0); 

Обладание сторона (Сотрудник):

@JoinColumn(name = "department_id", referencedColumnName = "department_id") 
@ManyToOne(fetch = FetchType.LAZY) 
private Department department; 

Способ присоединения к Employee объект, поставляемый клиентом, имеющий нулевое Department в нем:

public Employee update(Employee employee) { 
    Department department = employee.getDepartment(); 

    if (department == null) { 
     Employee managedEmployee = entityManager.find(Employee.class, employee.getEmployeeId()); 
     // Obtain the original Employee entity which may still have its Department intact. 

     if (managedEmployee == null) { 
      throw new EntityNotFoundException(); 
     } 

     Department managedDepartment = managedEmployee.getDepartment(); 

     if (managedDepartment != null) { 
      managedEmployee.getDepartment().getEmployeeList().remove(managedEmployee); 
      // Removing an Employee entity from the list on the inverse side, 
      // since it will no longer be pointing to Employee after Employee is merged. 
     } 

     return entityManager.merge(employee); 
    } 
} 

Поставляется Employee является отдельным объектом. Предположим, что Department является необязательным для Employee s, и, следовательно, имеется нулевой внешний ключ (таким образом, ON DELETE SET NULL указан в внутренней системе).

Нужно явно удалить Employee объект, как показано на update() выше способом из списка сотрудников на обратной стороне отношения (Department), когда входящий в комплект поставки Employee не содержит Department (потому что он уже установленным на нуль клиентом при редактировании объекта Employee) перед слиянием поставленного объекта Employee?

Я думаю, провайдер сохранит ссылку Employee в списке сотрудников на обратной стороне отношений, в противном случае болтается.

Answer 1

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

Это может быть необязательно, но это будет функцией вашего провайдера и кэширования. Если отдел кэшируется (в текущем EntityManager или в кеше второго уровня), и список был извлечен, он не будет знать об этом изменении. В этом случае вам придется принудительно перезагрузить объект, используя опцию обновления или исключение кеша. Как правило, гораздо проще поддерживать список напрямую. Если вас беспокоит производительность, вы можете проверить, был ли список уже загружен перед вызовом remove, но это не всегда необходимо (отслеживание изменений EclipseLink может разрешить изменение без загрузки коллекции).

«ON DELETE SET NULL» находится за пределами JPA, и я не знаю, как сообщить провайдеру, что это установлено на основе отношений. Нет смысла указывать отношение Employee.department к null и слиянию, поскольку JPA затем попытается обновить внешний ключ до нуля, что не является необходимым. Я бы не рекомендовал его использовать, но если это необходимо, обновите/недействите Employee в кеше вместо обновления отношения к null.

Answer 2

Поскольку сторона владельца ассоциации находится на объекте Employee, нет необходимости удалять сотрудника из сотрудников Department.

Вы можете удалить эту часть кода.

Также имейте в виду, что метод merge будет вызывать IllegalArgumentException, если сотрудник является удаленным экземпляром объекта. Так что, возможно, вы не можете просто удалить часть (ваш сотрудник) из вашего кода, или, может быть, вы можете поймать исключение, перебрасывающее EntityNotFoundException, но все это зависит от вашей логики кода.

Добавление Oficial источника

Цитата из JPA 2 спецификации (JSR-338) раздел Синхронизация с базой данных:

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