아래와 같이 멤버를 삭제하는 로직에 @Transactional
애너테이션이 붙어 있어도 updatable = false
설정으로 인해서 이메일 변경사항은 db에 저장이 안되고 status만 변경된 상태로 저장되었다.
@AllArgsConstructor
@Transactional
@Service
public class MemberService {
private final MemberRepository memberRepository;
private final MemberUtils memberUtils;
public void deleteMember(String email) {
Member findMember = memberUtils.get(email);
String newEmail = "del_" + findMember.getId() + "_" + findMember.getEmail();
findMember.setMemberStatus(Member.MemberStatus.MEMBER_QUIT);
findMember.setEmail(newEmail);
memberRepository.save(findMember);
}
}
@NoArgsConstructor
@Getter
@Setter
@Entity
@Table(name = "member")
public class Member extends Auditable {
@Id // 식별자 등록
@GeneratedValue(strategy = GenerationType.IDENTITY) // 식별자를 자동으로 생성
private Long id;
private String uuid = UUID.randomUUID().toString();
@Column(nullable = false, updatable = true, unique = true)
private String nickName;
@Column(nullable = false, updatable = false, unique = true)
private String email;
@Column(length = 2147483647) // fixme : 길이 제한 걸릴 경우 length = -1 이나 columnDefinition = "TEXT" 타입 고려
private String profileImage;
private String password;
@Column(length = 50)
private String grade;
}
db에 반영되는 과정에서 적용이 안되는 현상이기 때문에 서버에서 오류가 발생하지 않고 @Transactional
이 동작하지 않는 것이다.
따라서 이러한 현상을 방지하기 위해서는 db에 반영되는 사항을 다시 호툴해서 비교하는 방식으로 정상적으로 db에 반영 된지 확인할 필요가 있을 것 같다.
여기서 테스트코드의 중요성을 다시한번 느낄 수 있었다. 휴먼에러에 대한 체크를 postman을 통해 확인하기는 했지만 응답이 처리되는 것만 확인하고 필드값 반영 여부를 확인하지 않았기에 발생했던 문제였다.
(해당 요청의 응답에서는 status만 확인 가능하고 바디값으로 변경 된 내용을 다시 보여주지 않았기 때문에 발생한 오류)