[JPA] @OneToMany 단방향 매핑 시 고려해야 하는 것들

🌱 들어가기 전

JPA에서 @OneToMany 단방향 매핑보다는 다대일 양방향 매핑을 권장한다는 말을 보았을 것이다.

하지만, 객체지향으로 코드를 설계하다 보면 다대일의 상황보다는 1인 엔티티를 기준으로 N인 엔티티를 조회하는 경우가 더 많고, (적어도 내 경험에서는 그랬다) N인 엔티티가 굳이 1인 엔티티에 대한 정보를 몰라도 됐던 적이 많았다. 그러다 보니 자연스럽게 일대다 단방향 매핑을 많이 사용했었는데, 왜 그랬던 것인지 궁금해서 나름대로 실험을 해보고자 한다.

(ex. 게시글과 게시글 이미지의 관계에서, 게시글 이미지를 기준으로 게시글 정보를 찾아오는 것보다는 게시글을 기준으로 게시글 이미지 정보를 가져오는 게 더 많았음)

 

---

 

🌱 기본 엔티티 설계하기

@Entity
class Board(
    @Id @GeneratedValue(strategy = GenerationType.IDENTITY)
    val id: Long = 0L,

    @Embedded
    val title: BoardTitle,

    @Embedded
    val content: BoardContent,

    @Embedded
    var boardTags: BoardTags = BoardTags(Collections.emptyList())
) {

    fun addTag(boardTag: BoardTag) {
        boardTags.addTag(boardTag)
        boardTags = BoardTags(boardTags.tags)
    }
}

하나의 게시글에 제목과 내용 정보가 존재하며, 게시글 태그에 대한 정보가 1:N으로 구성된 엔티티다.

BoardTitle과 BoardContent는 VO이기 때문에 별도로 첨부하지는 않겠다.

여기서 게시글 태그 엔티티에 대해서 어떤 식으로 설정하는지에 따라서 결과가 달라지게 된다.

 

---

 

🌱 조인 테이블을 생성하여 일대다 관계 구성하기

@Embeddable
class BoardTags(
    tags: MutableList<BoardTag> = Collections.emptyList()
) {

    @OneToMany(fetch = FetchType.LAZY)
    val tags: MutableList<BoardTag> = tags.toMutableList()

    fun addTag(boardTag: BoardTag) {
        tags.add(boardTag)
    }
}

단순히 @OneToMany 어노테이션만 달았을 때, 생성된 테이블 구조를 보면 board_tags라는 별도의 조인 테이블이 생성된다.

여기서 board_tags에는 board_id와 tags_id라는 필드가 추가되었다. 여기서 board_id의 네이밍은 BoardTags를 가지고 있는 엔티티 (board)의 이름 + _id를 합친 것이고, tags_id의 네이밍은 @OneToMany로 선언한 필드명 (tags) + _id를 붙인 형태이다.

 

---

✔️ 저장 테스트

@Test
@Rollback(false) // 테스트 환경에서 롤백되는 것을 방지 
fun save() { 
    val 태그1 = BoardTag(name = "태그1")
    val 태그2 = BoardTag(name = "태그2")
    boardTagRepository.save(태그1)
    boardTagRepository.save(태그2)

    val board = Board(
        title = BoardTitle("제목"), content = BoardContent("내용")
    )
    board.addTag(태그1)
    board.addTag(태그2)

    boardRepository.save(board)
}

가장 먼저, 게시글 태그와 게시글에 대해서 insert 하는 쿼리가 발생한다.
이때, 게시글 태그 저장 시 board_id에 대한 컬럼은 채워지지 않고 name, id에 대해서만 삽입된다.
cf) 키 전략이 IDENTITY이기 때문에 save 시 쿼리가 발생한다.

이후, flush 시점에서 조인 테이블에 위와 같이 insert 쿼리가 발생한다.
즉, 쿼리가 총 5번이나 나가게 되는 것이어서 상당히 비효율적이다.

 

---

✔️ 삭제 테스트

게시글에 대한 태그를 삭제하는 테스트이다.
이때, 게시글에 존재하는 태그 정보를 제거하고, 그 다음 게시글의 태그 정보를 제거한다.

