java - method - update entity jpa hibernate

¿Por qué utilizar la instancia devuelta después de guardar() en Spring Data JPA Repository?

Question

Aquí está el código:

@Repository
public interface AccountRepository extends JpaRepository<Account, Long> {}

JpaRepository del proyecto Spring Data JPA.

Aquí está el código de prueba:

public class JpaAccountRepositoryTest extends JpaRepositoryTest {
    @Inject
    private AccountRepository accountRepository;

    @Inject
    private Account account;

    @Test
    @Transactional
    public void createAccount() {
        Account returnedAccount = accountRepository.save(account);

        System.out.printf("account ID is %d and for returned account ID is %d/n", account.getId(), returnedAccount.getId());
    }
}

Aquí está el resultado:

account ID is 0 and for returned account ID is 1

Aquí está de CrudReporsitory.save () javadoc:

Guarda una entidad dada. Utilice la instancia devuelta para realizar más operaciones ya que la operación de salvar podría haber cambiado la instancia de la entidad por completo.

Aquí está el código real para SimpleJpaRepository de Spring Data JPA:

 @Transactional
    public T save(T entity) { 
            if (entityInformation.isNew(entity)) {
                    em.persist(entity);
                    return entity;
            } else {
                    return em.merge(entity);
            }
    }

Entonces, la pregunta es ¿por qué necesitamos usar la instancia devuelta en lugar de la original? (Sí, debemos hacerlo, de lo contrario seguiremos trabajando con instancia separada, pero ¿por qué?)

El método original EntityManager.persist () devuelve vacío, por lo que nuestra instancia se adjunta al contexto de persistencia. ¿Se produce algo de magia proxy al pasar la cuenta para guardarla en el repositorio? ¿Es la limitación de la arquitectura del proyecto Spring Data JPA?

Answer 1

Se supone que el método save(…) de la interfaz CrudRepository simplemente el almacenamiento de una entidad sin importar en qué estado se encuentre. Por lo tanto, no debe exponer la implementación específica de la tienda real, incluso si (como en el caso JPA) la tienda diferencia entre nuevas entidades para ser almacenadas y las existentes para ser actualizadas. Es por eso que el método en realidad se llama save(…) no create(…) o update(…) . Devolvemos un resultado de ese método para permitir realmente que la implementación de la tienda devuelva una instancia completamente diferente, como lo hace potencialmente JPA cuando se invoca merge(…) .

Por lo tanto, en general, es más una decisión de la API ser indulgente con la implementación real y, por lo tanto, implementar el método para JPA tal como lo hacemos. No se realiza un masaje de proxy adicional a las entidades aprobadas.

Answer 2

Te perdiste la segunda parte: si la entidad no es nueva, se llama merge . merge copia el estado de su argumento en la entidad adjunta con el mismo ID, y devuelve la entidad adjunta. Si la entidad no es nueva y no utiliza la entidad devuelta, realizará modificaciones en una entidad separada.