[Spring] JPA Entity

🔫 일정 관리 앱 Develop API 를 구현하며 겪은 문제점과 해결방법, 새로 알게된 점을 기록합니다.

🥅 목표

• ERD 를 바탕으로 JPA가 관리하는 Entity 클래스를 생성
  

JPA Auditing ( BaseEntity )

관계형 데이터베이스(RDB) 테이블에 매핑할 때 도메인들이 공통적으로 가지고 있는 필드 (생성일, 수정일) 같은 필드 및 컬럼이 존재.

이러한 공통 필드를 중복없이 사용하기 위해 JPA에서 Auditing을 제공한다. Audit은 감시하다, 감사하다 의 뜻으로 Spring JPA에서 시간에 대한 값을 자동으로 넣어줄 때 유용하다.

@SpringBootApplication 클래스

@EnableJpaAuditing
@SpringBootApplication
public class JpaScheduleApplication {

    public static void main(String[] args) {
        SpringApplication.run(JpaScheduleApplication.class, args);
    }

}

@EnableJpaAuditing 어노테이션을 추가하여 JPA Auditing 활성화

BaseEntity

@Getter
@MappedSuperclass
@EntityListeners(AuditingEntityListener.class)
public abstract class BaseEntity {
    @CreatedDate
    @Column(updatable = false)
    private LocalDateTime createdAt;

    @LastModifiedDate
    private LocalDateTime updatedAt;

    private LocalDateTime deletedAt;
}

• 필드: 생성일, 수정일
• 모든 도메인이 삭제여부에 대한 값을 가지고 있으므로 deletedAt 필드를 추가하였다. (Soft Delete)
  • default: null
  • Entity가 삭제될 때 시간을 저장

어노테이션	설명
@MappedSuperclass	JPA Entity 클래스들이 해당 추상 클래스를 상속할 경우 추상클래스의 필드를 컬럼으로 인식
@EntityListeners(AuditingEntityListener.class)	해당 클래스에 Auditing 기능을 포함
@CreatedDate	Entity가 생성되어 저장될 때 시간이 자동 저장
@LastModifiedDate	조회한 Entity의 값을 변경할 때 시간이 자동 저장

🔗 참고
JPA Auditing 기능이란?

JPA 의 Entity는 기본 생성자가 반드시 필요하다.

Entity 클래스에 기본 생성자가 없을 경우, JpaSystemException이 발생한다.

repository에서 해당 엔티티의 데이터를 가져올 때 기본 생성자가 필요하다. JPA가 DB에서 데이터를 조회하고 객체로 매핑하여 반환하는 로직에 Java Reflection 이 적용되었기 때문이다.

JPA가 관리하는 @Entity로 선언하면 JPA는 Java Reflection 이 적용될 수 있는지 체크하여 컴파일 에러를 표시한다.

Java Reflection

구체적인 클래스 타입을 알지 못해도 그 클래스 정보(메서드, 타입 등)에 접근할 수 있도록 해주는 Java API 이다.

일반적으로 캡슐화가 적용된 객체에 데이터를 넣기 위해서 new 키워드(생성자)를 사용하거나, setter를 사용하여 데이터를 넣는다.

reflection 을 사용하면 private 접근 제어자를 가진 메서드에도 접근이 가능하다.

• static 영역에 저장되어있는 클래스 정보에 접근
  ➕ org.springframework.util.ReflectionUtils
  
  → Modifier(제어자)가 Public이 아니라면 인자로 받은 Method를 setAccessible(true) : 접근 가능하도록 만든다.

• 접근 가능(public)하도록 만든 다음 기본 생성자를 통해 생성된 객체 필드, 메서드에 직접 접근하여 값을 변경한다.

💫 Controller에서 @RequestBody을 바인딩하여 JSON 문자열의 값을 받을 때 setter 메서드를 만들지 않아도 객체에 저장하는 이유도 Java Reflection이 기본생성자를 통해 객체를 생성한 후 필드 값을 강제로 매핑해주기 때문이다.

