'spring' 카테고리의 글 목록 (4 Page)

spring

[JPA 활용 1] 1. 프로젝트 환경설정

2022. 4. 17. 09:54

프로젝트 환경설정

프로젝트 생성
라이브러리 살펴보기
View 환경 설정
H2 데이터베이스 설치
JPA와 DB 설정, 동작확인

프로젝트 생성

스프링 부트 스타터(https://start.spring.io/)
사용 기능 : web, thymeleaf, jpa, h2, lonbok, validation
- groupId : jpabook
- artifactId : jpashop

스프링 부트 스타터 설정 필독!
스프링 부트 버전은 2.4.x 버전을 선택해주세요.
자바 버전은 11을 선택해주세요
Validation (JSR-303 validation with Hibernate validator) 모듈을 꼭! 추가해주세요.

사용 기능

web
- RESTful api, Spring MVC, Apache Tomcat 내장하고 있기 때문에 웹 애플리케이션을 만들 땐 꼭 추가해야되는 Dependency 입니다.
thymeleaf
- view template입니다.
- jsp를 사용하지 않는 이유는 성능면에서 좋지 않고, 스프링 부트에서도 권장하지 않기 때문입니다.
jpa
- Java Persistence API의 약자로 Spring Data와 Hibernate를 사용하는 ORM 표준 기술입니다.
h2
- MySQL과 같은 좋은 데이터베이스가 많지만, h2를 사용하는 이유는 MySQL은 설치하거나 하는 부분에서 까다롭고 강의의 목적이 아니기 때문에 강의에 좀 더 집중하기 위해 사용합니다.
- h2는 간단하게 웹 애플리케이션 실행할 때 데이터베이스를 내장해서 실행할 수 있고, 간단하게 교육용으로 장점이 많다고 합니다.
lombok
- 지루하게 반복하는 코드를 줄여줍니다.
- 예를들면, getter, setter 같은 경우 직접 코드를 작성하지 않고 @getter, @setter과 같은 어노테이션만 추가하면 기능을 사용할 수 있게 해줍니다. (사용해봤는데 정말 편리한 라이브러리인 것 같습니다.)

Lombok 설정

lombok을 사용하기 위해선 아래와 같은 설정을 해주어야합니다.

preference -> plugins -> lombok 검색 후 설치
preference -> annotation processors -> enable annotation processing 체크

스프링 부트 라이브러리 살펴보기

spring-boot-starter-web
- spring-boot-starter-tomcat : 톰캣 (웹서버)
- spring-webmvc : 스프링 웹 MVC
spring-boot-starter-thymeleaf : 타임리프 템플릿 엔진(View)
spring-boot-starter-data-jpa
- spring-boot-starter-aop
- spring-boot-starter-jdbc
  - HikariCP 커넥션 풀 (부트 2.0 기본)
- hibernate + JPA : 하이버네이트 + JPA
- spring-data-jpa : 스프링 데이터 JPA
spring-boot-starter : 스프링 부트 + 스프링 코어 + 로깅
- spring-boot
  - spring-core
- spring-boot-starter-logging
  - logback, slf4j

테스트 라이브러리

spring-boot-starter-test
- junit : 테스트 프레임워크 (자바 테스트)
- mockito : 목 라이브러리
- assertj : 테스트 코드를 좀 더 편하게 작성하게 도와주는 라이브러리 (보통 원하는 값과 결과 값이 일치하는지 테스트할 때 많이 써봄)
- spring-test : 스프링 통합 테스트 지원

핵심 라이브러리
- 스프링 MVC
- 스프링 ORM
- JPA, Hibernate
- 스프링 데이터 JPA
기타 라이브러리
- h2 데이터베이스 클라이언트
- 커넥션 풀 : 부트 기본은 HikariCP
- WEB(thymeleaf)
- 로깅 SLF4J & LogBack
- 테스트

참고 : 스프링 데이터 JPA는 스프링과 JPA를 먼저 이해하고 사용해야 하는 응용기술

View 환경 설정

thymeleaf 템플릿 엔진

thymeleaf 공식 사이트 : https://www.thymeleaf.org/
스프링 공식 튜토리얼 : https://spring.io/guides/gs/serving-web-content/
스프링부트 메뉴얼 : https://docs.spring.io/spring-boot/docs/2.1.6.RELEASE/reference/html/boot-features-developing-web-applications.html#boot-features-spring-mvc-template-engines

스프링 부트 thymeleaf viewName 매핑
- resources : templeates/ + {ViewName} + .html

@Controller
public class HelloController {

    @GetMapping("hello")
    public String hello(Model model){
        model.addAttribute("data", "hello!!!!");
        return "hello";
    }
}

thymeleaf 템플릿 엔진 동작 확인 (hello.html)

<!DOCTYPE HTML>
  <html xmlns:th="http://www.thymeleaf.org">
  <head>
      <title>Hello</title>
      <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
  </head>
<body>
<p th:text="'안녕하세요. ' + ${data}" >안녕하세요. 손님</p>
  </body>
  </html>

위치 : resources/templates/hello.html

참고 : spring-boot-devtools 라이브러리를 추가하면, html 파일을 컴파일만 해주면 서버 재시작 없이 View 파일 변경이 가능합니다.
인텔리제이 컴파일 방법 : 메뉴 Build -> Recompile

implementation 'org.springframework.boot:spring-boot-devtools' << 를 build.gradle에 추가해주면 됩니다.

H2 데이터베이스 설치

https://www.h2database.com
다운로드 및 설치
데이터베이스 파일 생성 방법
- jdbc:h2:~/jpashop (최소 한번)
- ~/jpashop.mv.db 파일 생성 확인
- 이후 부터는 jdbc:h2:tcp://localhost/~/jpashop 이렇게 접속

참고!
H2 데이터베이스는 꼭 1.4.199 버전 사용
실행할 때, permission denied된다면 "chmod 755 h2.sh" 친 다음 ./h2.sh로 실행

JPA와 DB 설정, 동작확인

김영한님은 application.properties 대신 yaml인 application.yaml을 사용하신다. 개인적으로 더 편리하다고 합니다. application.properties를 삭제하고 application.yml을 생성한 뒤 아래 코드를 추가해줍니다.

spring:
  datasource:
    url: jdbc:h2:tcp://localhost/~/jpashop
    username: sa
    password:
    driver-class-name: org.h2.Driver
jpa:
  hibernate:
    ddl-auto: create
  properties:
    hibernate:
      #show_sql: true
      format_sql: true
logging.level:
  org.hibernate.SQL: debug

spring.jpa.hibernate.ddl-auto : create
- 애플리케이션 실행 시점에 테이블을 drop하고, 다시 생성한다는 의미입니다.

참고: 모든 로그 출력은 가급적 로거를 통해 남겨야 합니다.
show_sql 옵션은 System.out에 하이버네이트 실행 SQL을 남기는 것이고,
org.hibernate.SQL 옵션은 logger를 통해 하이버네이트 실행 SQL을 남기는 것 입니다.
그렇기 때문에 show_sql은 주석처리해주었고, org.hibernate.SQL을 통해 로거로 로그를 확인할 수 있도록 했습니다.

yml 코드 작성법 등을 보고싶으면 아래 링크를 통해 레퍼런스 자료를 찾아보시는 걸 추천드립니다.

Spring Boot

Commercial support Business support from Spring experts during the OSS timeline, plus extended support after OSS End-Of-Life. Publicly available releases for critical bugfixes and security issues when requested by customers.

spring.io

실제 동작하는지 확인하기

회원 엔티티

@Entity
@Getter
@Setter
public class Member {

    @Id
    @GeneratedValue
    private Long id;
    private String username;
}

회원 리포지토리

@Repository
public class MemberRepository {

    @PersistenceContext
    private EntityManager em;

    public Long save(Member member){
        em.persist(member);
        return member.getId();
    }

    public Member find(Long id){
        return em.find(Member.class, id);
    }
}

테스트

@RunWith(SpringRunner.class)
@SpringBootTest
public class MemberRepositoryTest {

    @Autowired
    MemberRepository memberRepository;

    @Test
    @Transactional
    @Rollback(false)
    public void testMember() throws Exception {
        //given
        Member member = new Member();
        member.setUsername("memberA");

        //when
        Long saveId = memberRepository.save(member);
        Member findMember = memberRepository.find(saveId);
        
        //then
        Assertions.assertThat(findMember.getId()).isEqualTo(member.getId());
        Assertions.assertThat(findMember.getUsername()).isEqualTo(member.getUsername());
    }
}

@Transactional
- Entity 변경 작업은 모두 트랜잭션 내에서만 이루어져야합니다. Member는 Entity이기 때문에 Transactional을 추가하지 않으면 에러가 뜨게됩니다.
- 해당 어노테이션이 테스트에있으면 테스트가 끝난다음 바로 롤백을 하기 때문에 h2에 데이터가 남아있지 않습니다.
@Rollback(false)
- 위의 트랜잭셔널 어노테이션이 테스트에 있으면 바로 롤백이되어 h2-console에서 입력한 데이터를 볼 수 없습니다.
- 이러한 경우 위의 @Rollback(false) 어노테이션을 추가해주면 h2-console에서 입력한 데이터를 볼 수 있습니다.

주의! @Test는 JUnit4를 사용하시면 org.junit.Test를 사용해야 합니다. 만약 JUnit5 버전을 사용하면 그것에 맞게 사용하면 됩니다.

Entity, Repository 동작확인
jar 빌드해서 동작 확인

쿼리 파라미터 로그 남기기

김영한님 피셜로 어마어마한 꿀팁이라고 합니다. 개발할 때 엄청 편리하다고 합니다. jpa로 쓰면 답답한게 sql 나가는거랑 데이터베이스 커넥션 가져오는게 어느 타이밍에 되는지 궁금할 때가 많은데 이러한 궁금증을 해결해준다고합니다.
로그에 다음을 추가하기 org.hibernate.type : SQL 실행 파라미터를 로그로 남긴다.
외부 라이브러리 사용
- https://github.com/gavlyukovskiy/spring-boot-data-source-decorator

스프링 부트를 사용하면 아래 라이브러리만 추가하면 됩니다.

implementation 'com.github.gavlyukovskiy:p6spy-spring-boot-starter:1.5.6'

참고 : 쿼리 파라미터를 로그로 남기는 외부 라이브러리는 시스템 자원을 사용하므로, 개발 단계에서는 편하게 사용해도 됩니다. 하지만 운영 시스템에 적용하려면 꼭 성능테스트를 하고 사용하는 것이 좋습니다.

출처

실전! 스프링 부트와 JPA 활용1 - 웹 애플리케이션 개발 - 인프런 | 강의

실무에 가까운 예제로, 스프링 부트와 JPA를 활용해서 웹 애플리케이션을 설계하고 개발합니다. 이 과정을 통해 스프링 부트와 JPA를 실무에서 어떻게 활용해야 하는지 이해할 수 있습니다., - 강

www.inflearn.com

'spring > 인프런 강의 정리' 카테고리의 다른 글

[JPA 활용 1] 3. 애플리케이션 구현 준비 (0)	2022.04.17
[JPA 활용 1] 2. 도메인 분석 설계 (0)	2022.04.17
[JPA 기본편] 10. 객체지향 쿼리 언어 (0)	2022.04.02
[JPA 기본편] 9. 값 타입 (0)	2022.03.24
[JPA 기본편] 8. 프록시와 연관관계 관리 (0)	2022.03.15

[JPA 기본편] 10. 객체지향 쿼리 언어

2022. 4. 2. 12:11

객체지향 쿼리 언어 소개

JPA는 다양한 쿼리 방법을 지원

JPQL
JPA Criteria
QueryDSL
네이티브 SQL
JDBC API 직접 사용, MyBatis, SpringJdbcTemplate 함께 사용

JPQL 소개

가장 단순한 조회 방법
- EntityManager.find()
- 객체 그래프 탐색(a.getB().getC())
나이가 18살 이상인 회원을 모두 검색하고 싶다면?

JPQL

JPA를 사용하면 엔티티 객체를 중심으로 개발
문제는 검색 쿼리
검색을 할 때도 테이블이 아닌 엔티티 객체를 대상으로 검색
모든 DB 데이터를 객체로 변환해서 검색하는 것은 불가능
애플리케이션이 필요한 데이터만 DB에서 불러오려면 결국 검색 조건이 포함된 SQL이 필요
JPA는 SQL을 추상화한 JPQL이라는 객체 지향 쿼리 언어 제공
SQL과 문법 유사, SELECT, FROM ,WHERE, GROUP BY, HAVING, JOIN 지원
JPQL은 엔티티 객체를 대상으로 쿼리
SQL은 데이터베이스 테이블을 대상으로 쿼리
SQL을 추상화해서 특정 데이터베이스 SQL에 의존 X

JPQL의 쿼리문은 단순한 String이기 때문에 동적 쿼리를 만들기가 어렵다. 그렇기때문에 동적 쿼리를 작성할 대안이 필요한데 Criteria가 해결해준다.

Criteria 소개

// Criteria 사용 준비
CriteriaBuilder cb = em.getCriteriaBuilder();
CriteriaQuery<Member> query = cb.createQuery(Member.class);

// 루트 클래스 (조회를 시작할 클래스)
Root<Member> m = query.from(Member.class);

// 쿼리 생성
CriteriaQuery<Member> cq = query.select(m).where(cb.equal(m.get("username"), "kim"));
List<Member> reulstList = em.createQuery(cq).getResultList();

장점
- 문자가 아닌 자바코드로 JPQL을 작성할 수 있음
- JPQL 빌더 역할
- JPA 공식 기능
단점
- SQL스럽지 않다.
- 너무 복잡하고 실용성이 없다. (보기 어려워 유지보수하기 힘듦)
결론
- Criteria 대신에 QueryDSL 사용 권장

QueryDSL 소개

// JPQL
// select m from Member m where m.age > 18
JPAFactoryQuery query = new JPAQueryFactory(em);
QMember m = QMember.member;

List<Member> list = query.selectFrom(m)
.where(m.age.at(18))
.orderBy(m.name.desc())
.fetch();

문자가 아닌 자바코드로 JPQL을 작성할 수 있음
JPQL 빌더 역할
컴파일 시점에 문법 오류를 찾을 수 있음
동적쿼리 작성 편리함
단순하고 쉬움
실무 사용 권장

자세히 공부하고 싶으면 아래 레퍼런스가서 공부하자

Querydsl Reference Guide

The Java 6 APT annotation processing functionality is used in Querydsl for code generation in the JPA, JDO and Mongodb modules. This section describes various configuration options for the code generation and an alternative to APT usage. 3.3.1. Path initi

querydsl.com

네이티브 SQL 소개

// 네이티브 쿼리
String sql =
“SELECT ID, AGE, TEAM_ID, NAME FROM MEMBER WHERE NAME = ‘kim’";

List<Member> resultList =
em.createNativeQuery(sql, Member.class).getResultList();

JPA가 제공하는 SQL을 직접 사용하는 기능
JPQL로 해결할 수 없는 특정 데이터베이스에 의존적인 기능
예) 오라클 CONNECT BY, 특정 DB만 사용하는 SQL 힌트

