[JPA] @ManyToOne

📌 @ManyToOne

이것은 테이블 간에 연관관계가 있을 때, 사용하는 것이에요. RDBMS에서는 FK를 통해 다른 Table을 참조할 수 있는 것이에요. 이 때, N:1, 1:N, N:M 등의 관계가 형성이 되는데, 예를 들어 Member (회원) Table과 Board (게시판) Table이 있을 때, 한 명의 회원은 여러개의 게시글을 남길 수 있는 것이에요.

그런데, 여기서 주의해야 할 점은 @ManyToOne도 있고, @OneToMany도 있는 것인데, 어떻게 구분해서 사용해야 할까요?

바로 참조를 할 Table 기준으로 생각을 하면 된답니다! Board Table이 Member Table을 참조할 것이고, Board Table이 N이기 때문에 Board Entity에서 @ManyToOne을 사용하면 되는 것이에요.

 

 

위의 Code는 SystemUseManual이라는 게시판과 Member Table을 연관 관계 지정을 해 준 것이에요.

작성자로 사용하기 위해 변수명은 writer라고 했답니다!

 

주니하랑은 현재 해당 게시판에 댓글 기능도 넣기 위해 따로 Entity를 분리한 것이에요.

 

 

근데 여기서 제가 잘 못 판단한 것이 있는 것이에요. 위에 Code를 보면 게시판과의 연관 관계를 위해 @ManyToOne을 쓰고, 댓글 작성자가 필요하닌까 당연히 Member Table과 또 연관관계를 맺어줘야 하는지 안 것이에요.

 

 

하지만 이건 엄청난 착각이고, 실수였답니다!

 

 

위에 left outer join으로 여러 Entity와 연관 관계를 맺어서 Data를 갖고 오는데, 보시다 시피 Member Entity를 두 번이나 Join하고 있는 것이에요!

 

 

 

위와 같이 Member에 대한 연관 관계를 없앤 뒤 다시 Test를 진행 해 볼 것이에요.

 

 

이번에는 정상적으로 딱! 한번만 Member Entity로 join을 하는 것을 확인할 수 있는 것이에요.

 

하.지.만 위에서 보는 바와 같이 SQL 문을 보면 Comment Table, UseManual Table, Member Table까지 모두 Join으로 처리하고 있는 것을 볼 수 있는 것이에요. Comment를 가져올 때, 매번 게시판(UseManual)과 Member까지 Join해서 가져올 필요가 많지는 않기 때문에 위와 같이 여러 Table을 Join으로 처리되는 상황은 좋지 않은 것이에요. 

 

 

    📍 fetch는 Lazy Loading을 사용하자!

위의 Query 실행 결과와 같이 특정 Entity를 조회할 때, 연관관계를 가진 모든 Entity를 같이 Loding하는 것을 'Eager Loding'이라고 하는 것이에요. 'Eager'는 '열렬한, 적극적인'이라는 뜻을 갖고 있고, 일반적으로 '즉시 로딩'이라고 표현하는 것이에요.

 

'즉시 로딩'은 한 번에 연관 관계가 있는 모든 Entity를 가져온다는 장점이 있으나, 여러 연관 관계를 맺고 있거나, 연관 관계가 복잡할수록 Join으로 인한 성능 저하를 피할 수 없는 것이에요.JPA에서 연관 관계의 Data를 어떻게 가져올 것인가를 fetch(패치)라고 하는데, 연관 관계 Annotation의 속성으로 'fetch' Mode를 지정한답니다!

즉시 로딩은 불 필요한 Join까지 처리해야 하는 경우가 많기 때문에 가능한 사용하지 않고, 그와 반대되는 'Lazy Loding'으로 처리하는 것이 좋은 것이에요. 'Lazy Loding'은 '지연 로딩, 게이른 로딩'이라고 부른답니다!

 

그러면 게시판(UseManul)을 한번 고쳐 보도록 할 것이에요.

 

 

UseManual Entity Class에서 수정된 부분은 @ManyToOne에 fetch 속성을 명시하고, FetchType.LAZY라는 지연 로딩을 적용한 부분인 것이에요. 그럼 다시 Test를 돌려 보도록 할 것이에요!

 

 

앗! 뭔가 문제가 발생한 것이에요! 발생한 Exception Message는 아래와 같은 것이에요.

 

이 말은 Data Base와 추가적인 연결이 필요하다는 것이에요.

 

지연 로딩 방식으로 로딩하기 때문에 UseManual Table만 가져와서 System.out.println()을 하는 것은 문제가 없지만, 

반응형

여기에서 문제가 발생하는 것이에요. manual.getWriter()는 member Table을 로딩해야 하는데, 이미 Data Base와 연결이 끝난 상태이기 때문에 Exception이 터지는 것이에요.

'no Session'이라는 메시지는 이런 경우 발생한답니다! 이 문제를 해결하기 위해 다시 한번 Data Base와 연결이 필요한데, @Transactional이 바로 이러한 처리에 도움을 주는 것이에요. Method 선언부에 이 Annotation을 넣어 보도록 할게요!

 

 