@Test
@Rollback(false)
fun delete() {
    // 저장 로직
    val 태그1 = BoardTag(name = "태그1")
    val 태그2 = BoardTag(name = "태그2")
    boardTagRepository.save(태그1)
    boardTagRepository.save(태그2)

    val board = Board(title = BoardTitle("제목"), content = BoardContent("내용"))
    board.addTag(태그1)
    board.addTag(태그2)

    boardRepository.save(board)
    entityManager.flush()
		
		/** 제거 로직 */
    val savedBoard = boardRepository.findById(1L).get()
    savedBoard.boardTags.tags.removeAt(0) // 필수!
    boardTagRepository.deleteById(1L)
}

기본적으로 태그 정보를 제거하려면 deleteById를 사용해야 한다고 생각할 수 있다. 하지만, 바로 deleteById를 사용하게 되면 조인 테이블에 걸려 있는 외래키에 의해서 board_tag 테이블에 있는 필드를 바로 제거할 수 없다.
그래서 board에 존재하는 tag 리스트에서 removeAt을 통해 1차적으로 조인 테이블에 대해서 제거를 해야 한다. (savedBoard.boardTags.tags.removeAt(0))

쿼리를 보면, 우선 조인 테이블인 board_tags에 대해서 delete 쿼리가 발생한다. 이때, board_id를 기준으로 제거하기 때문에 board_tags에 저장된 2개의 레코드 모두가 제거된다. 이후, 제거되지 않은 남은 레코드에 대해 (tags_id = 2인 레코드) 다시 삽입하는 과정이 발생한다. 만약, board_id = 1인 레코드가 5개가 있었다면 5개 모두에 대해 제거하고, 4개에 대해서 추가적인 insert 쿼리가 발생하여 더 불필요한 쿼리가 발생하였을 것이다.

최종적으로 위의 과정이 끝나고 board_tag에 대해서 최종적인 태그 제거 쿼리가 발생한다.

결과적으로 insert 쿼리로 인해서 원하지 않는 쿼리가 엄청 나갈 수도 있다는 특징을 가진다.

 

---

 

🌱 조인 테이블을 없애보기

조인 테이블에 의해서 insert 쿼리가 발생한 것이라면, 조인 테이블 자체를 없애면 되지 않을까?

@Embeddable
class BoardTags(
    tags: MutableList<BoardTag> = Collections.emptyList()
) {

    @OneToMany(fetch = FetchType.LAZY)
		@JoinColumn(name = "board_id")
    val tags: MutableList<BoardTag> = tags.toMutableList()

    fun addTag(boardTag: BoardTag) {
        tags.add(boardTag)
    }
}

@JoinColumn을 통해서 board_tag에 명시적으로 board에 대한 아이디를 저장할 수 있는 필드를 지정해주면 된다.
1:N 관계에서 외래키는 항상 N 테이블에 걸리기 때문에 n쪽에서 column 정보를 지정해준다.

생성된 테이블을 보면, 이번에는 조인 테이블 대신 board_tag 테이블에 board 정보를 지정하기 위한 board_id 정보가 추가된 것을 볼 수 있다.

 

---

✔️  저장 테스트

@Test
@Rollback(false) // 테스트 환경에서 롤백되는 것을 방지 
fun save() { 
    val 태그1 = BoardTag(name = "태그1")
    val 태그2 = BoardTag(name = "태그2")
    boardTagRepository.save(태그1)
    boardTagRepository.save(태그2)

    val board = Board(
        title = BoardTitle("제목"), content = BoardContent("내용")
    )
    board.addTag(태그1)
    board.addTag(태그2)

    boardRepository.save(board)
}

먼저, 태그 2개가 저장된 결과이다.
마찬가지로 name, id만 값이 채워져서 board_id에 대한 컬럼은 null 값을 가지게 된다.

그리고, 게시글에 대한 insert 쿼리가 발생한다.

하지만, 여기서 문제가 발생한다. board_tag에 대해 추가적으로 업데이트 쿼리가 발생한 것이다.

이는 처음에 board_tag를 저장할 때 board_id에 대한 정보가 없는 상태였기 때문에 flush 시점에 board.addTag()로 인해 추가된 정보를 바탕으로 업데이트를 하게 된 것이다.

위와 같이 @OneToMany 단방향에서는 데이터 저장 시 업데이트 쿼리가 발생할 수 있다는 단점이 있다.

 

---

 

✔️  삭제 테스트