JDBC 직접 사용, SpringJdbcTemplate 등

JPA를 사용하면서 JDBC 커넥션을 직접 사용하거나, 스프링 JdbcTemplate, MyBatis 등을 함께 사용 가능
단 영속성 컨텍스트를 적절한 시점에 강제로 플러시 필요
예) JPA를 우회해서 SQ을 실행하기 직전에 영속성 컨텍스트 수동 플러스

기본 문법과 쿼리 API

JPQL 문법

select_문 :: =
select_절
  from_절
  [where_절]
  [groupby_절]
  [having_절]
  [orderby_절]

update_문 :: = update_절 [where_절]
delete_문 :: = delete_절 [where_절]

select m from Member as m where m.age > 18
엔티티와 속성은 대소문자 구분O (Member, age)
JPQL 키워드는 대소문자 구분X (SELECT, FROM, where)
엔티티 이름 사용, 테이블 이름이 아님(Member)
별칭은 필수(m) (as는 생략가능)

집합과 정렬

select
COUNT(m), //회원수
SUM(m.age), //나이 합
AVG(m.age), //평균 나이
MAX(m.age), //최대 나이
MIN(m.age) //최소 나이
from Member m

GROUP BY, HAVING
ORDER BY

TypeQuery, Query

TypeQuery : 반환 타입이 명확할 때 사용
Query : 반환 타입이 명확하지 않을 때 사용

결과 조회 API

query.getResultList() : 결과가 하나 이상일 때, 리스트 반환
- 결과가 없으면 빈 리스트 반환
qeury.getSingleResult() : 결과가 정확히 하나, 단일 객체 반환
- 결과가 없으면 : javax.persistence.NoResultException
- 둘 이상이면 : javax

파라미터 바인딩 - 이름 기준, 위치 기준

프로젝션

프로젝션

SELECT 절에 조회할 대상을 지정하는 것
프로젝션 대상 : 엔티티, 임베디드 타입, 스칼라 타입 (숫자, 문자등 기본 데이터 타입)
SELECT m FROM Member m -> 엔티티 프로젝션
SELECT m.team FROM Member m -> 엔티티 프로젝션
SELECT m.address FROM Member m -> 임베디드 타입 프로젝션
SELECT m.username, m.age FROM Member m -> 스칼라 타입 프로젝션
DISTINCT로 중복 제거
SELECT m.username, m.age FROM Member m
1. Query 타입으로 조회
2. OBject[] 타입으로 조회
3. new 명령어로 조회
- 단순 값을 DTO로 바로 조회
  SELECT new jpabook.jpql.UserDTO(m.username, m.age) FROM Member m
- 패키지 명을 포함한 전체 클래스 명 입력
- 순서와 타입이 일치하는 생성자 필요

페이징 API

페이징 API

JPA는 페이징을 다음 두 API로 추상화
setFirstResult(int startPosition) : 조회 시작 위치 (0부터 시작)
setMaxResults(int maxResult) : 조회할 데이터 수

실제 Oracle 페이징 쿼리를 보면 3번의 뎁스를 통해 쿼리문을 작성해야 하지만, JPA는 setFirstResult, setMaxResults로 편하게 페이징 작업을 할 수 있는 것을 볼 수 있습니다.

조인

내부조인
- SELECT m FROM Member m [INNER] JOIN m.team t
외부 조인
- SELECT m FROM Member m LEFT [OUTER] JOIN m.team t
- 참고로 외부 조인할 때 SQL log를 oracle로 하면 에러 납니다.
세타 조인
- SELECT count(m) from Member m, Team t where m.username = t.name

조인 - ON 절

ON절을 활용한 조인 (JPA 2.1부터 지원)
1. 조인 대상 필터링
2. 연관관계 없는 엔티티 외부 조인 (하이버네이트 5.1 부터)

1. 조인 대상 필터링

예) 회원과 팀을 조인하면서, 팀 이름이 A인 팀만 조인

JPQL
SELECT m, t FROM Member m LEFT JOIN m.team t on t.name = 'A'

SQL
SELECT m.*, t.* FROM Member m LEFT JOIN Team t ON m.TEAM_ID = t.id and t.name = 'A'

2. 연관관계 없는 엔티티 외부 조인

예) 회원의 이름과 팀의 이름이 같은 대상 외부 조인

JPQL
SELECT m, t FROM Member m LEFT JOIN Team t on m.username = t.name

SQL
SELECT m.*, t.* FROM Member m LEFT JOIN Team t ON m.username = t.name

서브 쿼리

서브 쿼리

메인 쿼리랑 서브 쿼리랑 테이블 관계가 없다.

나이가 평균보다 많은 회원
select m from Member m
where m.age > (select avg(m2.age) from Member m2)
한 건이라도 주문한 고객
select m from Member m
where (select count(o) from Order o where m = o.member) > 0

서브 쿼리 지원 함수

[NOT] EXISTS (subquery) : 서브쿼리에 결과가 존재하면 참
- {ALL | ANY | SOME} (subquery)
- ALL 모두 만족하면 참
- ANY, SOME : 같은 의미, 조건을 하나라도 만족하면 참
[NOT] IN (subquery) : 서브쿼리의 결과 중 하나라도 같은 것이 있으면 참

서브 쿼리 - 예제

팀A 소속인 회원
select m from Member m
where exists (select t from m.team t where t.name = '팀A')
전체 상품 각각의 재고보다 주문량이 많은 주문들
select o from Order o
where o.orderAmount > ALL (select p.stockAmount from Product p)
어떤 팀이든 팀에 소속된 회원
select m from Member m
where m.team = ANY (select t from Team t)

JPA 서브 쿼리 한계

JPA는 WHERE, HAVING 절에서만 서브 쿼리 사용 가능
SELECT 절도 가능 (하이버네이트에서 지원)
FROM 절의 서브 쿼리는 현재 JPQL에서 불가능
- 조인으로 풀 수 있으면 풀어서 해결

JPQL 타입 표현

JPQL 타입 표현

문자 : 'HELLO', 'She''s'
숫자 : 10L(Long), 10D(Double), 10F(Float)
Boolean : TRUE, FALSE
ENUM : jpabook.MemberType.Admin (패키지명 포함)
엔티티 타입 : TYPE(m) = Member (상속 관계에서 사용)

JPQL 기타

SQL과 문법이 같은 식
EXISTS, IN
AND, OR, NOT
=, >, >=, <, <=, <>
BETWEEN, LIKE, IS NULL

조건식 - CASE 식

기본 CASE 식

단순 CASE 식

COALESCE : 하나씩 조회해서 null이 아니면 반환

NULLIF : 두 값이 같으면 null 반환, 다르면 첫번째 값 반환

JPQL 함수

JPQL 기본 함수

CONCAT
SUBSTRING
TRIM
LOWER, UPPER
LENGTH
LOCATE
ABS, SQRT, MOD
SIZE, INDEX (JPA 용도)

사용자 정의 함수 호출

하이버네이트는 사용전 방언에 추가해야 한다.
- 사용하는 DB 방언을 상속받고, 사용자 정의 함수를 등록한다.

select function('group_concat', i.name) from Item i

경로 표현식

.(점)을 찍어 객체 그래프를 탐색하는 것

select m.username -> 상태 필드
from Member m
join m.team t -> 단일 값 연관 필드
join m.order o -> 컬렉션 값 연관 필드
where t.name = '팀A'

경로 표현식 용어 정리

상태 필드 : 단순히 값을 저장하기 위한 필드 (ex : m.username)
연관 필드 : 연관관계를 위한 필드
- 단일 값 연관 필드
  - @ManyToOne, @OneToOne, 대상이 엔티티 (ex : m.team)
- 컬렉션 값 연관 필드
  - @OneToMany, @ManyToMany, 대상이 컬렉션 (ex : m.orders)

경로 표현식 특징

상태 필드 : 경로 탐색의 끝, 탐색 X
단일 값 연관 경로 : 묵시적 내부 조인(inner join) 발생, 탐색 O
- 탐색이 된다는 것은 "select m.team.name From Member m" 에서 m.team에서 .name으로 탐색이 가능하다는 것을 의미합니다.
컬렉션 값 연관 경로 : 묵시적 내부 조인 발생, 탐색 X
- FROM 절에서 명시적 조인을 통해 별칭을 얻으면 별칭을 통해 탐색 가능

묵시적 내부 조인이란?

"select m.team From Member m" 의 JPQL 쿼리문을 날리면 Member와 Team 테이블간의 inner join이 발생하게 됩니다.
이렇듯 inner join을 사용하지 않았지만 실제 쿼리문에서 inner join이 사용되는 것을 말합니다.
(참고로 묵시적 내부 조인이 발생하도록 짜면 안됩니다.) => 성능 튜닝에 어려움이 있다고 합니다.
==>> 묵시적 조인보다 명시적 조인을 사용하는 것을 권장합니다.