@Transactional 이 친구는 해당 Method를 하나의 '트랜잭션'으로 처리하라는 의미인 것이에요. 트랜잭션으로 처리하면 속성에 따라 다르게 동작하지만, 기본적으로는 필요할 때 다시 Data Base와 연결이 생성된답니다!

 

💡 참고 :

Transaction이란?

 

Hibernate: 
    select
        systemusem0_.no as no1_1_0_,
        systemusem0_.moddate as moddate2_1_0_,
        systemusem0_.regdate as regdate3_1_0_,
        systemusem0_.content as content4_1_0_,
        systemusem0_.title as title5_1_0_,
        systemusem0_.writer_id as writer_i6_1_0_ 
    from
        system_use_manual systemusem0_ 
    where
        systemusem0_.no=?
com.hongga.junyharang.domain.entity.manual.SystemUseManual@202b5293
Hibernate: 
    select
        member0_.id as id1_0_0_,
        member0_.moddate as moddate2_0_0_,
        member0_.regdate as regdate3_0_0_,
        member0_.email as email4_0_0_,
        member0_.grade as grade5_0_0_,
        member0_.name as name6_0_0_,
        member0_.password as password7_0_0_,
        member0_.phone as phone8_0_0_ 
    from
        member member0_ 
    where
        member0_.id=?
com.hongga.junyharang.domain.entity.member.Member@7137cd14
2021-10-05 18:41:40.137  INFO 17188 --- [    Test worker] o.s.t.c.transaction.TransactionContext   : Rolled back transaction for test: [DefaultTestContext@2ce86164 testClass = SystemUseManualRepositoryTest, testInstance = com.hongga.junyharang.repository.manual.SystemUseManualRepositoryTest@9ba167e, testMethod = 게시글_조회@SystemUseManualRepositoryTest, testException = [null], mergedContextConfiguration = [WebMergedContextConfiguration@5e8f9e2d testClass = SystemUseManualRepositoryTest, locations = '{}', classes = '{class com.hongga.junyharang.JunyharangApplication}', contextInitializerClasses = '[]', activeProfiles = '{}', propertySourceLocations = '{}', propertySourceProperties = '{org.springframework.boot.test.context.SpringBootTestContextBootstrapper=true}', contextCustomizers = set[org.springframework.boot.test.autoconfigure.actuate.metrics.MetricsExportContextCustomizerFactory$DisableMetricExportContextCustomizer@4c51cf28, org.springframework.boot.test.autoconfigure.properties.PropertyMappingContextCustomizer@0, org.springframework.boot.test.autoconfigure.web.servlet.WebDriverContextCustomizerFactory$Customizer@66ac5762, org.springframework.boot.test.context.filter.ExcludeFilterContextCustomizer@517d4a0d, org.springframework.boot.test.json.DuplicateJsonObjectContextCustomizerFactory$DuplicateJsonObjectContextCustomizer@1941a8ff, org.springframework.boot.test.mock.mockito.MockitoContextCustomizer@0, org.springframework.boot.test.web.client.TestRestTemplateContextCustomizer@6aa3a905, org.springframework.boot.test.context.SpringBootTestArgs@1, org.springframework.boot.test.context.SpringBootTestWebEnvironment@1e683a3e], resourceBasePath = 'src/main/webapp', contextLoader = 'org.springframework.boot.test.context.SpringBootContextLoader', parent = [null]], attributes = map['org.springframework.test.context.web.ServletTestExecutionListener.activateListener' -> true, 'org.springframework.test.context.web.ServletTestExecutionListener.populatedRequestContextHolder' -> true, 'org.springframework.test.context.web.ServletTestExecutionListener.resetRequestContextHolder' -> true, 'org.springframework.test.context.event.ApplicationEventsTestExecutionListener.recordApplicationEvents' -> false]]

 

Test 결과를 보면 처음에는 SystemUseManual Table만 로딩해서 처리하였으나, SystemUseManual.getWriter()를 하기 위해 member Table을 로딩하는 것을 볼 수 있는 것이에요. 지연 로딩을 사용하지 않았을 경우 자동을 SystemUseManual Table과 Member Table이 조인으로 처리된 것과는 차이가 있는 것을 알 수 있는 것이에요.

 

 

 

    📍 지연 로딩 ( lazy loding )의 장 / 단점

지연 로딩은 조인을 하지 않기 때문에 단순하게 하나의 테이블을 이용하는 경우에는 빠른 속도의 처리가 가능한 것이에요. 하지만, 위와 같이 필요한 순간에 쿼리를 실행해야 하기 때문에 연관 관계가 복잡한 경우 여러 번의 쿼리가 실행된다는 단점이 있는 것이에요.

따라서 보편적인 코딩 가이드는 '지연 로딩을 기본으로 사용하고, 상황에 맞게 필요한 방법을 찾는다' 인 것이에요.