작성
·
261
0
안녕하세요, 강의 내용중 질문이 있어 질문 드립니다.
PDF 13~14 쪽에 있는,
MemberRepositoryTest 파일을 보면,
Assertions.assertThat(findMember).isEqualTo(member); //JPA 엔티티 동일성 보 장
이라고 나와 있습니다.
해당 테스트를 통과 하는데 있어서는 문제가 없지만,
이는 정확히 말해서 동일성이 보장 된게 아니라,
동등성이 보장 되어야 하는거 아닌가요?
그리고 테스트 중간에
@Test
@Transactional
@Rollback(false)
public void testMember(){
Member member = new Member();
member.setName("memberA");
memberRepository.save(member);
em.flush(); em.clear();
Member findMember = memberRepository.findOne(member.getId());
Assertions.assertThat(findMember).isEqualTo(member);
}
이것과 같이 진행하면 false 가 나옵니다.
Member.class 를
@Entity
@Data
@EqualsAndHashCode(onlyExplicitlyIncluded =true)
public class Member {
@Id @GeneratedValue
@Column(name="member_id")
@EqualsAndHashCode.Include
private Long id;
@NotEmpty //-->@valid로 체크
private String name;
@Embedded //@Embadable....
private Address address;
@JsonIgnore // 양방향 참조시에 한쪽에 해줘야함 그래서 연쇄 호출안함
@OneToMany(mappedBy = "member") //읽기만 가능
private List<Order> orders = new ArrayList<>();
}
이렇게 고치니까 통과가 되었습니다.
질문 정리
1) .isEqualsTo 는 동일성이 아닌 동등성 보장인가요?
2) @Data를 사용했다고 해서, equals, hashCode가 정확하게 작동하지 않을때도 있나요?
답변 1
0
안녕하세요. hi_man159님, 공식 서포터즈 y2gcoder입니다.
1) 정확히는 같은 영속성 컨텍스트 내에서 동일성을 보장합니다! 같은 영속성 컨텍스트 내에서는 1차 캐시에 엔티티 객체를 저장하고 사용하기 때문에 주소값도 같습니다. 다만 말씀하신 것처럼 isEqualsTo는 동등성 비교를 위한 메서드가 맞습니다. 해당 테스트에서 isEqualsTo()를 사용한 이유에 대해서는 다음 링크(클릭)을 참고해주십쇼!
2) 먼저 관련된 테스트 코드를 보면 한 번 영속성 컨텍스트를 종료하고 다시 조회했기 때문에, 같은 영속성 컨텍스트 내 조회가 아닙니다 => 따라서 동일성 보장이 되지 않습니다.
또한 @Data 속 @EqualsAndHashCode 를 통해 객체의 동등성 보장을 해줄 수 있는 것은 맞습니다. 다만 해당 Member 엔티티는 객체 타입도 속성으로 갖고 있습니다. (Address, List<Order>)
특히 List<Order> orders 필드는 Member 객체를 생성할 때마다 새로운 객체를 할당하고 있습니다. 이러면 @Data 내부의 @EqualsAndHashCode 가 자동으로 오버라이딩 해준 equals(), hashcode()로는 동등성 비교가 되지 않을 수 있습니다.
그래서 hi_man159 님께서는 @EqualsAndHashCode의 onlyExplicitlyIncluded 속성과, @EqualsAndHashCode.Include 애노테이션을 사용해서 id 필드만 가지고 비교하도록 설정하셨습니다. 그래서 같은 테스트의 두 member 객체는 같은 id 값을 가지고 있기 때문에 변경하신 후에 테스트 코드가 통과하는 것입니다.
감사합니다.