상태 필드 경로 탐색

JPQL
- select m.username, m.age from Member m
SQL
- select m.username, m.age from Member m

단일 값 연관 경로 탐색

JPQL
- select o.member from Order o
SQL
- select m.*
  from Orders o
  inner join Member m on o.member_id=m.id

묵시적 조인이 발생한다!

명시적 조인, 묵시적 조인

명시적 조인 : join 키워드 직접 사용
- select m from Member m join m.team t
묵시적 조인 : 경로 표현식에 의해 묵시적으로 SQL 조인 발생 (내부 조인만 가능)
- select m.team from Member m

경로 탐색을 사용한 묵시적 조인 시 주의사항

항상 내부 조인
컬렉션은 경로 탐색의 끝, 명시적 조인을 통해 별칭을 얻어야 탐색이 가능함
경로 탐색은 주로 SELECT, WHERE 절에서 사용하지만 묵시적 조인으로 인해 SQL의 FROM (JOIN) 절에 영향을 줌

실무 조언

가급적 묵시적 조인 대신에 명시적 조인 사용
조인은 SQL 튜닝에 중요 포인트
묵시적 조인은 조인이 일어나는 상황을 한눈에 파악하기 어려움

JPQL - 페치 조인 (fetch join)

실무에서 정말정말 중요함

페치 조인 (fetch join)

SQL 조인 종류 X
JPQL에서 성능 최적화를 위해 제공하는 기능
연관된 엔티티나 컬렉션을 SQL 한 번에 함께 조회하는 기능
join fetch 명령어 사용
페치 조인 ::= [LEFT [OUTER] | INNER] JOIN FETCH 조인 경로

엔티티 패치 조인

회원을 조회하면서 연관된 팀도 함께 조회(SQL 한 번에)
SQL을 보면 회원 뿐만 아니라 팀(T.*)도 함께 SELECT
[JPQL]
select m from Member m join fetch m.team
[SQL]
select M.*, T.* from Member M
INNER JOIN Team T ON M.TEAM_ID=T.ID

페치 조인 사용 코드

String jqpl = "select m from Member m join fetch m.team";
List<Member> members = em.createQuery(jpql, Member.class).getResultList();

for(Member member : members){
//페치 조인으로 회원과 팀을 함께 조회해서 지연 로딩 X
System.out.println("username = " + member.getUsername() + ", " +
"teamNmae = " + member.getTeam().name());
}

컬렉션 페치 조인

일대다 관계, 컬렉션 페치 조인
[JPQL]
select t
from Team t join fetch t.members
where t.name = '팀A'
[SQL]
SELECT T.*, M.*
INNER JOIN MEMBER M ON T.ID=M.TEAM_ID
WHERE T.NAME='팀A'

주의해야할 건
조회한 건 팀A 한개이지만, 팀A와 연관된 member가 몇명인지 모르기 때문에
row의 수가 1개인지 100개인지 10000개인지 알 수 없습니다.
아래는 팀A를 조회하고 팀A에 속한 member가 2명인 경우 조회했을 때의 결과입니다.

컬렉션 페치 조인 사용 코드

String jqpl = "select t from Team t join fetch t.members where t.name = '팀A'";
List<Team> teams = em.createQuery(jqpl, Team.class).getResultList();

for(Team teamA : teams){
System.out.println("team = " + teamA.getName() + ", team = " + teamA);
for(Member memberA : team.getMembers()){
System.out.println("-> username = " + memberA.getName() + ",member = " + memberA);
}
}

주의!
team은 1개 member은 2개이지만
같은 팀 2개 같은 member가 2개가 만들어진 걸 볼 수 있습니다.
이렇게 중복된 부분을 제거하기 위해 sql의 distinct가 필요합니다.

페치 조인과 DISTINCT

SQL의 DISTINCT는 중복된 결과를 제거하는 명령
JPQL의 DISTINCT 2가지 기능 제공
1. SQL에 DISTINCT를 추가
2. 애플리케이션에서 엔티티 중복 제거
select distinct t
from Team t join fetch t.members
where t.name = '팀A'
SQL에 DISTINCT를 추가하지만 데이터가 다르므로 SQL 결과에서 중복제거 실패

DISTINCT가 추가로 애플리케이션에서 중복 제거시도
같은 식별자를 가진 Team 엔티티 제거

이전 쿼리문에 distinct를 추가하면 위처럼 됩니다.

실제 distinct 쓰기 전 출력문과 쓰고난 후의 출력문은 아래와 같습니다.

페치 조인과 일반 조인의 차이

일반 조인 실행 시 연관된 엔티티를 함께 조회하지 않음 (그렇기 때문에 지연 로딩이 발생한다.)
[JQPL]
select t
from Team t join t.members m
where t.name = '팀A'
[SQL]
SELECT T.*
FROM TEAM T
INNER JOIN MEMBER M ON T.ID = M.TEAM_ID
WHERE T.NAME = '팀A'
JPQL은 결과를 반환할 때 연관관계를 고려 X
단지 SELECT 절에 지정한 엔티티만 조회할 뿐
여기서는 팀 엔티티만 조회하고, 회원 엔티티는 조회 X
페치 조인을 사용할 때만 연관된 엔티티도 함께 조회(즉시 로딩)
페치 조인은 객체 그래프를 SQL 한번에 조회하는 개념

페치 조인의 특징과 한계

페치 조인 대상에는 별칭을 줄 수 없다.
- 페치 조인 대상이 5명이 있는데, 1명만 조회해서 갖고오면 4명이 누락되기 때문에 문제가 생길 수 있다. (아직 현업에서 사용해보지 않아서 이것때문에 문제가 생길지 감이 오지 않지만 그렇다고 합니다.)
- 하이버네이트는 가능, 가급적 사용 X
- 유일하게 사용할 때는 fetch join을 여러번 이어서 사용해야할 때 사용한다고합니다.
둘 이상의 컬렉션은 페치 조인 할 수 없다.
- 팀에 members와 orders 두 개의 컬렉션이 있는 경우 페치조인 할 수 없다고 합니다.
- 가끔 되기도 하지만, 문제가 생길 수 있다고 합니다.
- 일대다도 데이터가 뻥튀기가 되는데, 일대 다대다 이기 때문에 데이터가 예상하지 못하게 NxN이 되어 엄청난 데이터가 나올 수 있습니다. (어떻게 되기도 하는데 데이터가 제대로 맞지 않는다고 합니다.)
컬렉션을 페치 조인하면 페이징 API(setFirstResult, setMaxResult)를 사용할 수 없다.
- 일대일, 다대일 같은 단일 값 연관 필드들은 페치 조인해도 페이징 가능 (데이터 뻥튀기가 되지 않기 때문)
- 하이버네이트는 경고 로그를 남기고 메모리에서 페이징 (매우 위험) (매모리에서 페이징이란 모든 데이터를 다 가져온 뒤, 페이징을 하기 때문에 필요하지 않은 모든 데이터를 갖고 온다.)
- 해결책
  - 방향을 뒤집어서 해결할 수 있습니다. (컬렉션 대상으로 시작하는 쿼리문으로 작성하면 됩니다.)
  - "select t From Team t"를 해준 뒤, 배치사이즈를 통해 N+1 문제를 최소화 해줍니다.

연관된 엔티티들을 SQL 한 번으로 조회 - 성능 최적화
엔티티에 직접 적용하는 글로벌 로딩 전략보다 우선함
- @OneToMany(fetch = FetchType.LAZY) // 글로벌 로딩 전략
실무에서 글로벌 로딩 전략은 모두 지연 로딩
최적화가 필요한 곳은 페치 조인 적용

페치 조인 - 정리

모든 것을 페치 조인으로 해결할 수는 없다.
페치 조인은 객체 그래프를 유지할 때 사용하면 효과적
- m.team.getname() 이런식으로 객체 그래프를 유지할 때
여러 테이블을 조인해서 엔티티가 가진 모양이 아닌 전혀 다른 결과를 내야 하면, 페치 조인 보다는 일반 조인을 사용하고 필요한 데이터들만 조회해서 DTO로 반환하는 것이 효과적

김영한님은 현업에서 복잡한 테이블 7~8개를 조인해서 풀어내야하는 문제에 직면했을 때, 결과가 빨리 나오지 않아 성능이 좋지 않았다.
왜이리 성능이 안좋은가 봤더니 쿼리가 너무 많아 발생했다.
batch, fetch join으로 짧은 시간안에 결과를 해결해냈다는 일화가...

그만큼 fetch join가 중요하기 때문에 잘 이해하고 있어야 한다는 점을 기억하면 될 것 같다!

JPQL - 다형성 쿼리

TYPE

조회 대상을 특정 자식으로 한정
예) Item 중에 Book, Movie를 조회해라
[JPQL]
select i from Item i
where type(i) IN (Book, Movie)
[SQL]
select i from i
where i.DTYPE in ('B', 'M')

TREAT (JPA 2.1)

자바의 타입 캐스팅과 유사
상속 구조에서 부모 타입을 특정 자식 타입으로 다룰 때 사용
FROM, WHERE, SELECT (하이버네이트 지원) 사용
예) 부모인 Item과 자식 Book이 있다.
[JPQL]
select i from Item i
where treat(i as Book).auther = 'kim'
[SQL]
select i.* from Item i
where i.DTYPE = 'B' and i.auther = 'kim'

JPQL - 엔티티 직접 사용

엔티티 직접 사용 - 기본 키 값

JPQL에서 엔티티를 직접 사용하면 SQL에서 해당 엔티티의 기본 키 값을 사용
[JQPL]
select count(m.id) from Member m // 엔티티의 아이디를 사용
select count(m) from Member m // 엔티티를 직접 사용
[SQL] (JPQL 둘 다 같은 다음 SQL 실행)
select count(m.id) as cnt from Member m
엔티티를 파라미터로 전달

String jpql = "select m from Member m where m = :member";
List result = em.createQuery(jqpl)
.getParameter("member", member);
.getReulstList();

식별자를 직접 전달

String jpql = "select m from Member m where m.id = :memberId";
List result = em.createQuery(jqpl)
.setParameter("memberId", memberId);
.getReulstList();

실행된 SQL

select m.* from Member m where m.id=?

엔티티 직접 사용 - 외래 키 값

Team team = em.find(Team.class, 1L);

String qlString = "select m from Member m where m.team = :team";
List<Member> resultList = em.createQuery(qlString, Member.class)
.setParameter("team", team)
.getResultList();

String qlString = "select m from Member m where m.team.id = :teamId";
List<Member> resultList = em.createQuery(qlString, Member.class)
.setParameter("teamId", teamId)
.getResultList();

실행된 SQL

select m.* from member m where m.team_id = ?

JPQL - Named 쿼리

Named 쿼리 - 정적 쿼리

미리 정의해서 이름을 부여해두고 사용하는 JPQL
정적 쿼리
어노테이션, XML에 정의
애플리케이션 로딩 시점에 초기화 후 재사용
애플리케이션 로딩 시점에 쿼리를 검증

NamedQuery에서 오타를 낸 경우 프로그램이 정상 작동하는 것이 아닌 컴파일 시점에 에러를 찾아 프로그램이 중단되게 만들어줍니다. (해당 쿼리를 컴파일 시점에 캐시하며 검증을 한다고 합니다.)

Named 쿼리 - 어노테이션

위처럼 엔티티위에 쿼리를 작성하게 되면 엔티티를 보기 힘들어지고 엔티티 클래스의 코드가 더러워집니다. 이를해결하기 위한 방법은 아래 방법을 사용하면 됩니다.

Spring Data JPA reference document를 보면

Spring Data JPA - Reference Documentation