이러한 이유로 JPA는 Java Reflection을 사용하기 위해 기본 생성자를 반드시 생성하도록 강제한다.

🔗 참고
JPA의 Entity는 기본 생성자가 왜 반드시 필요할까?

즉시 로딩과 지연 로딩

Schedule 과 Member 사이에 @ManyToOne(N:1) 관계로 매핑되어 있을 경우,@ManyToOne 어노테이션에 fetch 타입을 줄 수 있다.

즉시로딩(FetchType.EAGER)

• 특징
  • FetchType을 지정하지 않았을 경우 Default Type
  • JPA 구현체가 JOIN을 사용하여 SQL 한 번에 함께 조회해온다.

지연로딩(FetchType.LAZY)

@Getter
@Entity
@Table(name = "schedule")
public class Schedule extends BaseEntity {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;
    
    // ...

    @ManyToOne(fetch = FetchType.LAZY)
    @JoinColumn(name = "member_id")
    private Member member;

    public Schedule() {
    }
}

• 특징
  • 로딩되는 시점에 Lazy 로딩이 설정되어 있는 엔티티는 프록시 객체*로 가져온다.
  • 후에 실제 객체를 사용하는 시점에 (Member을 사용하는 시점에) 초기화 된다.
    • getMember()로 조회하면 프록시 객체를 조회한다.
    • getMember().getUsername() 으로 필드에 접근할 때 쿼리가 나간다.

✏️ 프록시 객체(Proxy)
JPA의 실제 엔티티를 필요할 때만 꺼내쓸 수 있도록 하는 가짜 객체이다.

• em.find(): 데이터베이스를 통해 실제 엔티티 객체 조회
• em.getReference(): 데이터베이스 조회를 미루는 가짜 객체 조회

🤔 어떤 전략을 써야할까?
대부분의 비스니스 로직에서 Schedule 과 Member 을 같이 사용하는 경우라면 LAZY 로딩이 손해
👉 조회를 한 번만 하는게 좋으니까 무조건 EAGER(즉시 로딩)을 사용하면 되나요?

• 실무에서는 가급적 지연 로딩만 사용한다.
• 즉시 로딩을 적용하면 예상하지 못한 SQL이 발생한다.
  • 실무에선 연관관계의 테이블이 많기 때문이다! 만약, @ManyToOne 필드가 5개라면 SQL에서도 JOIN이 5개 일어난다.
• 즉시 로딩은 JPQL에서 N+1 문제를 일으킨다.
  • 하나의 쿼리 에서 발생하는 추가 쿼리가 N개 (파생)
• 실무에서는 LAZY 로딩 전략을 가져간다.

• 비즈니스 로직에서 같이 사용하는 경우가 많을 경우, JPQL fetch join이나 엔티티 그래프 기능으로 해결하자.

🔗 참고
[JPA] 즉시 로딩과 지연 로딩(FetchType.LAZY or EAGER)
[JPA] 프록시

---

N + 1 해결책

즉시 로딩에서 발생하는 N + 1을 해결하는 방법 ≠ 지연 로딩

지연 로딩 + fetch join을 사용하더라도 N + 1 이 발생한다.

→ 해당 연결 Entity 에 프록시로 걸어두고, 결국 사용할 때 쿼리를 날리기 때문에 처음 조회 할 때는 N+1이 발생하지 않지만 연결 객체를 사용해야 한다면 프록시에 대한 쿼리가 또 발생한다.

• fetch join
• @EntityGraph

🫤 유의점

1. Pagination
   • ~ToOne 관계에서의 페이징 처리 가능
   • @BatchSize
   • @Fetch(FetchMode.SUBSELECT)
2. 둘 이상의 Collection fetch join(~ToMany) 불가능
   • 자료형을 Set 으로
   • @BatchSize

🔗 참고
JPA 모든 N+1 발생 케이스과 해결책

---

😎 학습 내용 추가예정