[JPA] save()시 식별자가 존재하는 경우 어떻게 동작할까? (feat. 코틀린에서 JPA 사용하기)

 

 

 

 

저는 지금까지 일반적으로 JPA를 사용하는 경우 @Id와 @GenerateValue, 그리고 Long 타입의 id를 사용하였습니다.

항상 id는 직접 할당하지 않았기에 save()시 id의 값은 항상 null이었습니다.

 

 

그러다 코틀린을 공부하고, 코틀린으로 JPA를 사용해보려던 중, 코틀린에서 id에 null을 허용하게끔 코드를 작성한다면 코드가 너무 더러워질 것 같아서, null을 사용하지 않는 방법을 찾아보았습니다.

 

 

생각보다 간단했는데 결론은 0으로 초기화 시켜주면 된다였습니다.

혹은 nullable 타입을 사용하는 것도 좋은 방법입니다.

 

이제부터 이러한 이유를 살펴보겠습니다.

 

 

 

 

 

 

 

 

 

 

 

 

 

save()는 어떻게 작동할까?

저장하려는 엔티티가 새로운 엔티티인 경우 persist를,
그렇지 않은 경우 merge를 진행합니다.

 

 

JpaRepository 사용 시 save()는 다음과 같이 구현되어 있습니다.

 

 

저장하려는 entity가 새로운 엔티티인 경우 persist를, 그렇지 않은 경우 merge를 진행합니다.

 