Example 109. Using @Transactional at query methods @Transactional(readOnly = true) interface UserRepository extends JpaRepository { List findByLastname(String lastname); @Modifying @Transactional @Query("delete from User u where u.active = false") void del

docs.spring.io

아래와 같이 interface 메서드 위에 NamedQuery를 선언이 가능합니다. 아래와 같이 작성하면 컴파일 시점에 에러를 확인해주며 캐시에 저장합니다.

JPQL - 벌크 연산

벌크 연산

재고가 10개 미만인 모든 상품의 가격을 10% 상승하려면?
JPA 변경 감지 기능으로 실행하려면 너무 많은 SQL 실행
1. 재고가 10개 미만인 상품을 리스트로 조회한다.
2. 상품의 엔티티의 가격을 10% 증가한다.
3. 트랜잭션 커밋 시점에 변경감지가 동작한다.
변경된 데이터가 100건이라면 더티체킹을 통해 100번의 UPDATE SQL 쿼리문이 나간다.

벌크 연산 예제

쿼리 한 번으로 여러 테이블 로우 변경(엔티티)
executeUpdate()의 결과는 영향받은 엔티티 수 반환
UPDATE, DLEETE 지원
INSERT(insert into .. select, 하이버네이트 지원)

String qlString = "update Product p " +
"set p.price = p.price * 1.1 " +
"where p.stockAmount < :stockAmount";

int resultCount = em.createQuery(qlString)
.setParameter("stockAmount", 10)
.executeUpdate();

벌크 연산 주의

벌크 연산은 영속성 컨텍스트를 무시하고 데이터베이스에 직접 쿼리
- 벌크 연산을 먼저 실행
- (벌크 연산할 때 자동으로 flush가 됌) 벌크 연산 수행 후 영속성 컨텍스트 초기화 (em.clear() 필수)

출처

자바 ORM 표준 JPA 프로그래밍 - 기본편 - 인프런 | 강의

JPA를 처음 접하거나, 실무에서 JPA를 사용하지만 기본 이론이 부족하신 분들이 JPA의 기본 이론을 탄탄하게 학습해서 초보자도 실무에서 자신있게 JPA를 사용할 수 있습니다., - 강의 소개 | 인프런

www.inflearn.com

'spring > 인프런 강의 정리' 카테고리의 다른 글

[JPA 활용 1] 2. 도메인 분석 설계 (0)	2022.04.17
[JPA 활용 1] 1. 프로젝트 환경설정 (0)	2022.04.17
[JPA 기본편] 9. 값 타입 (0)	2022.03.24
[JPA 기본편] 8. 프록시와 연관관계 관리 (0)	2022.03.15
[JPA 기본편] 7. 고급 매핑 (0)	2022.03.11

[JPA 기본편] 9. 값 타입

2022. 3. 24. 13:38

기본값 타입
임베디드 타입(복합 값 타입)
값 타입과 불변 객체
값 타입의 비교
값 타입 컬렉션
실전 예제 - 6. 값 타입 매핑

기본값 타입

JPA의 데이터 타입 분류

엔티티 타입
- @Entity로 정의하는 객체
- 데이터가 변해도 식별자로 지속해서 추적 가능
- 예) 회원 엔티티의 키나 나이 값을 변경해도 식별자로 인식 가능
값 타입
- int, Integer, String처럼 단순히 값으로 사용하는 자바 기본 타입이나 객체
- 식별자가 없고 값만 있으므로 변경시 추적 불가
- 예) 숫자 100을 200으로 변경하면 완전히 다른 값으로 대체

값 타입 분류

기본값 타입
- 자바 기본 타입 (int, double)
- 래퍼 클래스 (Integer, Long)
- String
임베디드 타입(embedded type, 복합 값 타입)
- x,y 좌표 같은 경우
컬렉션 값 타입(collection value type)

기본값 타입

예) int age, String name
생명 주기를 엔티티의 의존
- 예) 회원을 삭제하면 이름, 나이 필드도 함께 삭제
값 타입은 공유하면 X
- 예) 회원 이름 변경시 다른 회원의 이름도 함꼐 변경되면 안됨

참고 : 자바의 기본 타입은 절대 공유 X

int, double 같은 기본 타입(primitive type)은 절대 공유 X
기본 타입은 항상 값을 복사함
Integer같은 래퍼 클래스나 String 같은 특수한 클래스는 공유 가능한 객체이지만 변경 X

임베디드 타입 (복합 값 타입)

임베디드 타입

새로운 값 타입을 직접 정의할 수 있음
JPA는 임베디드 타입(embedded type)이라 함
주로 기본 값 타입을 모아서 만들어서 복합 값 타입이라고도 함
int, String과 같은 값 타입

임베디드 타입

회원 엔티티는 이름, 근무 시작일, 근무 종료일, 주소 도시, 주소 번지, 주소 우편번호를 가진다.

회원 엔티티는 이름, 근무 기간, 주소를 가진다.

임베디드 타입 사용법

@Embeddeable : 값 타입을 정의하는 곳에 표시
@Embedded : 값 타입을 사용하는 곳에 표시
기본 생성자 필수

임베디드 타입의 장점

재사용
높은 응집도
Perioid.isWork() 처럼 해당 값 타입만 사용하는 의미있는 메소드를 만들 수 있음
임베디드 타입을 포함한 모든 값 타입은 값 타입을 소유한 엔티티에 생명주기를 의존함

임베디드 타입과 테이블 매핑

임베디드 타입과 테이블 매핑

임베디드 타입은 엔티티의 값일 뿐이다.
임베디드 타입을 사용하기 전과 후에 매핑하는 테이블은 같다.
객체와 테이블을 아주 세밀하게(find-grained) 매핑하는 것이 가능
잘 설계한 ORM 애플리케이션은 매핑한 테이블의 수 보다 클래스의 수가 더 많음

임베디드 타입과 연관관계

@AttributeOverride : 속성 재정의

한 엔티티에서 같은 값 타입을 사용하면?
컬럼 명이 중복 됨
@AttributeOverrides, @AttributeOverride를 사용해서 컬럼 명 속성을 재정의

@AttributeOverrides, @AttributeOverride 예시

값 타입과 불변 객체

값 타입은 복잡한 객체 세상을 조금이라도 단순화하려고 만든 개념이다. 따라서 값 타입은 단순하고 안전하게 다룰 수 있어야 한다.

값 타입 공유 참조

임베디드 타입 같은 값 타입을 여러 엔티티에서 공유하면 위험함
부작용 (side effect) 발생

예시

member1의 city만 바꾸고싶었지만, member2도 변경되기 때문에 update쿼리문이 두번 나가는 것을 볼 수 있다.

해결 방법
- 이렇게 값을 공유하고 싶을 때는 임베디드가 아닌 엔티티로 해주어야 합니다.

값 타입 복사

값 타입의 실제 인스턴스인 값을 공유하는 것은 위험
대신 값(인스턴스)를 복사해서 사용

값을 복사해서 사용하는 경우, update 쿼리문이 한번만 나가 의도치 않은 업데이트 쿼리문이 나가지 않습니다.

객체 타입의 한계

항상 값을 복사해서 사용하면 공유 참조로 인해 발생하는 부작용을 피할 수 있다.
문제는 임베디드 타입처럼 직접 정의한 값 타입은 자바의 기본 타입이 아니라 객체 타입이다.
자바 기본 타입에 값을 대입하면 값을 복사한.
객체 타입은 참조 값을 직접 대입하는 것을 막을 방법이 없다.
객체의 공유 참조는 피할 수 없다.

기본 타입은 타입의 값을 복사해서 넘기지만, 객체 타입은 참조 값을 전달하기 때문에 값 변경시 a와 b모두 변경이 됩니다.

불변 객체

객체 타입을 수정할 수 없게 만들면 부작용을 원천 차단
값 타입은 불변 객체(immutable object)로 설계해야한다.
불변 객체 : 생성 시점 이후 절대 값을 변경할 수 없는 객체
생성자로만 값을 설정하고 수정자(Setter)를 만들지 않으면 됨 (또는 setter를 public이 아닌 private로 선언)
참고 : Integer, String은 자바가 제공하는 대표적인 불변 객체

불변이라는 작은 제약으로 부작용이라는 큰 재앙을 막을 수 있다.

값 타입의 비교

값 타입의 비교

값 타입 : 인스턴스가 달라도 그 안에 값이 같으면 같은 것으로 봐야 함

값 타입의 비교

동일성(identity) 비교 : 인스턴스의 참조 값을 비교, == 사용
동등성(equivalence) 비교 : 인스턴스의 값을 비교, equals()
값 타입은 a.equals(b)를 사용해서 동등성 비교를 해야 함
값 타입의 equals() 메소드를 적절하게 재정의(주로 모든 필드 사용)

값 타입 컬렉션

값 타입 컬렉션

위의 Member 엔티티의 경우 1: N의 개념이기 때문에 별도의 테이블을 만들어주어야 관리가 가능합니다.

값 타입 컬렉션

타입을 하나 이상 저장할 때 사용
@ElementCollection, @CollectionTable 사용
데이터베이스는 컬렉션을 같은 테이블에 저장할 수 없다. (정석적으로 불가능)
컬렉션을 저장하기 위한 별도의 테이블이 필요함

값 타입 컬렉션 사용

값 타입 조회 예제
- 값 타입 컬렉션도 지연 로딩 전략 사용 (해당 컬럼에 접근할 때 select 쿼리문이 나간다.)
참고 : 값 타입 컬렉션은 영속성 전에(Cascade) + 고아 객체 제거 기능을 필수로 가진다고 볼 수 있다.

값 타입 컬렉션의 제약사항

값 타입은 엔티티와 다르게 식별자 개념이 없다.
값은 변경하면 추적이 어렵다.
값 타입 컬렉션에 변경 사항이 발생하면, 주인 엔티티와 연관된 모든 데이터를 삭제하고, 값 타입 컬렉션에 있는 현재 값을 모두 다시 저장한다. (매우 비효율적인데...) - 역시나 쓰면 안된다고 한다.
값 타입 컬렉션을 매핑하는 테이블은 모든 컬럼을 묶어서 기본키를 구성해야 함 : Null 입력 X, 중복 저장 X

값 타입 컬렉션 대안

실무에서는 상황에 따라 값 타입 컬렉션 대신에 일대다 관계를 고려
일대다 관계를 위한 엔티티를 만들고, 여기에서 값 타입을 사용
영속성 전이(Cascade) + 고아 객체 제거를 사용해서 값 타입 컬렉션 처럼 사용
EX) AddressEntity

실전 예제 6 - 값 타입 매핑

출처

자바 ORM 표준 JPA 프로그래밍 - 기본편 - 인프런 | 강의

www.inflearn.com

'spring > 인프런 강의 정리' 카테고리의 다른 글

[JPA 활용 1] 1. 프로젝트 환경설정 (0)	2022.04.17
[JPA 기본편] 10. 객체지향 쿼리 언어 (0)	2022.04.02
[JPA 기본편] 8. 프록시와 연관관계 관리 (0)	2022.03.15
[JPA 기본편] 7. 고급 매핑 (0)	2022.03.11
[JPA 기본편] 6. 다양한 연관관계 매핑 (0)	2022.03.09

[JPA 기본편] 8. 프록시와 연관관계 관리

2022. 3. 15. 15:03

프록시
즉시 로딩과 지연 로딩
지연 로딩 활용
연속성 전이 : CASECADE
고아 객체
연속성 전이 + 고아 객체, 생명주기
실전 예제 - 5. 연관관계 관리

프록시

Member를 조회할 때 Team도 함께 조회해야 할까?

결론적으로 비즈니스 로직에 따라 다를 것이다. 멤버를 가져왔을 때 팀을 100% 사용한다고 할 때는 함께 조회하는 게 이득일 수 있지만, 팀을 20% 사용한다고 할 때는 필요할 때 팀 데이터를 가져오는게 이득일 수 있다.

JPA에서는 위의 문제점을 지연로딩과 프록시로 기가막히게 처리한다고 한다.

프록시 기초

