update를 만드느라 엄첨 애를 먹은 경우였다.

// Create
DeployStatus entity = make();
save(entity , entityManager);
entityManager.flush();
entityManager.clear();

// READ
DeployStatus saved = entityManager.find(DeployStatus.class , entity.getDeployId());
assertNotNull(saved);
assertEquals(entity, saved);// expected, actuall

// Update
entity.setTargetAssetSeqno(1201L);
entity = entityManager.merge(entity);
entityManager.flush();
entityManager.clear();// 메모리 상에서 지워져서 entity manager로 부터 detach된 상태
DeployStatus updated = entityManager.find(DeployStatus.class , entity.getDeployId());
assertEquals(entity, updated );

//Delete
delete(updated, entityManager);
assertNull(entityManager.find(DeployStatus.class, entity.getDeployId()));
entityManager.flush();
entityManager.clear();

delete(updated, entityManager);에서 entity가 아닌 updated를 쓰는 이유는 entity는 update과정에서 clear()로 메모리 상에서 지워져서 detach된 상황이다. 그러므로 remove(entity)한다면 오류가 발생할 것이다.

하지만 entityManager.find로 찾으면 DB에 남아 있으므로 삭제가 가능해짐(entityManager가 관리중이라는말.)

entityManager는 동일 객체임을 보장하기 때문도 있다.

나중에 detach에 대해서도 한번 다시 정리를 해야할것같다.

@EqualsAndHashCode

또한 위 annotation을 추가시켜주지 않는다면 객체의 field값들이 모두 같다고 해도 hash value를 비교하지 못한다.

류차장님의 답변

assertEquals()가 Java equals()로 같은지 판단하는 건데 equals() 따로 오버라이드 안 하면 필드값 비교 같은 거 안 하고 다른 객체는 다른 거로 판단하죠. @EqualsAndHashCode는 equals() 오버라이드 자동으로 만들어주는 거