@Test
@Rollback(false)
fun delete() {
    // 저장 로직
    ...

    // 강제 flush -> update 쿼리 발생
    entityManager.flush()

    // 조회 -> 영속성 컨텍스트에서 발생
    val savedBoard = boardRepository.findById(1L).get()
	
   // 보드에 존재하는 보드 태그 제거
    savedBoard.boardTags.tags.removeAt(0)
    
   // 보드 태그 제거
    boardTagRepository.deleteById(1L)
}

entityManager.flush 이후의 로직에서 발생하는 쿼리이다.
저장 후 영속성 컨텍스트에서 게시글을 조회한 뒤, 해당 게시글에 연관된 태그를 제거하였다. removeAt(0)을 진행하게 되면 게시글 기준으로 ‘게시글의 첫 번째 태그 정보가 제거’ 된 것이기 때문에 id = 1인 board_tag에 존재하는 board_id를 null로 세팅하는 쿼리가 발생한다.

 

이는 사실 Hibernate의 flush 순서와 좀 더 가까운 문제이다. Hibernae에서 자식 엔티티를 FK 없이 저장하고 컬렉션에 대해 처리를 하게 되면 FK에 대한 update 쿼리가 발생하기 때문이다. 현재 테이블 구조 상 FK가 걸리지 않아서 FK가 없는 상태니까 update 연산이 먼저 발생하고 엔티티에 대한 delete가 발생한 것이다.

cf) 참고로, update - delete 모두 flush 시에 발생하며 실제로 board_tag를 제거하지 않는다면 (deleteById) 두 쿼리 모두 발생하지 않는다. delete 시에 추가로 update 쿼리가 발생하는 느낌이다.

 

💡 Hibernate의 flush 순서는 다음과 같다.

1. OrphanRemovalAction
2. AbstractEntityInsertAction
3. EntityUpdateAction
4. QueuedOperationCollectionAction
5. CollectionRemoveAction
6. CollectionUpdateAction
7. CollectionRecreateAction
8. EntityDeleteAction

 

+ 무조건 '제거 행위'를 한다고 해서 update 쿼리가 발생하는 것은 아니다.

@Test
@Rollback(false)
fun delete() {
    // 저장 로직
    ...

    // 강제 flush -> update 쿼리 발생
    entityManager.flush()

    // 조회 -> 영속성 컨텍스트에서 발생
    val savedBoard = boardRepository.findById(1L).get()

    // 보드 태그 제거
    boardTagRepository.deleteById(1L)
}

하지만, removeAt()을 통해서 제거하지 않는다면 단순한 delete 쿼리만 발생한다.

단순히 boardTag의 id 값만을 참고하여 delete를 하기 때문에, board_id에 대한 정보가 딱히 없기 때문이다. (이전에는 게시글을 기준으로 태그 정보를 제거하였기 때문)

그래서 삭제 시에 update 쿼리가 무조건적으로 발생한다는 말은 틀린 말이다.

 

---

 

🌱 그렇다면, 일대다 단방향은 아예 쓰면 안 되는 걸까? - updatable = false 지정하기

그렇다면 우리는 항상 일대다 단방향을 사용하면 이렇게 update 쿼리를 봐야 하는 것일까?

update 쿼리를 없애고 싶을 것이다. 그렇다면, 추가적으로 board_id에 대한 업데이트가 진행되지 않도록 쿼리 자체에 updatable에 대한 조건을 false로 지정해보자.

@Embeddable
class BoardTags(
    tags: MutableList<BoardTag> = Collections.emptyList()
) {

    @OneToMany(fetch = FetchType.LAZY)
    @JoinColumn(name = "board_id", updatable = false)
    val tags: MutableList<BoardTag> = tags.toMutableList()

    ...
}

위와 같이 updatable=false를 지정하게 되면, board_tag 테이블에 존재하는 board_id 필드는 수정 불가능 상태가 된다.

즉, 한 번 지정된 연관관계를 다시 세팅하는 것이 불가능하게 된 것이다.

 

---

 

✔️  저장 테스트

@Test
@Rollback(false)
fun save() {
    val 태그1 = BoardTag(name = "태그1")
    val 태그2 = BoardTag(name = "태그2")
    boardTagRepository.save(태그1)
    boardTagRepository.save(태그2)

    val board = Board(
        title = BoardTitle("제목"), content = BoardContent("내용")
    )
    board.addTag(태그1)
    board.addTag(태그2)

    boardRepository.save(board)
}