em.find() vs em.getReference()
em.find() : 데이터베이스를 통해서 실제 엔티티 객체 조회
em.getReference() : 데이터베이스 조회를 미루는 가짜(프록시) 엔티티 객체 조회
- DB 쿼리가 나가지 않는데 조회가 되는 것
- 실제로 해보니 getReference 시점에 쿼리가 나가지 않고 해당 객체를 사용할 때 쿼리가 나감.

getReference로 가져온 객체는 .getClass()로 네이밍 조회 시에 Hibernate에서 제공해주는 프록시 객체인 것을 알 수 있습니다.

프록시 특징

실제 클래스를 상속 받아서 만들어짐 (hibernate가 내부적으로 프록시 라이브러리를 통해 만들어 냄)
실제 클래스와 겉 모양이 같다.
사용하는 입장에서는 진짜 객체인지 프록시 객체인지 구분하지 않고 사용하면 됨. (이론상)

프록시 객체는 실제 객체의 참조(targer)을 보관
프록시 객체를 호출하면 프록시 객체는 실제 객체의 메소드 호출 (여기서 DB에 쿼리가 나감)

프록시 객체의 초기화

Member member = em.getReference(Member.class, "id1");
member.getName();

프록시의 특징

프록시 객체는 처음 사용할 때 한 번만 초기화
프록시 객체를 초기화 할 때, 프록시 객체가 실제 엔티티로 바뀌는 것은 아님, 초기화되면 프록시 객체를 통해서 실제 엔티티에 접근 가능
프록시 객체는 원본 엔티티를 상속 받음, 따라서 타입 체크시 주의해야함 (== 비교 실패, 대신 instance of 사용)
- instanceof 사용법 : 객체 instanceof 클래스명
영속성 컨텍스트에 찾는 엔티티가 이미 있으면 em.getReference()를 호출해도 실제 엔티티 반환
- getReference 전 find로 같은 객체를 찾아놓았다면 실제 엔티티 반환
- getReference 전 getReference로 같은 객체를 찾아놓았다면 프록시 객체 반환
- getReference -> find가 같은 데이터일 때 find에서도 프록시 반환
  - -->> 이렇게까지 하는 이유는 JPA에서는 어떻게든 ==비교 시에 같도록 나오게하려고 함.
영속성 컨텍스트의 도움을 받을 수 없는 준영속 상태일 때, 프록시를 초기화하면 문제 발생 (하이버네이트는 org.hibernate.LazuInitializationException 예외를 터트림) - 영속성 컨텍스트에 없기 때문에 초기화할 수 없다는 뜻
- em.detach(객체) or em.close()

프록시 확인

프록시 인스턴스의 초기화 여부 확인
- emf.getPersistenceUnitUtil().isLoaded(Object entity)
프록시 클래스 확인 방법
- entity.getClass().getName() 출력
프록시 강제 초기화
- org.hibernate.hibernate.initialize(entity)
참고 : JPA 표준은 강제 초기화 없음
- 강제 호출 : member.getName()

즉시 로딩과 지연 로딩

Member를 조회할 때 Team도 함께 조회해야 할까?

이것은 비즈니스 로직에 따라 다르지만, 단순히 member 정보만 조회하는 비즈니스 로직에서는 Team에 대한 쿼리문을 날릴 필요가 없다.

지연 로딩 LAZY를 사용해서 프록시로 조회

fetch = FetchType.LAZY로 조회하는 경우 Member를 조회할 때, Team에 대한 쿼리가 나가지 않는 것을 볼 수 있습니다.

findMember.getTeam을 해서 Team 객체를 가져오면 쿼리문을 보내지 않고, 프록시 객체를 가져오는 것을 볼 수 있습니다. 후에 프록시 객체의 접근해 데이터를 가져올 때 프록시 객체가 진짜 객체를 필요로 하기 때문에 쿼리문을 보내고, 데이터를 가져오는 것을 볼 수 있습니다.

지연 로딩

지연 로딩 LAZY를 사용해서 프록시로 조회

Team team = member.getTeam(); // 쿼리가 나가지 않음 (프록시 객체 할당)

team.getName(); // 실제 team을 사용하는 시점에 초기화 (쿼리가 나감)

즉시 로딩

Member를 가져올 때 Team을 자주 함께 사용할 때 사용하면 쿼리 한번으로 조회가 되기때문에 좋은 방법입니다.

LAZY 테스트 할 때와 같은 코드로 EAGER일 때 실행해 보았습니다. 출력된 쿼리문으로 Member와 Team 객체를 한 번의 쿼리로 조회하는 것을 볼 수 있습니다. LAZY는 Member->Team의 플로우에서 두번 쿼리문을 날리는 것에 비해 효율적으로 보입니다. 가져온 Team의 객체는 프록시 객체가 아닌 진짜 객체를 가져온 것을 볼 수 있습니다.

즉시 로딩

즉시 로딩(EAGER), Member조회 시 항상 Team도 조회

JPA 구현체는 가능하면 조인을 사용해서 SQL 한 번에 함께 조회

프록시와 즉시로딩 주의

가급적 지연 로딩만 사용 (특히 실무에서)
즉시 로딩을 적용하면 예상하지 못한 SQL이 발생하기 때문 (2개일 땐 별다른 차이가 없지만, 5개 아니 더 많은 구조들에서 문제가 생깁니다.)
즉시 로딩은 JPQL에서 N+1 문제를 일으킨다. (N+1문제란, 처음 쿼리 1개를 날렸는데 추가 쿼리가 N개가 나간다.)
@ManyToOne, @OneToOne은 기본이 즉시 로딩
-> LAZY로 설정
@OneToMany, @ManyToMany는 기본이 지연 로딩

EAGER의 경우 Member를 조회할 때, Member마다 Team 쿼리를 또 날린다.

지연 로딩 활용

Member와 Team은 자주 함께 사용 -> 즉시 로딩
Member와 Order는 가끔 사용 -> 지연 로딩
Order와 Product는 자주 함께 사용 -> 즉시 로딩
위의 설명은 이론적인 것, 실무에서는 모두 지연 로딩으로 해야함.

지연 로딩 활용 - 실무

모든 연관관계에 지연 로딩을 사용해라!
실무에서 즉시 로딩을 사용하지 마라!
JPQL fetch 조인이나, 엔티티 그래프 기능을 사용해라! (뒤에서 설명)
즉시 로딩은 상상하지 못한 쿼리가 나간다.

영속성 전이 : CASCADE와 고아 객체

영속성 전이 : CASCADE

특정 엔티티를 영속 상태로 만들 때 연관된 엔티티도 함께 영속 상태로 만들고 싶을 때
예 : 부모 엔티티를 저장할 때 자식 엔티티도 함께 저장

영속성 전이 : 저장

연관관계의 주인을 저장할 때, 연관된 객체를 모두 저장하는 것을 cascade라고 한다.

cascade가 없을 땐 연관관계의 주인을 저장할 때, 연관관계의 주인만 DB에 insert 쿼리문이 나가며 저장된다. 아래는 위의 코드로 실행했을 때의 출력되는 쿼리문.

하지만 cascade를 all로 설정하면 연관관계의 주인을 저장할 때에는 연관관계의 주인 뿐만이 아닌 하위 객체들 모두 DB에 insert 쿼리문이 나가며 저장된다. 아래는 위의 코드로 실행했을 때의 출력되는 쿼리문.

영속성 전이 : CASCADE - 주의!

영속성 전이는 연관관계를 매핑하는 것과 아무 관련이 없음
엔티티를 영속화할 때 연관된 엔티티도 함께 영속화하는 편리함을 제공할 뿐
위의 경우처럼 parent -> child일 때, child와 다른 객체가 연관관계가 없다면 cascade를 사용해도 되지만 child에 또 다른 객체가 연관관계가 있다면 사용하면 안된다고 합니다. (이유는 알게되면 정리)

CASCADE의 종류

ALL : 모두 적용
PERSIST : 영속
REMOVE : 삭제
MERGE : 병합
REFRESH : REFRESH
DETACH : DETACH

고아 객체

고아 객체 제거 : 부모 엔티티와 연관관계가 끊어진 자식 엔티티를 자동으로 삭제
orphanRemoval = true
Parent parent1 = em.find(Parent.class, id);
parent1.getChildren().remove(0);
// 자식 엔티티를 컬렉션에서 제거
DELETE FROM CHILD WHERE ID = ?

고아 객체 - 주의

참조가 제거된 엔티티는 다른 곳에서 참조하지 않는 고아 객체로 보고 삭제하는 기능
참조하는 곳이 하나일 때 사용해야 함!
특정 엔티티가 개인 소유할 때 사용
@OneToOne, @OneToMany만 가능
참고 : 개념적으로 부모를 제거하면 자식은 고아가 된다. 따라서, 고아 객체 제거 기능을 활성화 하면, 부모를 제거할 때 자식도 함께 제거된다. 이것은 CascaseType.REMOVE처럼 동작한다.

영속성 전이 + 고아 객체, 생명주기

CascadeType.ALL + orphanRemoval=true
스스로 생명주기를 관리하는 엔티티는 em.persist()로 영속화, em.remove()로 제거
두 옵션을 모두 활성화 하면 부모 엔티티를 통해서 자식의 생명 주기를 관리할 수 있음
도메인 주도 설계(DDD)의 Aggregate Root개념을 구현할 때 유용 (나중에 찾아 보자)

DDD, Aggregate Root 란?

이번에 알아볼 것은, DDD란? Domain이란? Domain Model이란? DDD가 필요한 이유 DDD와 Aggregate Root DDD의 특징과 이유 간단히 영속성 전이, 고아 객체와의 연관 DDD(Domain Driven Design)란? 도메인 중심으로..

eocoding.tistory.com

실전 예제 5 - 연관관계 관리

글로벌 패치 전략 설정

모든 연관관계를 지연 로딩으로
@ManyToOne, @OneToOne은 기본이 즉시 로딩이므로 지연 로딩으로 변경

영속성 전이 설정

Order -> Delivery를 영속성 전이 ALL 설정
- 주문을 생성할 때 배송정보도 함께 저장하겠다는 뜻
Order -> OrderItem을 영속성 전이 ALL 설정
- 주문을 생성할 때 주문아이템도 함께 저장하겠다는 뜻

출처

자바 ORM 표준 JPA 프로그래밍 - 기본편 - 인프런 | 강의

www.inflearn.com

'spring > 인프런 강의 정리' 카테고리의 다른 글

[JPA 기본편] 10. 객체지향 쿼리 언어 (0)	2022.04.02
[JPA 기본편] 9. 값 타입 (0)	2022.03.24
[JPA 기본편] 7. 고급 매핑 (0)	2022.03.11
[JPA 기본편] 6. 다양한 연관관계 매핑 (0)	2022.03.09
[JPA 기본편] 5. 연관관계 매핑 기초 (0)	2022.03.08

[JPA 기본편] 7. 고급 매핑

2022. 3. 11. 17:46

상속관계 매핑
@MappedSuperclass
실전 예제

상속관계 매핑

상속관계 매핑

관계형 데이터베이스는 상속 관계 X
슈퍼타입 서브타입 관계라는 모델링 기법이 객체 상속과 유사
상속관계 매핑 : 객체의 상속과 구조와 DB의 슈퍼타입 서브타입 관계를 매핑
슈퍼타입 서브타입 논리 모델을 실제 물리 모델로 구현하는 방법
- 각각 테이블로 변환 -> 조인 전략
- 통합 테이블로 변환 -> 단일 테이블 전략
- 서브타입 테이블로 변환 -> 구현 클래스마다 테이블 전략

주요 어노테이션

Inheritance(strategy = InheritanceType.XXX)
- JOINED : 조인 전략
- SINGLE_TABLE : 단일 테이블 전략
- TABLE_PER_CLASS : 구현 클래스마다 테이블 전략
@DiscriminatorColumn(name = "DTYPE")
- 해당 컬럼에 DTYPE이 생기게 되고, value는 상속된 객체의 엔티티 명이 들어갑니다.
@DiscriminatorValue("XXX")
- 엔티티 명을 바꿀 수 있음, 자식 객체에 부여함

