14장 컬렉션과 부가 기능

[LOG-INFO]

끄적끄적

Collection

• Hibernate는 Collection을 효율적으로 관리하기 위해 Entity를 영속 상태로 만들 때 원본 Collection(Java)을 감싸고 있는 내장 Collection(Hibernate)을 생성해서 사용하도록 참조를 변경함

  • 어떤 점에서 효율적일까? 성능을 말한 것 같진 않고, 추상화 시킴으로써 관리가 용이해짐을 말하는건가?

  • 내장 Collection은 원본 Collection을 감싸고 있어서 Wrapper Collection이라고도 불린다
  • Collection, List -> PersistentBag (중복 O, 순서 X)
    • 중복 Entity 있는지 비교하지 않고 단순히 저장만 함

      • Entity를 추가해도 지연 로딩된 Collection을 초기화하지 않음?

  • List + @OrderColumn -> PersistentList (중복 O, 순서 O)
    • DB에 저장할 때 순서 값을 저장해서 조회할 때 사용함

      • 오 처음�앎.

      • 근데 역시 실무에서 잘 사용하지 않는군. ArrayList에서 중간에 끼워넣거나 삭제할 때의 성능상 단점과 같은 이유군.

  • Set -> PersistentSet (중복 X, 순서 X)
    • 중복 Entity 있는지 비교해야 함

      • Entity를 추가할 때 지연 로딩된 Collection을 초기화 함?

  • 하이버네이트는 이런 특징 때문에 컬렉션을 사용할 때 즉시 초기화해서 사용하는 것을 권장한다??

    • `Collection members = new ArrayList();

Converter: Entity의 데이터를 변환해서 DB에 저장 가능

• y,n 대신 0,1로 저장하거나...
• date, datetime 대신 long으로 저장하거나...
• 근데 이런건 안티패턴이지 않나.. 굳이..? 코드 난독화를 위한건가?

Listener

• Use case
  • 모든 Entity를 대상으로 어떤 사용자가 삭제를 요청했는지 모두 로그로 남겨야 하는 요구사항
  • etc...
• 이벤트 종류
  • PrePersist
  • PostPersist
  • PostLoad - 2차 캐시에 저장되어 있어도 호출된다
  • PreUpdate
  • PostUpdate
  • PreRemove
  • PostRemove
• 이벤트 적용 위치
  • Entity에 직접 적용
  • 별도의 Listener 등록
  • 기본 Listner 사용
• 이벤트 호출 순서
  • 기본 Listener
  • Parent Class Listener
  • Listener
  • Entity

Entity Graph: 연관 Entity들을 함께 조회할 때 사용

• 이거 전에 사용하려 해봤는데 Entity Graph 쫌만 복잡해져도 사용하기 어려워졌던 것 같음
• 실무에서 안 쓸 것 같은데 쓰는 곳 있나??

[HaeUlNam]

끄적끄적

• 영속성 상태 전에는 Collection/List/Set이고, 영속성 상태가 되고 난 후에는 내장 컬렉션으로 변환된다. 내장 컬렉션은 Collection/List/Set을 품고 있는 Wrapper class이다.

• @ OrderBy - ORDER BY 절

• @ Converter - JPA 단에서 데이터를 변환해서 저장. 필드에서 converter를 지정할 수도 있고, Type에 따라 autoApply를 할 수도 있다.

• JPA 리스너: 엔터티의 생명주기에 따른 이벤트를 처리할 수 있음

  1. PostLoad: 엔티티가 영속성 컨텍스트에 조회된 직후
  2. PrePersist: 엔티티를 영속성 컨텍스트에 관리하기 직전
  3. PreUpdate: 엔티티를 데이터베이스에 수정하기 직전
  4. PreRemove: 엔터티를 영속성 컨텍스트에서 삭제하기 직전
  5. PostPersist/PostUpdate/PostRemove: 엔터티를 데이터베이스에서 저장/수정/삭제한 직후
     

• 이벤트 적용 위치

  • 엔티티에 직접 적용: @ PrePersist, @ PostPersist와 같은 annotation을 method에 붙여주면 됨.
  • 별도의 리스너 등록: @ EntityListeners annotation을 통해 listener 등록. 대상 엔티티를 파라미터로 받을 수 있음. 엔티티 직접 적용하는 것보다 별도의 리스너를 등록하는 것이 좋아보이긴 함.
  • 기본 리스너 사용

• 엔티티 그래프

  • 엔티티 조회 시점에 연관된 엔티티들을 함께 조회하는 기능. JPQL의 fetch join 대신 사용할 수 있어, JPQL은 데이터를 조회하는 기능만 수행하면 됨.

@NamedEntityGraph(name = "Order.withMember", attributeNodes = {
	@NamedAttributeNode("member")
})
@Entity
@Table(name="ORDERS")
public class Order {

	@ManyToOne(fetch= FetchType.LAZY, optional = false)
	@JoinColumn(name= "MEMBER_ID")
	private Member member;
}

질문

• 왜 내장 컬렉션으로 관리하나?
  • A. 이 메커니즘은 컬렉션의 지속적인 상태에 대한 변경 사항 추적과 컬렉션 요소의 지연 인스턴스화를 지원하도록 설계.

[minkukjo]

끄적끄적

• Hibernate는 컬렉션이 영속상태가 되면 이를 관리하는 PersistBag타입으로 변환해서 관리한다.
  • PersistBag는 컬렉션의 래핑 클래스임
• 하이버네이트는 이런 특징이 있어서, 컬렉션을 사용할 때 즉시 초기화해서 사용하는 편이 좋다고 한다.
• OrderColumn 애노테이션을 붙이면 컬렉션의 순서도 보장해준다고 한다. 단, 순서에 해당하는 컬럼이 존재해야한다고 한다.
• 근데 OlderColumn은 단점이 많아서 실무에서 잘 사용 안한다고 함.
  • Order 관리가 나이스하게 되지 않는 모양임. 추가 쿼리 발생 + 순서 뒤틀어지면 전체 업데이트 등
• OrderBy는 특정 컬럼을 기준으로 순서를 보장해줌. ( 이게 그나마 나은 듯?)
• Converetr는 엔터티 데이터를 변환해서 저장해주는 애노테이션이다.
  • 주로 Enum을 DB 값으로 매핑할 때 많이 사용한다.
• Converter(autoApply = true)를 주면 converter를 따로 지정 안해도 해당 타입의 모든 컬럼에 적용된다고 한다. (요건 좀 쓸만해보이기도 함!)
• JPA 리스너는 모든 엔터티를 대상으로 이벤트를 감지해주는 친구다.
• 여러 시점들을 제공해서, 해당 시점에 리스너가 불릴 수 있게 해준다. ( 이걸로 마이그레이션을 해보려고 시도한 적이 있음 )
• 엔터티 그래프는 엔터티 조회 시점에 연관된 엔터티를 같이 조회해오는 기능!
• 실제로 몇 번 언급한 적이 있지만, JPA의 연관관계 매핑은 상당히 까다롭고 복잡한데다가, 실효성도 떨어진다.
  • 객체로 쿼리를 다룰 수 있다는 점에서 매력적이긴 하지만, N+1 문제가 도사리고 있는데다가 마땅한 해법도 없다. ( fetch join이나 Entity Graph도 결함이 있음 )
  • 근데 그런 해법을 해결하려고 위 도구를 쓰는게 과연 맞는가? 싶은 의문도 있음
  • 얼마전에 팀에서 N+1 문제가 발생했는데, 원인이 1:1 연관관계 매핑으로 일어난 일이었다. ( 스터디때 조금 더 자세하게 소개 해보면 재밌을 듯 )

[MinJunKweon]

끄적끄적

• Hibernate에서 컬렉션 필드를 영속 상태로 만들 때, 하이버네이트의 PersistentBag 타입으로 변경해서 사용함

컬렉션 인터페이스	내장 컬렉션	중복 허용	순서 보관
Collection, List	PersistentBag	O	X
Set	PersistentSet	X	X
Lsit + @OrderColumn	PersistentList	O	O

• Collection, List는 엔티티를 추가할 때 중복된 엔티티가 있는지 비교하지 않고 단순히 저장만 하면 되기 때문에

  • 엔티티를 추가해도 지연 로딩된 컬렉션을 초기화하지 않는다.

  무슨말인지 이해를 못함..

• Set은 엔티티를 추가할 때 중복된 엔티티가 있는지 비교해야 하므로

  • 엔티티를 추가할 때 지연 로딩된 컬렉션을 초기화한다.

• List + @OrderColumn => 순서가 있는 컬렉션은 데이터베이스에 순서 값도 함께 관리함

• @OrderColumn의 단점

  • 1개의 Board에 N개의 Comment가 있다고 가정
  • 어노테이션은 Board 엔티티에 선언되지만, 컬럼은 Comment 테이블에 추가됨 (POSITION 컬럼)
  • Comment는 단순히 저장될 때, POSITION 값을 갖지 않아서 그대로 저장됨 (NULL). 이후 Board의 List에서 인덱스 값을 가지고 UPDATE하는 쿼리가 추가로 발생됨
  • List에서 값을 빼는 연산을 하게되면 이후 엔티티들의 순서를 모두 변경하는 UPDATE문을 수행
  • 디비 상에서 중간에 POSITION 값이 비는 경우, null로 List에 들어가게 됨. NPE 발생 가능

    코틀린에서 쓸 때는 반드시 Nullable로 선언해야겠네요

• @OrderBy

  • 엔티티 필드의 순서를 정렬하는 어노테이션
  • Set에 @OrderBy를 적용하면 순서 유지를 위해 하이버네이트에서 HashSet 대신 LinkedHashSet을 사용함

Converter

• 엔티티 -> DB / DB -> 엔티티 간에 데이터를 변환하는 방식
• @Converter(converter=BooleanToYNConverter.class) 같은 식으로 사용가능
• AttributeConverter<X(엔티티), Y(DB)> 인터페이스를 구현하는 클래스는 사용 가능
  • fun convertToDatabaseColumn(attribute: X): Y : 엔티티 -> DB 저장할 때
  • fun convertToEntityAttribute(dbData: Y): X : DB -> 엔티티 변환할 때. (단, dbData는 JDBC 드라이버에서 사용할 수 있도록 해야함)

리스너

• 특정 시점에 특별히 로그를 남기거나 로직을 추가해야하는 경우에 이벤트에 리스너를 달 수 있음
• 이벤트에서 식별 가능한 이벤트 종류

1. PostLoad

• 엔티티가 영속성 컨텍스트에 조회된 직후 또는 refresh를 호출한 후(2차 캐시에 저장되어 있어도 호출된다)

2. PrePersist

• persist() 메소드를 호출해서 엔티티를 영속성 컨텍스트에 관리하기 직전에 호출된다. 식별자 생성 전략을 사용한 경우 엔티티에 식별자는 아직 존재하지 않는다. 새로운 인스턴스를 merge 할 때도 수행된다.

3. PreUpdate

• flush나 commit을 호출해서 엔티티를 데이터베이스에 수정하기 직전에 호출된다.

4. PreRemove

• remove() 메소드를 호출해서 엔티티를 영속성 컨텍스트에서 삭제하기 직전에 호출된다. 또한 삭제 명령어로 영속성 전이가 일어날 때도 호출된다. orphanRemoval에 대해서는 flush나 commit 시에 호출된다.

5. PostPersist

• flush나 commit을 호출해서 엔티티를 데이터베이스에 저장한 직후에 호출된다. 식별자가 항상 존재한다. 참고로 식별자 생성 전략이 ICENTITY면 식별자를 생성하기 위해 persist()를 호출하면서 데이터베이스에 해당 엔티티를 저장하므로 이때는 persist()를 호출한 직후에 바로 PostPersist가 호출된다.

6. PostUpdate

• flush나 commit을 호출해서 엔티티를 데이터베이스에 수정한 직후에 호출된다.

7. PostRemove

• flush나 commit을 호출해서 엔티티를 데이터베이스에 삭제한 직후에 호출된다.

• 이벤트 적용 위치

  • 엔티티에 직접 적용
    • @PerPersist, @PostPersist 같은 어노테이션으로 엔티티에 메소드를 직접 구현하는 방식
    • 요런식으로 달 수 있다. - Baldung
  • 별도 리스너 등록
    • @EntityListeners 어노테이션을 엔티티 클래스 위에 적용하여 사용 가능
    • @EntityListeners로 지정할 수 있는 클래스는 위 @PrePersist 같은 어노테이션이 붙은 리스너 메소드를 가진 클래스면 가능하다.

      리스너용 인터페이스를 만드는게 좋아보이는데 왜 굳이 어노테이션으로 했을까..

  • 기본 리스너 사용
    • META-INF/orm.xml에 기본 리스너 등록 가능
    • 이렇게 할 수 있다고 함
  • 추가로 이런 방식도 있다고 함
    • @ExcludeDefaultListeners : 기본 리스너 무시
    • @ExcludeSuperclassListeners : 상위 클래스 이벤트 리스너 무시

• 여러 리스너가 있을 때 우선순위 (기본 리스너가 가장 높음)

  1. 기본 리스너
  2. 부모 클래스 리스너
  3. 리스너
  4. 엔티티

엔티티 그래프

• 엔티티 조회 시점에 연관된 엔티티들을 함께 조회하는 기능
• Named 엔티티 그래프
  • @NamedEntityGraph 어노테이션으로 정의
    • name : 엔티티 그래프의 이름을 정의함
    • attributeNodes : 함계 조회할 속성을 선택. @NamedAttributeNode를 인자로 받고, 함께 조회할 속성을 정의함
• em.find()에서 엔티티 그래프 사용
  • em.getEntityGraph() 메소드를 사용해서 정의
• subgraph
  • @NamedSubgraph 어노테이션을 사용해서 서브 그래프를 정의할 수 있음
• JPQL에서 엔티티 그래프 사용
  • setHint()를 통해 엔티티 그래프를 지정할 수 있음.
• 동적 엔티티 그래프
  • em.createEntityGraph()를 사용해서 동적으로 구성 가능
  • graph.addAttributeNodes()로 프로그래메틱컬하게 설정 가능
• 정리
  • ROOT에서 시작
    • 엔티티 그래프는 항상 조회하는 엔티티의 ROOT에서 시작해야함
      • Order 엔티티를 조회하는데, Member부터 시작하는 엔티티 그래프를 사용하면 안됨.
  • 이미 로딩된 엔티티
    • 영속성 컨텍스트에 해당 엔티티가 이미 로딩되어 있으면 엔티티 그래프가 적용되지 않음.

      이부분이 많이 실수할 거 같음

  • fetchgraph vs loadgraph
    • fetchgraph : 엔티티 그래프에 선택한 속성만 함께 조회함
    • loadgraph : 선택한 속성 + 글로벌 fetch 모드가 EAGER로 설정된 연관관계도 포함하여 조회

[LOG-INFO]

얼마전에 팀에서 N+1 문제가 발생했는데 -> 궁금합니다

[minkukjo]

해리 has invited you to join a video meeting on Google Meet.

Join the meeting: https://meet.google.com/wvz-etih-mua