update 쿼리는 발생하지 않지만, 처음 board_tag를 삽입할 때 board_id에 대한 정보가 지정되지 않는 상태로 insert가 된 것을 볼 수 있다. 추후 board가 삽입되더라도 계속 board_tag의 board_id는 계속 null로 남게 되는 것이다.

 

---

 

✔️  삭제 테스트

@Test
@Rollback(false)
fun delete() {
    // 저장 로직
    ...

    // 강제 flush -> update 쿼리 발생
    entityManager.flush()

    // 조회 -> 영속성 컨텍스트에서 발생
    val savedBoard = boardRepository.findById(1L).get()
		
    // 보드에 존재하는 보드 태그 제거
    savedBoard.boardTags.tags.removeAt(0)

    // 보드 태그 제거
    boardTagRepository.deleteById(1L)
}

하지만, 삭제 테스트에서는 보드에 존재하는 태그 정보를 removeAt으로 제거하더라도 update 쿼리가 발생하지 않는다!

insert 시 이미 board_id가 null이기 때문에 별도의 update 쿼리가 발생할 필요가 없어서 그냥 delete 쿼리만 나간 것이다.

 

 

---

 

🌱 board_id도 값이 채워졌으면 좋겠어! - nullable = false 지정해주기

하지만, 위의 방법은 연관관계가 세팅되지 않으니까 매우 찝찝하다.

board_id가 null인 것이 마음에 들지 않는 것이니까, 애초에 null 값이 들어오지 않도록 만들어보자.

@Embeddable
class BoardTags(
    tags: MutableList<BoardTag> = Collections.emptyList()
) {

    @OneToMany(fetch = FetchType.LAZY)
    @JoinColumn(name = "board_id", updatable = false, nullable = false)
    val tags: MutableList<BoardTag> = tags.toMutableList()
		...
}

 

✔️  저장 테스트

@Test
@Rollback(false)
fun save() {
    val 태그1 = BoardTag(name = "태그1")
    val 태그2 = BoardTag(name = "태그2")
    boardTagRepository.save(태그1)
    boardTagRepository.save(태그2)

    val board = Board(
        title = BoardTitle("제목"), content = BoardContent("내용")
    )
    board.addTag(태그1)
    board.addTag(태그2)

    boardRepository.save(board)
}

null 값이 저장되지 않아 원하는 결과가 나올 것 같다고 예상했지만, 위와 같이 오류가 발생한 것을 볼 수 있다.

이는, board_tag에 태그 정보가 저장하는 시점에 board_id에 대한 정보가 들어가야 하는데 현재는 board에 대한 정보가 하나도 없으니 null 값이 들어가려다가 제약 조건 위반으로 인해 예외가 발생한 것이다.

 

---

 

🌱 태그 정보가 저장될 때 게시글 정보도 함께 저장할래! - CascadeType 지정하기

그렇다면, board_tag가 저장하는 시점에 board에 대한 정보를 알면 되는 것이 아닐까?
하지만, 우리는 board → board_tag로의 단방향 관계만 가지도록 만들고 싶기 때문에 board_tag가 board에 대한 정보를 알지 않기를 바란다. 이를 위해서는, board_tag를 알고 있는 board가 저장되는 시점에 태그에 대한 정보도 함께 저장되도록 만들 수 있다.

@Embeddable
class BoardTags(
    tags: MutableList<BoardTag> = Collections.emptyList()
) {

    @OneToMany(fetch = FetchType.LAZY, cascade = [CascadeType.PERSIST])
    @JoinColumn(name = "board_id", updatable = false, nullable = false)
    val tags: MutableList<BoardTag> = tags.toMutableList()

    ...
}

위와 같이 cascade 옵션을 활용하여 PERSIST로 지정해주자.
이러면 board가 저장되는 시점에 board_tag 정보도 함께 알게 된다.

 

---

✔️  저장 테스트

기존의 저장 로직을 변경하여, board가 저장될 때 board_tag도 함께 지정하여 저장해보자.

@Test
@Rollback(false)
fun save_casacde() {
    val boardTags = mutableListOf(BoardTag(name = "태그1"), BoardTag(name = "태그2"))
    val board = Board(
        title = BoardTitle("제목"), content = BoardContent("내용"),
        boardTags = BoardTags(boardTags)
    )
    boardRepository.save(board)
}

먼저, board에 대한 정보가 저장되는 insert 쿼리가 발생하는 것을 볼 수 있다.