조인 전략

장점
- 테이블 정규화
- 외래 키 참조 무결성 제약조건 활용가능
- 저장공간 효율화
단점
- 조회시 조인을 많이 사용, 성능 저하
- 조회 쿼리가 복잡함
- 데이터 저장시 INSERT SQL 2번 호출

단일 테이블 전략

장점
- 조인이 필요 없으므로 일반적으로 조회 성능이 빠름
- 조회 쿼리가 단순함
단점
- 자식 엔티티가 매핑한 컬럼은 모두 null 허용
- 단일 테이블에 모든 것을 저장하므로 테이블이 커질 수 있다. 상황에 따라서 조회 성능이 오히려 느려질 수 있다.

구현 클래스마다 테이블 전략

이 전략은 데이터베이스 설계자와 ORM 전문가 둘 다 추천 X
장점
- 서브 타입을 명확하게 구분해서 처리할 때 효과적
- not null 제약조건 사용 가능
단점
- 여러 자식 테이블을 함께 조회할 때 성능이 느림(UNION SQL 필요)
- 자식 테이블을 통합해서 쿼리하기 어려움

@MappedSuperclass

@MappedSuperclass

공통 매핑 정보가 필요할 때 사용(id, name)

상속관계 매핑 X
엔티티 X, 테이블과 매핑 X
부모 클래스를 상속 받는 자식 클래스에 매핑 정보만 제공
조회, 검색 불가(em.find(BaseEntity)) 불가)
직접 생성해서 사용할 일이 없으므로 추상 클래스 권장
테이블과 관계 없고, 단순히 엔티티가 공통으로 사용하는 매핑 정보를 모으는 역할
주로 등록일, 수정일, 등록자, 수정자 같은 전체 엔티티에서 공통으로 적용하는 정보를 모을 때 사용
참고 : Entity 클래스는 엔티티나 @MappedSuperclass로 지정한 클래스만 상속가능

실전 예제

요구사항 추가

상품의 종류는 음반, 도서, 영화가 있고 이후 더 확장될 수 있다.
모든 데이터는 등록일과 수정일이 필수다.

모데인 모델

테이블 설계를 보면 ITEM이라는 테이블에 DTYPE으로 하위 테이블에 대한걸 명시해줍니다. 이처럼 설계하기 위해서는

@Inheritance(strategy = InheritanceType.SINGLE_TABLE)

SINGLE_TALBE로 해주면 ITEM 테이블에 모든 하위 테이블에 대한 정보가 저장됩니다.

@DiscriminatorColumn

DIscriminatorColumn을 추가해주면 해당 컬럼 데이터가 어떤 하위 테이블의 데이터인지 DTYPE으로 명시해줍니다.

출처

자바 ORM 표준 JPA 프로그래밍 - 기본편 - 인프런 | 강의

www.inflearn.com

'spring > 인프런 강의 정리' 카테고리의 다른 글

[JPA 기본편] 9. 값 타입 (0)	2022.03.24
[JPA 기본편] 8. 프록시와 연관관계 관리 (0)	2022.03.15
[JPA 기본편] 6. 다양한 연관관계 매핑 (0)	2022.03.09
[JPA 기본편] 5. 연관관계 매핑 기초 (0)	2022.03.08
[JPA 기본편] 4. 엔티티 매핑 (0)	2022.03.05

[JPA 기본편] 6. 다양한 연관관계 매핑

2022. 3. 9. 15:45

연관관계 매핑시 고려사항 3가지
다대일 [N:1]
일대다 [1:N]
일대일 [1:1]
다대다 [N:N]
실전 예제

연관관계 매핑시 고려사항 3가지

다중성
단방향, 양방향
연관관계의 주인

다중성

다대일 : @ManyToOne
일대다 : @OneToMany
일대일 : @OneToOne
다대다 : @ManyToMany

단방향, 양방향

테이블
- 외래 키 하나로 양쪽 조인 가능
- 사실 방향이라는 개념이 없음
객체
- 참조용 필드가 있는 쪽으로만 참조 가능
- 한쪽만 참조하면 단방향
- 양쪽이 서로 참조하면 양방향

연관관계의 주인

테이블은 외래 키 하나로 두 테이블이 연관관계를 맺는다.
객체 양방향 관계는 A -> B, B -> A 처럼 참조가 2곳. 둘 중 테이블의 외래 키를 관리할 곳을 지정해햐 함.
연관관계의 주인 : 외래 키를 관리하는 참조
주인의 반대편 : 외래 키에 영향을 주지 않음, 단순 조회기능

다대일 [N:1]

다대일 단방향

DB 설계 상 1:N의 경우 N 쪽에 외래키가 있어야 합니다.

다대일 양방향

기존에 했던 것과 다를 것 없이 양방향의 경우 TEAM 객체에 조회하하는 list만 추가하면 됩니다.

일대다 [1:N]

일대다 단방향

권장하지 않는 모델링 방법 (무조건 N 쪽에 외래 키가 있기 때문)

일대다 단방향 정리

일대다 단방향은 일대다(1:N)에서 일(1)이 연관관계의 주인
테이블 일대다 관계는 항상 다(N) 쪽에 외래 키가 있음
객체와 테이블의 차이 때문에 반대편 테이블의 외래 키를 관리하는 특이 구조
@JoinColumn을 꼭 사용해야 함. 그렇지 않으면 조인 테이블 방식을 사용함 (중간에 테이블을 하나 추가함)

일대다

JoinColumn은 꼭 해주어야함!! JoinColumn을 하지 않게되면 두 테이블을 연결시킬 새로운 테이블을 JPA에서 자동으로 만든다.

일대다 단방향 단점

엔티티가 관리하는 외래 키가 다른 테이블에 있음
연관관계 관리를 위해 추가로 UPDATE SQL 실행

그렇기때문에 일대다 단방향 매핑보다는 다대일 양방향 매핑을 사용하자. (다(N)쪽에 외래 키가 있도록)

일대다 양방향

insertable = false, updatable = false를 하게되면 읽기만 가능하게 해줍니다.

일대다 양방향 정리

일대다 양방향 매핑은 공식적으로 존재 X
@JoinColumn(insertable = false, updatable = false)
읽기 전용 필드를 사용해서 양방향처럼 사용하는 방법
다대일 양방향을 사용하자

일대일 [1:1]

일대일 관계

일대일 관계는 그 반대도 일대일
주 테이블이나 대상 테이블 중에 외래 키 선택 가능
- 주 테이블에 외래 키
- 대상 테이블에 외래 키
외래 키에 데이터베이스 유니크(UNI) 제약조건 추가

일대일 : 주 테이블에 외래 키 단방향

외래 키는 Member, Locker 어디에 넣어도 상관없다. 위의 예시에서는 Member에 외래 키를 넣었습니다. 다대일(@ManyToOne) 단방향 매핑과 유사

일대일 : 주 테이블에 외래 키 양방향

양방향으로 하고 싶다면 Member, Member 모두 필드를 추가해주면 됩니다.

일대일 : 주 테이블에 외래 키 양방향 정리

다대일 양방향 매핑처럼 외래 키가 있는 곳이 연관관계의 주인
반대편은 mappedBy 적용

일대일 : 대상 테이블에 외래 키 단방향

일대일의 경우 대상 테이블에 외래 키가 있으면 작동하지 않습니다.

일대일 : 대상 테이블에 외래 키 단방향 정리

단방향 관계는 JPA 지원 X
양방향 관계는 지원

일대일 : 대상 테이블에 외래 키 양방향

일대일 주 테이블에 외래 키 양방향과 매핑 방법은 같음

일대일 정리

주 테이블에 외래 키
- 주 객체가 대상 객체의 참조를 가지는 것 처럼
  주 테이블에 외래 키를 두고 대상 테이블을 찾음
- 객체지향 개발자 선호
- JPA 매핑 관리
- 장점
  - 주 테이블만 조회해도 대상 테이블에 데이터가 있는지 확인 가능
- 단점
  - 값이 없으면 외래 키에 null 허용
대상 테이블에 외래 키
- 대상 테이블에 외래 키가 존재
- 전통적인 데이터베이스 개발자 선호
- 장점
  - 주 테이블과 대상 테이블을 일대일에서 일대다 관계로 변경할 때 테이블 구조 유지
- 단점
  - 프록시 기능의 한계로 지연 로딩으로 설정해도 항상 즉시 로딩 됨 (프록시는 뒤에서 설명)

다대다 [N:M]

실무에서 다대다 관계는 쓰면 안된다.

관계형 데이터베이스는 정규화된 테이블 2개로 다대다 관계를 표현할 수 없음.
연결 테이블을 추가해서 일대다, 다대일 관계로 풀어내야 함.

다대다

@ManyToMany 사용
@JoinTable로 연결 테이블 지정
다대다 매핑 : 단방향, 양방향 가능

다대다 매핑의 한계

편리해 보이지만 실무에서 사용 X
연결 테이블이 단순히 연결만 하고 끝나지 않음
주문 시간, 수량 같은 데이터가 들어올 수 있음

다대다 한계 극복

연결 테이블용 엔티티 추가 (연결 테이블을 엔티티로 승격)
@ManyToMany -> @OneToMany, @ManyToOne

실전 예제

배송, 카테고리 추가 - 엔티티

주문과 배송은 1:1 (@OneToOne)
상품과 카테고리는 N:M (@ManyToMany)

배송, 카테고리 추가 - ERD

배송, 카테고리 추가 - 엔티티 상세

N:M 관계는 1:N, N:1로

테이블의 N:M 관계는 중간 테이블을 이용해서 1:N, N:1
실전에서는 중간 테이블이 단순하지 않다.
@ManyToMany는 제약 : 필드 추가 X, 엔티티 테이블 불일치
실전에서는 @ManyToMany 사용 XX

@JoinColumn

외래 키를 매핑할 때 사용

@ManyToOne

다대일 관계 매핑

@OneToMany

다대일 관계 매핑

출처

자바 ORM 표준 JPA 프로그래밍 - 기본편 - 인프런 | 강의

www.inflearn.com

'spring > 인프런 강의 정리' 카테고리의 다른 글

[JPA 기본편] 8. 프록시와 연관관계 관리 (0)	2022.03.15
[JPA 기본편] 7. 고급 매핑 (0)	2022.03.11
[JPA 기본편] 5. 연관관계 매핑 기초 (0)	2022.03.08
[JPA 기본편] 4. 엔티티 매핑 (0)	2022.03.05
[JPA 기본편] 3. 영속성 관리 - 내부 동작 방법 (0)	2022.03.05

[JPA 기본편] 5. 연관관계 매핑 기초

2022. 3. 8. 02:54

목표

객체와 테이블 연관관계의 차이를 이해
객체의 참조와 테이블의 외래 키를 매핑
용어 이해
- 방향 (Direction) : 단방향, 양방향
- 다중성 (Multiplicity) : 다대일(N:1), 일대다(1:N), 일대일(1:1), 다대다(N:N) 이해
- 연관관계의 주인 (Owner) : 객체 양방향 연관관계는 관리 주인이 필요

예제 시나리오

회원과 팀이 있다.
회원은 하나의 팀에만 소속될 수 있다.
회원과 팀은 다대일 관계다.

객체를 테이블에 맞추어 모델링 (연관관계가 없는 객체)

객체를 테이블에 맞추어 모델링 (참조 대신에 외래 키를 그대로 사용)

@Entity
public class Member {
    @Id @GeneratedValue
    private Long id;

    @Column(name = "USERNAME")
    private String name;

    @Column(name = "TEAM_ID")
    private Long teamId;
    ...
    }
    
@Entity
public class Team {
    @Id
    @GeneratedValue
    private Long id;

    private String name;
    ...
    }