merge가 작동하는 방식은 다음 게시물(https://ttl-blog.tistory.com/167)을 참고해주세요.

결론적으로는 select 쿼리와 insert 쿼리가 두번 실행됩니다.

 

 

 

즉 save시 merge가 호출된다면 불필요한 쿼리가 1번 더 발생하므로 성능에 악영향을 미치며, 오류가 발생할 가능성도 있어보입니다.

 

이를 방지하기 위해 merge가 호출되지 않도록 해야 하는데, 새로운 엔티티를 판단하는 근거가 무엇인지 알아볼 필요가 있습니다.

살펴보도록 하겠습니다.

 

 

 

 

 

 

 

 

 

 

새로운 엔티티를 판단하는 근거

@Id의 타입이 primitive 타입이 아닌 경우에는 null인 경우만 새로운 엔티티로 판단합니다.

그러나 primitive 타입 중, 해당 Wrapper 클래스가 Number의 하위 타입인 경우(int, long 등)에는 해당 값이 0인 경우에만 이를 새로운 엔티티라 판단합니다.

 

entityInformation은 일반적인 경우 JpaMetamodelEntityInformation이 사용됩니다.

 

 

즉 JpaMetamodelEntityInformation의 isNew()가 사용되며, 다음과 같이 구현되어 있습니다.

versionAttribute가 정확히 무엇인지는 모르겠지만(죄송합니다..ㅠㅠ 아시는 분 계시면 알려주세요..ㅠㅠ),

디버깅한 결과 Optional.empty가 나와 항상 if문의 조건에 걸리게 됩니다.

 

 

 

super.isNew()는 AbstractEntityInformation에 정의되어 있으며, 다음과 같습니다.

 

id의 타입이 primitive 타입이 아닌 경우에는 null인 경우만 새로운 엔티티로 판단합니다.

 

그러나 primitive 타입 중 해당 타입의 Wrapper 클래스가 Number의 하위 타입인 경우(int, long 등)에는 해당 값이 0인 경우에만 이를 새로운 엔티티라 판단합니다.

 

 

 

 

 

 

 

 

 

 

 

다음으로 넘어가기 전에 지금까지 확인한 내용들이 올바른지 테스트를 해보도록 하겠습니다.

 

 

 

Test Case 1 - Id 필드가 Primitive 타입이 아닌 경우

예시로 사용할 Member 클래스입니다.

@Getter
@NoArgsConstructor(access = AccessLevel.PROTECTED)
@Entity
@Table(name = "member")
public class Member {
   @Id @GeneratedValue(strategy = GenerationType.IDENTITY)
   @Column(name = "member_id")
   private Long id;

   private String username;

   public void setId(Long id) {
      this.id = id;
   }

   public void setUsername(String username) {
      this.username = username;
   }
}

 

 

 

 

@SpringBootTest
@Transactional
public class MemberRepositoryTest {
   
   @Autowired private MemberRepository memberRepository;

   @Test
   public void saveTest() throws Exception {
      Member member = new Member();
       member.setUsername("username");
       member.setId(0L);

      memberRepository.save(member);
   }
}

 

이 경우에는 Member의 Id 필드의 값이 0이지만, Long 타입(primitive 타입이 아님)이므로 merge가 동작합니다.

 

실행되는 쿼리는 다음과 같습니다.

 

 

 

 

 

 

 

 

 

 

Test Case 2 - Id 필드가 Primitive 타입인 경우

이 경우 Member 클래스는 다음과 같습니다.

@Getter
@NoArgsConstructor(access = AccessLevel.PROTECTED)
@Entity
@Table(name = "member")
public class Member {
   @Id @GeneratedValue(strategy = GenerationType.IDENTITY)
   @Column(name = "member_id")
   private long id;

   private String username;

   public void setId(long id) {
      this.id = id;
   }

   public void setUsername(String username) {
      this.username = username;
   }
}

 

 

테스트코드는 달라진 부분이 없습니다.

@SpringBootTest
@Transactional
public class MemberRepositoryTest {
   
   @Autowired private MemberRepository memberRepository;

   @Test
   public void saveTest() throws Exception {
      Member member = new Member();
       member.setUsername("username");
       member.setId(0L);

      memberRepository.save(member);
   }
}

 

이 경우에는 Member의 Id 필드의 값이 0이며, primitive 타입이면서 long 타입이므로 persist가 동작합니다.

 

실행되는 쿼리는 다음과 같습니다.

 

 

 

 

 

 

 

 

 

 

 

 

코틀린에서의 경우

코틀린에서는 다음과 같이 사용하여야 합니다.

(아직 코틀린이 익숙치 않아 간단하게만 구현하였습니다. 나중에 이상한 부분이 있는 경우 수정하겠습니다.)

@Entity
class Member(
    val username: String
) {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    val id: Long = 0L
}

 

위와 같이 구현한 뒤 아래 테스트코드를 실행해 보겠습니다.

@SpringBootTest
@Transactional
class Tdd (){

    @Autowired private lateinit var memberRepository: MemberRepository

    @Test
    fun tdd() {
        val member = Member("username")
        memberRepository.save(member)
    }
}

 

id는 다음과 같이(var id: Long) 선언되어 있으므로 merge가 작동해야 할 것 같지만, 실제로는 persist가 실행됩니다. 

 

해당 이유를 알아보기 전에, id를 null 가능으로 만들어 주어 실행해 보도록 하겠습니다.

즉 다음과 같습니다

@Entity
class Member(
    val username: String
) {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    val id: Long? = 0L
}

 

 

merge가 작동하는 것을 알 수 있습니다.

 

 

 

이유는 코틀린을 조금만 공부하셨더라도 쉽게 추측할 수 있겠지만 다음과 같습니다.

 

null 가능 필드를 사용하면 Wrapper 타입이 사용되고, null 불가능 필드를 사용하면 primitive 타입이 사용되기 때문입니다.

 

 

 

 

 

 

 

nullable 경우 ( var id: Long? )

코틀린 파일 -> 바이트코드 디컴파일 시 다음과 같습니다.

 

 

 

 

 

 

 

null 불가능의 경우 ( var id: Long )

코틀린 파일 -> 바이트코드 디컴파일 시 다음과 같습니다.

 

 

 

 

 

 

 

 

 

사실 save의 동작 관련해서는 김영한 선생님의 책(자바 ORM 표준 JPA 프로그래밍)과 Spring Data JPA 강의에서도 설명해주신 부분입니다.

저는 다 듣고 정리까지 했는데도 기억을 못해서...ㅠㅠ

아무튼 감사합니당!!!

 

도움이 되셨다면 광고 한번씩 클릭해주시면 감사하겠습니다(여러번이면 더 좋아용)  :)

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Id로 Nullable 타입 사용하기

저는 nullalble을 사용하는 것이 무조건 좋지 않다고 생각하였는데, 공식 가이드(https://spring.io/guides/tutorials/spring-boot-kotlin/)의 예시에서는 Nullalble 타입을 사용했습니다.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

정리

 

save() 메서드

• 새로운 엔티티인 경우 - persist
• 새로운 엔티티가 아닌 경우 - merge

 

 

새로운 엔티티를 판단하는 방법

• 식별자가 객체인 경우 - null인지의 여부
• 식별자가 기본 타입인 경우 - 0으로 판단
• Persistable 인터페이스를 구현하여 판단하는 방법을 직접 정할 수 있습니다.
  • 다음 글 참고 (https://ttl-blog.tistory.com/852)

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Reference

https://docs.spring.io/spring-data/jpa/docs/2.3.0.RELEASE/reference/html/#repositories.nullability.kotlin

Spring Data JPA - Reference Documentation