그리고, board_id가 1로 채워진 board_tag에 대한 insert 쿼리가 발생하는 것을 볼 수 있다.
즉, update 쿼리가 발생하지 않으면서 우리가 원하는대로 잘 동작하는 것이다.

 

---

 

🌱 @OneToMany 양방향

처음부터 양방향으로 설정하게 된다면 별도의 설정 필요 없이도 잘 동작한다.

그러나, 양방향 연관관계를 설정하기 위한 연관관계 편의 메서드가 존재해야 한다.

@Entity
class Board(
    @Id @GeneratedValue(strategy = GenerationType.IDENTITY)
    val id: Long = 0L,

    @Embedded
    val title: BoardTitle,

    @Embedded
    val content: BoardContent,

    @Embedded
    var boardTags: BoardTags = BoardTags(Collections.emptyList())
) {

    fun addTag(boardTag: BoardTag) {
        boardTag.board = this // here!
        boardTags.addTag(boardTag)
        boardTags = BoardTags(boardTags.tags)
    }
}

@Embeddable
class BoardTags(
    tags: MutableList<BoardTag> = Collections.emptyList()
) {

    @OneToMany(fetch = FetchType.LAZY, mappedBy = "board")
    val tags: MutableList<BoardTag> = tags.toMutableList()
    
    ...
}

@Entity
class BoardTag(

    @Id @GeneratedValue(strategy = GenerationType.IDENTITY)
    val id: Long = 0L,

    val name: String,

    @ManyToOne(fetch = FetchType.LAZY)
    var board: Board? = null
) {
	...
}

addTag() 메서드에서 연관관계를 세팅해주기 위해 boardTag.board = this라는 메서드를 추가해주었다.

 

---

 

✔️ 저장 테스트

@Test
@Rollback(false)
fun save() {
    val 태그1 = BoardTag(name = "태그1")
    val 태그2 = BoardTag(name = "태그2")

    val board = Board(
        title = BoardTitle("제목"), content = BoardContent("내용")
    )
    board.addTag(태그1)
    board.addTag(태그2)

    boardRepository.save(board)
    boardTagRepository.save(태그1)
    boardTagRepository.save(태그2)
}

양방향 연관관계가 설정되었기 때문에 태그를 먼저 저장하는 대신에, 게시글에 대해서 먼저 저장해준다.
이때 board.addTag() 시 board에 대한 연관관계도 설정되기 때문에 자연스럽게 boardTag가 저장되는 시점에 board에 대한 정보를 알게 되어 insert 시 업데이트 쿼리가 발생하지 않는다.

실제로 쿼리 정보를 보면, 먼저 게시글에 대한 insert 쿼리가 발생한다.

그리고, board_tag에 대해서 insert 쿼리가 발생할 때도 board_id에 대한 정보가 잘 채워져서 삽입되는 것을 볼 수 있다.

 

---

 

✔️ 삭제 테스트

@Test
@Rollback(false)
fun delete_bidirection() {
    // 저장 로직
    ...

    // 조회 -> 영속성 컨텍스트에서 발생
    val savedBoard = boardRepository.findById(1L).get()

    // 보드에 존재하는 보드 태그 제거
    savedBoard.boardTags.tags.removeAt(0)

    // 보드 태그 제거
    boardTagRepository.deleteById(1L)
}

이때도 단순히 board_tag에 대한 delete 쿼리 한 번만 발생하게 된다.
tags.removeAt(0)을 진행하더라도 외래키 제약조건으로 인해서 update 쿼리가 발생하지 않고 바로 엔티티에 대한 delete가 발생하게 된다.

 

---

 

💡 결론

- @OneToMany 단방향 관계에서는 불필요한 update 쿼리가 발생할 수 있다.
- 이를 해결하기 위해서는 nullable = false, updatable = false를 지정해주고 부모 엔티티가 영속화될 때 자식 엔티티도 함께 영속화될 수 있도록 PERSIST 옵션을 지정하자.
- 그런 하위 관계가 아니라면 양방향 관계를 고려하자.

일대다 단방향은 부모 엔티티와 자식 엔티티의 생명주기가 같을 경우만 사용하도록 하자! (완전한 하위 관계일 때)

그게 아니라면 양방향으로 설정하거나, 아니면 그냥 엔티티끼리 연관관계를 가지는 게 아니라 단순히 id 값을 필드로 가지도록 만들 것 같다.