test code

            //팀 저장
            Team team = new Team();
            team.setName("TeamA");
            em.persist(team);

            //회원 저장
            Member member = new Member();
            member.setName("member1");
            member.setTeamId(team.getId());
            em.persist(member);

결과

테이블에 잘 저장되고 Join도 잘 동작하는 것을 볼 수 있습니다.

객체를 테이블에 맞추어 모델링 (식별자로 다시 조회, 객체 지향적인 방법이 아니다.)

이전에 보았던 것처럼 DB를 통해서 계속해서 끄집어 내야한다.

객체를 테이블에 맞추어 데이터 중심으로 모델링하면, 협력 관계를 만들 수 없다.

테이블은 외래키로 조인을 사용해서 연관된 테이블을 찾는다.
객체는 참조를 사용해서 연관된 객체를 찾는다.
테이블과 객체 사이에는 이러한 간격이 존재한다.

단방향 연관관계

객체 지향 모델링 (객체 연관관계 사용)

변경된 코드

    //@Column(name = "TEAM_ID")
    //private Long teamId;

    @ManyToOne
    @JoinColumn(name = "TEAM_ID")
    private Team team;

@ManyToOne
- Member N : Team 1 이기 때문에 Member 객체에선 Team과 연관되는 컬럼에는 본인이 Many 팀이 One이라는 어노테이션을 추가해주어야 합니다. (연관관계 사용할 때 이러한 일대일, 다대일, 일대다, 다대다 관계의 어노테이션을 추가해야함)
@JoinColumn
- 조인해야하는 컬럼이 어떤 컬럼인지 명시해주는 어노테이션입니다. DB에 실제 존재하는 값을 찾아서 매핑합니다.

이렇게 관계와 join 컬럼만 추가해주면 끝입니다.

객체 지향 모델링

조회

            //조회
            Member findMember = em.find(Member.class, member.getId());
            //참조를 사용해서 연관관계 조회
            Team findTeam = findMember.getTeam();

Member 객체를 가져온 뒤, getTeam() 메소드만 호출하면 원하는 연관된 Team 객체를 받아올 수 있습니다. (다시 DB를 조회할 필요가 없음)

양방향 연관관계와 연관관계의 주인

양방향 매핑

이전엔 멤버 -> 팀 으로만 가능했다면 양방향 연관관계는 멤버 <-> 팀 으로 이동이 가능하게 매핑하는 것 입니다.

코드

    @OneToMany(mappedBy = "team")
    private List<Member> members = new ArrayList<>();

Team 객체에 해당 컬럼만 추가해주면 됩니다.

OneToMany는 일대다 관계라는 것을 프로그램에게 알려 주는 것이고, mappedBy는 Member객체에 있는 team이라는 변수와 매핑이 된다는 것을 나타내는 것 입니다.

테스트

            //조회
            Team findTeam = em.find(Team.class, team.getId());
            int memberSize = findTeam.getMembers().size(); //역방향 조회

위의 테스트를 해보았는데 문제가 발생했다.

기존 데이터를 em.flush()를 통해 DB에 저장한 뒤, 탐색하면 정상적으로 데이터를 가져올 수 있을 거라고 생각했지만 그렇지 못했습니다.

em.flush후 em.clear까지 해줘야지 정상적으로 데이터를 갖고올 수 있었습니다.

em.flush후 em.clear를 해야하는 이유는? em.flush를 하면 DB에 데이터가 저장이 됩니다. 그렇기 때문에 DB에 데이터를 가져올 것이라고 생각했지만, 영속성 컨텍스트에 가져오려는 데이터가 있기때문에 DB에 저장된 데이터가 아닌 영속성 컨텍스트에 있는 데이터를 가져옵니다. 여기서 문제점은 영속성 컨텍스트에 있는 Team 테이블에 members 컬럼에는 아무것도 없습니다. DB에서 조회를 하여 가져올 때는 @OneToMany를 통해 DB에서 연관된 테이블을 같이 가져오지만, 영속성 컨텍스트에 있는 Team 테이블은 그렇지 않기 때문입니다. 그렇기 때문에 em.clear를 통해 영속성 컨텍스트를 초기화 시켜준 뒤, 원하는 객체를 DB로부터 받아올 수 있도록 해줘야합니다.

연관관계의 주인과 mappedBy

mappedBy = JPA의 멘탈붕괴 난이도
mappedBy는 처음에 이해하기 어렵다.
객체와 테이블간에 연관관계를 맺는 차이를 이해해야 한다.

객체와 테이블이 관계를 맺는 차이

객체 연관관계 = 2개
- 회원 -> 팀 연관관계 단방향 1개
- 팀 -> 회원 연관관계 단방향 1개
테이블 연관관계 = 1개
- 회원 <-> 팀 연관관계 양방향 1개

테이블의 경우 fk 값 하나로 테이블의 연관관계가 끝이 납니다. 하지만 객체의 경우 참조가 객체마다 있어야합니다.

사실상 객체의 양방향 관계는 서로 다른 단방향 관계 2개입니다.

한명의 멤버가 팀을 바꾸려고 할 때 테이블에서는 fk 값만 바꿔주면 끝이납니다. 하지만, 객체의 경우 Member에 있는 team을 바꿔야할 지, Team에 있는 members를 바꿔야할지 딜레마에 빠지기 때문입니다.

그렇기때문에 객체를 매핑할 때 테이블이 fk 값하나로 연관관계를 맺는 것처럼 객체의 참조도 하나일 필요가 있습니다.

그래서 결론은 "객체도 둘 중 하나로 외래 키를 관리해야 한다"로 됩니다. 이 개념이 바로 연관관계의 주인입니다.

연관관계의 주인

객체의 두 관계 중 하나를 연관관계의 주인으로 지정
연관관계의 주인만이 외래 키를 관리 (등록, 수정)
주인이 아닌 쪽은 읽기만 가능
주인은 mappedBy 속성 사용 X
주인이 아니면 mappedBy 속성으로 주인 지정

이전에 짰던 코드를 비유하면 연관관계의 주인은 Member의 team입니다.

누구를 주인으로?

외래 키가 있는 곳을 주인으로 정해라
여기서는 Member.team이 연관관계의 주인

외래 키가 있는 곳을 주인으로 정하는 이유는 아래와 같다.

예를들어, Team.members를 외래키로 정했다고 가정해보자. members의 값을 변경하게되면 연관된 다른 테이블의 업데이트 쿼리도 나가게되는데 이렇게되면 헷갈리게 된다.
성능 이슈

양방향 연관관계와 연관관계의 주인 - 주의점, 정리

양방향 매핑시 가장 많이 하는 실수 (연관관계의 주인에 값을 입력하지 않음)

실제 코드만 보면 아무런 문제가 없어보이는 코드입니다. member 객체를 만들었고, team에 member를 추가해주었습니다. 한번 더 기억을 더듬어 보자면 저희는 이전에 mappedBy로 연관관계의 주인을 Member로 설정했습니다. 또 등록, 수정이 member를 통해서만 이루어진다고 말했었습니다. 하지만, 해당 코드에서 등록을 연관관계의 주인이 아닌 역방향으로 했습니다. 결과는 어떨까요??

위를 보다시피 매핑이 정상적으로 이루어지지 않은 모습을 볼 수 있습니다.

다시 한번 기억합시다! 연관관계 주인에 설정을 해야합니다.

그렇다면 연관관계의 주인에만 설정을 하는 것이 맞는 걸까요?? 이것도 무언가 객체지향스럽지 못합니다. 이유는 데이터를 넣지도 않았는데 이미 데이터는 들어가있기 때문입니다. 이것은 아래와 같은 두가지에서 문제가 생깁니다.

em.clear()를 하지 않은 경우 (위에 해당의 문제는 설명한 바 있습니다. 간단하게 설명하자면 영속성 컨텍스트에서 데이터를 가져오기 때문입니다. 이해되지 않는 분들은 em.clear를 하고 안하고의 차이를 주석처리해보며 직접 느껴보시길 추천합니다.)
테스트케이스를 작성할 때, member.getTeam은 되지만 team.getMembers는 동작하지 않음.

위의 이유로 "양쪽 다 데이터를 세팅하는 것이 맞는 방법이다"라고합니다.

양방향 연관관계 주의 - 실습

순수 객체 상태를 고려해서 항상 양쪽에 값을 설정하자
연관관계 편의 메소드를 생성하자
양방향 매핑시에 무한 루프를 조심하자
- 예) toString(). lombok, JSON 생성 라이브러리

연관관계 편의 메소드

연관관계 편의 메소드를 생성해 한번의 메소드로 양쪽에 값을 설정해줍니다. 위 코드는 setTeam -> changeTeam을 통해 양쪽의 연관관계를 설정해주는 코드입니다. 양쪽 연관관계를 맺는 방법은 다양한 방법이 있으니 편한 방법대로 해주시면됩니다.

양방향 매핑시 무한 루프

양방향 연관관계에서 두 객체 모두 toString을 생성한 뒤, 한쪽 객체의 toString을 사용하는 경우 member <-> team을 계속해서 부르기 때문에 stackoverflow가 발생하게 됩니다. (toString하는 경우 한쪽 방향만 이용하던가, 양방향 연관하는 컬럼의 경우 제외해주어야 합니다.) 특히, lombok으로 toString 쓰는 경우 보이지 않기때문에 조심해야합니다.

양방향 매핑 정리

단방향 매핑만으로도 이미 연관관계 매핑은 완료
양방향 매핑은 반대 방향으로 조회(객체 그래프 탐색) 기능이 추가된 것 뿐
JPQL에서 역방향으로 탐색할 일이 많음
단방향 매핑을 잘 하고 양방향은 필요할 때 추가해도 됨 (테이블에 영향을 주지 않음)

김영한님의 추천으로 단방향 매핑으로 설계를 완료하고 필요에 의해서 탐색하는 경우에만 조회용으로만 양방향으로 사용하는 것을 권장한다고 합니다.

연관관계 매핑 시작

테이블 구조

객체 구조

출처

자바 ORM 표준 JPA 프로그래밍 - 기본편 - 인프런 | 강의

www.inflearn.com

'spring > 인프런 강의 정리' 카테고리의 다른 글

[JPA 기본편] 7. 고급 매핑 (0)	2022.03.11
[JPA 기본편] 6. 다양한 연관관계 매핑 (0)	2022.03.09
[JPA 기본편] 4. 엔티티 매핑 (0)	2022.03.05
[JPA 기본편] 3. 영속성 관리 - 내부 동작 방법 (0)	2022.03.05
[JPA 기본편] 2. JPA 시작하기 (0)	2022.02.21

[JPA 기본편] 4. 엔티티 매핑

2022. 3. 5. 16:40

객체와 테이블 매핑

엔티티 매핑 소개

객체와 테이블 매핑
- @Entity, @Table(name = "테이블 명")
필드와 컬럼 매핑
- @Column(name = "컬럼 명")
기본 키 매핑
- @Id
연관관계 매핑
- @ManyToOne, @OneToMany, @ManyToMany, @OneToOne, @JoinColumn

@Entity

@Entity가 붙은 클래스는 JPA가 관리하는 엔티티
JPA를 사용해서 테이블과 매핑할 클래스는 @Entity 필수
주의
- 기본 생성자 필수 (파라미터가 없는 public 또는 protected 생성자)
- final 클래스, enum, interface, inner 클래스 사용 X
- 저장할 필드에 final 사용 X

@Table

@Table은 엔티티와 매핑할 테이블 지정

데이터베이스 스키마 자동 생성

데이터베이스 스키마 자동 생성

DDL을 애플리케이션 실행 시점에 DB 자동 생성
테이블 중심 -> 객체 중심
데이터베이스 방언을 활용해서 데이터베이스에 맞는 적절한 DDL 생성
이렇게 생성된 DDL은 개발 장비에서만 사용
생성된 DDL은 운영서버에서는 사용하지 않거나, 적절히 다듬은 후 사용

데이터베이스 스키마 자동 생성 - 속성

