Удаление определенного дочернего объекта при обновлении родительского объекта

My Service layer is annotated with @Transactional, when i am trigerring get Api for dept. it is returning proxy object of department and in service layer list of employees is not getting fetched . when model mapper is converting dept object to deptBean at that time it is fetching list of employees. Why I am able to fetch list of employee object from proxy object outside transaction.

У вас есть несколько способов решить эту проблему.

Один из способов, который я очень высоко оцениваю не предлагать, но он доступен, - это пометить коллекцию для быстрой загрузки в вашу модель отображения, как это

// inside your Department entity
@OneToMany(mappedBy = "department", fetch = FetchType.EAGER)
private List<Employee> employees;

Проблема с этим подходом заключается в том, что, хотя он и будет работать, он вводит то, что мы называем SELECT N+1, где в основном провайдер сохраняемости будет извлекать Department, а затем будет выполнять выборку для заполнения коллекции. При выборе 1 Department это не такая уж большая проблема. Когда вы выбираете несколько таких отделов, это становится серьезной проблемой производительности.

SELECT * FROM Department // returns 3 rows
SELECT * FROM Employees WHERE departmentId = :row1DepartmentId   
SELECT * FROM Employees WHERE departmentId = :row2DepartmentId
SELECT * FROM Employees WHERE departmentId = :row3DepartmentId

Для большого набора результатов это может серьезно снизить производительность.

Лучший и предложенный способ связать выборки ассоциаций во время запроса в зависимости от того, что требует вызывающий запрос. Другими словами, не используйте #findOne(), а вместо этого напишите специализированный запрос, который возвращает то, что нужно вашему коду.

@Query( "SELECT d FROM Department d JOIN FETCH employees WHERE d.id = :id" )
public List<Department> getDepartmentWithEmployees(Integer id)

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

In Update function of Service layer also , I am returning proxy object but that is not able to fetch list of employees in Service layer too.Also , I tried calling get function of service layer in after department updation controller even that is also not able to fetch list of employees.

Поскольку мы решили проблемы отложенной инициализации с помощью вызова #getDepartment, это больше не должно быть проблемой.

From Rest Api I am getting Department object which contains the list of employees that need to be updated/deleted/added in database, My Employee Entity is having a transient property say operation on basis of that i am filtering out which operation need to be perform on employee update / delete / add.

Пара ников здесь.

Сначала я бы подумал о разделении ваших объектов JSON и объектов сущности вашей базы данных. Вы эффективно заражаете свою модель базы данных временным полем, чтобы вы могли передать некоторый данные от контроллера на свой уровень сохраняемости. Мне это кажется неправильным.

Если вы не хотите разделять ваши json-объекты и модели сущностей, то, по крайней мере, поместите эти временные данные в отдельный объект контекста, который вы заполняете отдельно и предоставляете процессу обновления.

public class EmployeeOperationContext {
  private Integer employeeId;
  private EmployeeOperation operation;
}

public enum EmployeeOperation {
  INSERT,
  UPDATE,
  DELETE
}

public void updateDepartment(
     Department dept, 
     List<EmployeeOperationContext> contexts) { 
  ...
}

Ключевым моментом здесь является то, что в любое время вам может потребоваться рефакторинг вашей модели базы данных, чтобы работать лучше или обеспечить лучшее представление о вашей базе данных в более нормализованном виде. При этом это не означает, что ваш REST API изменится.

И наоборот, то же самое может произойти, когда потребители REST API диктуют изменения, но вы не хотите, чтобы эти изменения повлияли на вашу модель базы данных.

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

ОБНОВИТЬ

Проблема с вашим обновлением Department заключается в том, что вы слепо берете данные из входящего вызова отдыха и отправляете их в базу данных, не объединяя их с существующими данными. Другими словами, посмотрите на это

// Here you covert your DepartmentBean JSON object to a Department entity
Department dept = modelMapper.map( deptBean, Department.class );
// Here you overwrite the existing Department with JSON data
Department persistedDept = departmentRepository.save( dept );
// ^ this department no longer has employees because of this

Есть несколько способов решить эту проблему, но все они связаны с одной и той же предпосылкой. Основная проблема здесь заключается в том, что вы должны сначала получить существующий объект отдела из базы данных, чтобы у вас было правильное состояние, а затем применить входящие изменения. Коротко:

// Fetch department from the database
Department department = departmentRepository.get( departmentId );
// overlay the DepartmentBean data on the Department
modelMapper.map( deptBean, department, Department.class );
// save department
departmentRepository.save( department );

В конечном итоге я бы изменил метод службы, чтобы использовать DepartmentBean в качестве входных данных и выполнить описанное выше внутри службы:

@Transactional
public void updateDepartment(DepartmentBean jsonModel) {
  // Now we can read the department & apply a read lock in the trx
  Department department = repository.getWithLock( departmentId );

  // Overlay the json data on the entity instance
  modelMapper.map( jsonModel, department, Department.class );

  // save the changes
  repository.save( department );
}

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