java java-ee jpa persistence

java - fusionar vs buscar para actualizar entidades JPA



java-ee persistence (1)

Del libro Pro EJB3 JPA :

La estrategia más común para manejar esta (-actualizar entidades-) en la aplicación Java EE que usa JPA es colocar los resultados de los cambios en instancias de entidades separadas y fusionar los cambios pendientes en un contexto de persistencia para que puedan escribirse en la base de datos

Ejemplo: el parámetro emp es una entidad separada

@Stateless public class EmployeeServiceBean { @PersistenceContext EmtityManager em; public void updateEmployee(Employee emp){ if(em.find(Employee.class, emp.getId()) == null){ throw new IllegalArgumentException("Unknown Employee id") } em.merge(emp); } }

Entonces, dice:

Si la cantidad de información que se está borrando es muy pequeña, podemos evitar el objeto separado y la operación merge () ubicando la versión administrada y copiando manualmente los cambios en ella.

Ejemplo: Aquí se adjunta el emp.

public void updateEmployee(int id, String newName, long newSalary) { Employee emp = em.find(Employee.class, id); if(emp==null){ throw new IllegalArgumentException("Unknown Employee id") } emp.setEmpName(newName); emp.setSalary(newSalary); }

Por lo tanto, parece que para pequeñas actualizaciones y para crear operaciones, la estrategia find() y luego establecer nuevos valores uno por uno es conveniente. Pero, para las grandes actualizaciones de datos (es decir, colecciones) es preferible tener una entidad separada y todas sus relaciones (con CascadeType.Merge) y hacer una gran merge() .

Ok pero por que


Porque si su bean tiene muchos atributos, JPA verificará uno por uno en el proceso de fusión, para todos los atributos, si está tratando con un objeto separado.

Ahora, si tiene un bean con 200 atributos y desea cambiar solo 1 campo, para JPA es más fácil obtener la versión administrada (internamente, JPA sabe cuándo un campo de una entidad administrada está "sucio" o no), entonces solo tratará con ese atributo específico.