hibernate.hbm2ddl.auto

데이터베이스 스키마 자동 생성 - 주의

운영 장비에는 절대 create, create-drop, update 사용하면 안된다.
개발 초기 단계는 create 또는 update
테스트 서버는 update 또는 validate
스테이징과 운영 서버는 validate 또는 none

운영 같은 경우 몇천만건 있는 상태에서 alter를 잘못치면 시스템이 중단상태가 될 수 있다. 애플리케이션 로딩시점에 시스템에서 자동으로 alter 친다는 것은 매우 위험하다.

DDL 생성 기능

제약조건 추가 : 회원 이름은 필수, 10자 초과X
- @Column(nullable = false, length = 10)
유니크 제약조건 추가
- @Table(uniqueConstraints = {@uniqueConstraint( name = "NAME_AGE_UNIQUE",
  columnNames = {"NAME", "AGE"})})
DDL 생성 기능은 DDL을 자동 생성할 때만 사용되고 JPA의 실행 로직에는 영향을 주지 않는다.

필드와 컬럼 매핑

요구사항 추가

회원은 일반회원과 관리자로 구분해야 한다.
회원가입일과 수정일이 있어야 한다.
회원을 설명할 수 있는 필드가 있어야 한다. 이 필드는 길이 제한이 없다.

Member 클래스 수정

@Entity
public class Member {
    @Id
    private Long id;

    @Column(name = "name")
    private String username;

    private Integer age;

    @Enumerated(EnumType.STRING)
    private RoleType roleType;

    @Temporal(TemporalType.TIMESTAMP)
    private Date createdDate;

    @Temporal(TemporalType.TIMESTAMP)
    private Date lastModifiedDate;

    @Lob                    // 데이터베이스에 varchar를 능가하는 큰 문자열을 넣을 때 Lob 사용
    private String description;

    public Member(){}
}

테이블이 create된 출력

description이 clob인 이유는 String으로 선언했기 때문
enum은 varchar로 매핑

매핑 어노테이션 정리

@Column

@Enumerated

자바 enum 타입을 매핑할 때 사용

주의! ORDINAL 사용 X (순서로 하게되면 1,2,3 이런식으로 저장되는데 문제는 Enum의 데이터를 추가할 경우 기존의 데이터가 바뀌지 않아 문제가 생긴다.)

@Temporal

날짜 타입(java.util.Date, java.util.Calendar)을 매핑할 때 사용

참고 : LocalDate, LocalDateTime을 사용할 때는 생략 가능(최신 하이버네이트 지원)

@Lob

데이터베이스 BLOB, CLOB 타입과 매핑

@Lob에는 지정할 수 있는 속성이 없다..
매핑하는 필드 타입이 문자면 CLOB 매핑, 나머지는 BLOB 매핑
- CLOB : String, char[], java.sql.CLOB
- BLOB : byte[], java.sql.BLOB

@Transient

필드 매핑 X
데이터베이스 저장 X, 조회 X
주로 메모리상에서만 임시로 어떤 값을 보관하고 싶을 때 사용

기본 키 매핑

기본 키 매핑 방법

직접 할당 : @ID만 사용
자동 생성(@GeneratedValue)
- IDENTITY : 데이터베이스에 위임, MYSQL
- SEQUENCE : 데이터베이스 시퀀스 오브젝트 사용, ORACLE
  - @SequenceGenerator 필요
- TABLE : 키 생성용 테이블 사용, 모든 DB 에서 사용
  - @TableGenerator 필요
- AUTO : 방언에 따라 자동 지정, 기본값

Identity 전략 - 특징

기본 키 생성을 데이터베이스에 위임
주로 MySQL, PostgreSQL, SQL Server, DB2에서 사용 (예, MySQL의 AUTO_INCREMENT)
JPA는 보통 트랜잭션 머킷 시점에 INSERT SQL 실행
AUTO_INCREMENT는 데이터베이스에 INSERT SQL을 실행한 이후에 ID 값을 알 수 있음
IDENTITY 전략은 em.persist() 시점에 즉시 INSERT SQL 실행하고 DB에서 식별자를 조회
JDBC 드라이브에 insert 쿼리를 날릴 때 return을 받는 것이 내부적으로 되어있기 때문에 select 쿼리문을 날리지 않고 insert 만으로 기본 키를 넣을 수 있음
persist 시점에 insert SQL을 실행하기 때문에 버퍼링을 이용한 성능 최적화를 할 수 없다.

Sequence 전략 - 특징

데이터베이스 시퀀스는 유일한 값을 순서대로 생성하는 특별한 데이터베이스 오브젝트 (예 : 오라클 시퀀스)
오라클, PostgreSQL, DB2, H2 데이터베이스에서 사용
em.persist() 일 때 DB에서 Sequence만 갖고와서 영속성 컨텍스트에 저장하면서, insert 쿼리문도 함께 SQL저장소에 저장한 뒤, 트랜잭션 commit 시점에 insert 쿼리문을 DB에 전송
따라서, 버퍼링 기능을 사용 가능
하지만, persist에서 SEQ 값을 갖고 오기위해 네트워크를 이용하는 것 때문에 성능에 문제가 생길 수 있습니다. SEQ값을 갖고오는 것보다 Insert 쿼리문을 날리는게 성능에 더 좋아진다고 생각할 것 입니다.
이를 해결하기 위해, allocationSize를 이용하면됩니다. allocationSize에 할당한 수만큼 데이터가 모일 때 SEQ 값을 증가시키는 아래와 같은 쿼리문을 보냅니다.

Sequence 전략 - 매핑

Sequence - @SequenceGenerator

Table 전략

키 생성 전용 테이블을 하나 만들어서 데이터베이스 시퀀스를 흉내내는 전략
장점 : 모든 데이터베이스에 적용 가능
단점 : 성능
- 최적화가 되어있지 않기 때문에 성능이 떨어진다.

Table 전략 - 매핑

알아서 테이블과 컬럼이 생성되고, select와 update문을 날리면서 동작

테이블을 하나 만들어서 관리하는게 있어보이지만, 성능상 좋지 않기 때문에 잘 사용하지는 않는다고 합니다.

권장하는 식별자 전략

기본 키 제약 조건 : null 아님, 변하면 안된다.
미래까지 이 조건을 만족하는 자연키는 찾기 어렵다. 대리키(대체키)를 사용하자.
예를들어, 주민등록번호도 기본키로 적절하지 않다.
권장 : Long형 + 대체키 + 키 생성전략 사용

실전 예제 1 - 요구 사항 분석과 기본 매핑

요구사항 분석

회원은 상품을 주문할 수 있다.
주문 시 여러 종류의 상품을 선택할 수 있다.

기능 목록

회원 기능
- 회원 등록
- 회원 조회
상품 기능
- 상품 등록
- 상품 수정
- 상품 조회
주문 기능
- 상품 주문
- 주문 내역 조회
- 주문 취소

도메인 모델 분석

회원과 주문의 관계 : 회원은 여러 번 주문할 수 있다. (일대다)
주문과 상품의 관계 : 주문할 때 여러 상품을 선택할 수 있다. 반대로 같은 상품도 여러 번 주문될 수 있다. 주문상품이라는 모델을 만들어서 다대다 관계를 일다대, 다대일 관계로 풀어냄

테이블 설계

엔티티 설계와 매핑

엔티티 설계를 보며, 프로젝트에 Entity로 추가합니다. (Order 클래스에 status는 enum 타입입니다.)

참고

    <dependency>
            <groupId>javax.xml.bind</groupId>
            <artifactId>jaxb-api</artifactId>
            <version>2.3.1</version>
    </dependency>

자바 11이상 버전을 이용하면 위의 라이브러리를 pom.xml에 추가해주어야합니다. java 11부터는 Java ee 모듈이 제거되어 jaxb 라이브러리를 꼭 추가해줘야 된다고 합니다.

엔티티를 추가한 뒤, 코드를 돌렸을 때 create table 로그가 출력되고 콘솔에 테이블이 만들어지면 잘 작동된 것 입니다.

근데 자세히보면 Member와 Order의 관계를 만들어주는 Order엔티티에 memberId의 자료형은 Long입니다. 조금 더 객체지향적으로 설계하기 위해선 자료형을 Member로 선언해야 할 것입니다. 그렇다면 객체지향적으로 설계된 엔티티와 그렇지 않은 엔티티의 차이점은 어떨까요?

자료형을 Long, 클래스로 하는 것의 차이점은 아래의 예시를 들어 확인해보도록 하겠습니다.

자료형을 Member로 하면 order.getMember()를 통해 한번의 작업으로 원하는 Member 엔티티를 얻어올 수 있습니다. 하지만, 객체지향적으로 설계하지 않은 Long의 자료형은 order.getMemberId()를 통해 memberid를 받아오고 해당 memberid를 통해 다시 또 엔티티를 찾아주는 작업을 해야합니다. 즉, Long 자료형의 경우 두번의 작업을 해야합니다.

위의 같은경우는 Order -> Member 한번의 이동의 차이점을 본 것인데요. 이러한 엔티티간의 이동이 많은 경우 객체지향적으로 설계한 것이 더 편리하다는 것을 느낄 수 있을 것 입니다.

데이터 중심 설계의 문제점

현재 방식은 객체 설계를 테이블 설계에 맞춘 방식
테이블의 외래키를 객체에 그대로 가져옴
객체 그래프 탐색이 불가능
참조가 없으므로 UML도 잘못됨

출처

자바 ORM 표준 JPA 프로그래밍 - 기본편 - 인프런 | 강의

www.inflearn.com

'spring > 인프런 강의 정리' 카테고리의 다른 글

[JPA 기본편] 6. 다양한 연관관계 매핑 (0)	2022.03.09
[JPA 기본편] 5. 연관관계 매핑 기초 (0)	2022.03.08
[JPA 기본편] 3. 영속성 관리 - 내부 동작 방법 (0)	2022.03.05
[JPA 기본편] 2. JPA 시작하기 (0)	2022.02.21
[JPA 기본편] 1. JPA 소개 (0)	2022.02.19

PREV 1 2 3 4 5 6 7 8 NEXT

spring

'spring > 인프런 강의 정리' 카테고리의 다른 글

객체지향 쿼리 언어 소개

기본 문법과 쿼리 API

프로젝션

페이징 API

조인

서브 쿼리

JPQL 타입 표현

조건식 - CASE 식

JPQL 함수

경로 표현식

JPQL - 페치 조인 (fetch join)

JPQL - 다형성 쿼리

JPQL - 엔티티 직접 사용

JPQL - Named 쿼리

JPQL - 벌크 연산

'spring > 인프런 강의 정리' 카테고리의 다른 글

기본값 타입

임베디드 타입 (복합 값 타입)

값 타입의 비교

값 타입 컬렉션

실전 예제 6 - 값 타입 매핑

'spring > 인프런 강의 정리' 카테고리의 다른 글

프록시

즉시 로딩과 지연 로딩

영속성 전이 : CASCADE와 고아 객체

실전 예제 5 - 연관관계 관리

'spring > 인프런 강의 정리' 카테고리의 다른 글

상속관계 매핑

@MappedSuperclass

실전 예제

'spring > 인프런 강의 정리' 카테고리의 다른 글

다대일 [N:1]

일대다 [1:N]

일대일 [1:1]

다대다 [N:M]

실전 예제

'spring > 인프런 강의 정리' 카테고리의 다른 글

단방향 연관관계

양방향 연관관계와 연관관계의 주인

양방향 연관관계와 연관관계의 주인 - 주의점, 정리

연관관계 매핑 시작

'spring > 인프런 강의 정리' 카테고리의 다른 글

객체와 테이블 매핑

데이터베이스 스키마 자동 생성

필드와 컬럼 매핑

기본 키 매핑

실전 예제 1 - 요구 사항 분석과 기본 매핑

'spring > 인프런 강의 정리' 카테고리의 다른 글

티스토리툴바

객체와 테이블 매핑