개발자의 기록습관

[Spring]Jackson json deserialize시 snake_case to camelCase

nroo — Wed, 24 Jun 2020 11:42:40 +0900

RestTemplate으로 외부 연동 API 응답 값을 받을때 굉장히 다양한 case convention을 경험할 수 있다.
하지만 restTemplate에 기본적으로 등록되어 있는 messageConverters에서는 필드 매핑시 snake_case를 제대로 매핑하지 못해서 null이 들어가는 경우가 있다.
restTemplate에 Spring이 이미 등록한 기본 MappingJackson2HttpMessageConverter보다 우선하도록 새롭게 커스텀한 messageConverter를 등록하자.
jackson version 2.7 이전에서는

PropertyNamingStrategy. CAMEL_CASE_TO_LOWER_CASE_WITH_UNDERSCORES 를
이후 버전에서는 PropertyNamingStrategy.SNAKE_CASE 를 사용해야 한다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20 // AdapterConfig.java

...


private ObjectMapper createCustomObjectMapper() {
  ObjectMapper objectMapper = new ObjectMapper();
  objectMapper.setPropertyNamingStrategy(PropertyNamingStrategy.SNAKE_CASE);
  return objectMapper;
}
 
private MappingJackson2HttpMessageConverter createMappingJackson2HttpMessageConverter() {
  MappingJackson2HttpMessageConverter converter = new MappingJackson2HttpMessageConverter();
  converter.setObjectMapper(createCustomObjectMapper());
  return converter;
}
 
@Bean(name = "restTemplate")
public RestTemplate restTemplate() {
  RestTemplate restTemplate = new RestTemplate(clientHttpRequestFactory());
  restTemplate.getMessageConverters().add(0, createMappingJackson2HttpMessageConverter());
  return restTemplate;
}

...

Colored by Color Scripter cs

[AWS] EC2 서버 생성, 접속시 필수 설정

nroo — Fri, 27 Dec 2019 01:19:00 +0900

아마존 리눅스 1 서버 기준

EC2 서버 접속 간소화

Mac 기준

EC2 서버로 SSH 접속하려면 매번 pem파일과 ip를 입력해야 한다.

$ ssh i {pem 키 위치} {public Ip주소}
~/.ssh/ 디렉토리로 pem 파일을 옮겨 놓으면 ssh 실행 시 pem 키 파일을 자동으로 읽어 접속할 수 있다.

$ cp {pem키 위치} ~/.ssh/
pem키 권한 변경

$ chmod 600 ~/ssh/{pem 키}
pem키가 있는 ~/.ssh 디렉토리에 config 파일 생성

$ vim ~/.ssh/config

# myServiceName용 접근 설정
Host myServiceName
   HostName {public Ip 주소}
   User ec2-user
   IdentityFile ~/.ssh/myServiceName.pem

config 파일 권한 변경

$ chmod 700 ~/.ssh/config
아래와 같이 간소화된 명령어로 EC2 접근

$ ssh myServiceName

Java8 설치

아마존 리눅스 1의 경우 기본 자바 버전이 7, 프로젝트 버전에 맞게 변경.

$ sudo yum install -y java-1.8.0-openjdk-devel.x86_64
$ sudo /usr/sbin/alternatives --config java
Java8 선택 후 변경 완료 확인: $ java -version
Java7 제거: $ sudo yum remove java-1.7.0-openjdk

Timezone 변경

EC2 서버의 기본 타임존은 UTC다. 한국과는 9시간 차이 발생. 애플리케이션에서 생성되는 시간도 모두 9시간 차이나게 됨. 필수 변경 사항.
$ sudo rm /etc/localtime
$ sudo ln -s /usr/share/zoneinfo/Asia/Seoul /etc/localtime
변경 확인 $ date

Hostname 변경

여러 서버를 관리 중일 경우 IP만으로 어떤 서비스의 서버인지 확인이 어려움
해당 서비스를 표현하기 위해 HOSTNAME 변경
$ sudo vim /etc/sysconfig/network

변경 전

NETWORKING=yes
HOSTNAME=localhost.localdomain
NOZEROCONF=yes

변경 후

NETWORKING=yes
HOSTNAME=myServiceName
NOZEROCONF=yes

hostname 변경 확인
$ sudo reboot

추가 설정 사항
- 호스트 주소를 찾을 때 가장 먼저 보는 /etc/hosts에 변경한 hostname을 등록해야 한다.
- 이유는 hostname이 /etc/hosts에 등록되지 않아서 장애가 발생할 수 있기 때문이다.
  - 우아한형제들 기술 블로그 - 빌링 시스템 장애, 이러지 말란 Maria~
  - $ sudo vim /etc/hosts
  - hostname 추가 등록
    - 127.0.0.1 myServiceName
    - curl로 확인
      - $ curl myServiceName
        정상 등록 됐다면 80 포트 접근 불가 메시지
        curl: (7) Fail to connect .... port 80: Connection refused
        비정상이라면 호스트 찾지 못했음을 나타내는 메시지
        Could not resolve host: ...

Reference

스프링 부트와 AWS로 혼자 구현하는 웹 서비스 - 이동욱
http://woowabros.github.io/experience/2017/01/20/billing-event.html

NHN FORWARD 2019 후기

nroo — Thu, 28 Nov 2019 11:46:42 +0900

NHN TOAST FORWARD 2019

2019.11.27
한줄 후기
최근에 가봤던 컨퍼런스중에 실무와 가까이 있다고 생각되는 주제들이 가장 많았습니다. 이미 팀에서 도입해서 사용하고 있거나, 우리가 내년에 개선하고자 하는 것들에 대한 주제 위주로 들었는데요, 우리와 비슷한 고민들을 하고 있는 것 같았습니다.

1. '깃' 깔나는 Git 워크플로우 알아보기

NHN Edu 서버개발팀 - 신승엽

주요 Git 워크플로우 살펴보기

Git flow
- 항상 존재하는 브랜치
  - master 브랜치
  - develop 브랜치
- 서포팅 브랜치
  - 필요할 때 생성 후 삭제하는 브랜치
  - feature 브랜치
    - 특정 feature의 개발이 완료되면 다시 develop으로 merge 이때, fast forward 하지 않도록 주의
  - release 브랜치
    - feature들이 포함된 develop 에서 따고, 릴리즈 후엔 master와 develop에서 merge
  - hotfix 브랜치
    - master에서 출발
GitHub flow
- Git glow는 대부분의 케이스에서는 너무 복잡하다
- 사람들이 워크 플로우를 이해하기 쉽게 되어 실수가 없어지고 헤메지 않게 되었다고 설명함
- Master 브랜치가 항상 stable한 상태여야 한다. 현재 master 그대로 배포되어도 이상하지 않은 상태로 유지해야 한다.
- 새로운 기능을 개발할 때는, Topic 브랜치를 master 브랜치에서 딴다.
  - 기능 개발
  - Pull request 개설
  - 코드 리뷰 / 논의
  - 완료된 토픽 브랜치를 그대로 배포한다.
    - 토픽 브랜치 배포시 반드시 CI 빌드를 통과해야 하며
    - 락이 가능하다
    - Master 브랜치의 최신 커밋이 존재하는지 확인해서 충돌을 막는다.
  - 배포 후 이상없다면, master에서 해당 토픽 브랜치 merge
    - 이때 배포 락이 해제 된다.
GitLab flow
- git flow는 너무 복잡하며, github flow는 너무 간단하다
- 지속적인 배포가 어려울 때
  - github flow는 마스터를 실서버에 그대로 배포하는 컨셉인데, 대부분의 회사에서 불가능할 수 있다.
  - 이럴경우 production 브랜치를 관리하고, production에서 master를 merge해서 배포한다.
  - 배포버전 관리에 용이하다.
- 환경별 배포가 필요할 때
  - master는 staging에 자동 배포되고
  - Pre-production, production 브랜치 두개를 관리할 수 있다.
- 릴리즈 소프트웨어일 때
  - 마스터에서 버전별 stable 브랜치를 따서 배포한 후
  - 핫픽스의 경우 master에서 수정하고 각 버전의 stable 브랜치로 cherry pick 한다.
  - 이것은 마치 리눅스에서 hotfix 하고, 각 배포판에 적용하는 것과 같은 원리이다.

우리는 이렇게 해요

브랜치 전략
- 상황
  - 단기간의 배포 일정인 경우
    - 배포 날짜로 관리. develop-20191121 등
  - 장기간의 배포 일정인 경우
    - 코드네임으로 관리. develop-tomato 등
- git flow base
- develop 브랜치에서 위의 상황에 맞는 각 sub develop 브랜치를 따고
- sub develop 브랜치 개발이 완료되면 QA를 진행한다.
- 사실 이 정책의 경우 릴리즈 브랜치가 필요 없다. sub develop이 명확하다.
- sub develop 개발 후 QA가 끝나서 배포가 완료되면, master와 develop에서 merge한다.
- 나머지 sub develop을 현재 develop에 rebase 한다.
  - 연속되는 충돌이 있을 경우 -> 영상 참조
  - 같은 이름의 sub develop 브랜치를 새로 따고, 체리픽 활용
- 핫픽스는 master에서 따서 완료후 master, develop merge
- 핫픽스 브랜치 merge 후에 sub develop들을 develop에 다시 merge.
- 현재 포털개발팀 TV줌파트에서 쓰는 방식과 매우 유사함. (릴리즈 브랜치 관리는 협업 환경에 따라 다르다고 생각함)
개발 플로우

2. 레거시 웹 서비스 길들이기 : 서버 개발자의 SPA 적용기

NHN 클라우드 프레임워크 개발팀 - 최강훈
웹 개발은 백엔드와 프런트엔드로 나눠서 전문성을 가지고 개발하는 게 트렌드입니다. 그러나, 이미 서비스 중인 덩치 큰 일체형 웹 서비스를 나누는 건 막막하고 두려운 일입니다. 이 세션에서는 서버 개발자 관점에서 SPA를 도입하여 레거시 웹 서비스라는 괴물을 길들였던 경험과 고민을 공유하고자 합니다.
프롤로그: 무엇이 문제인가?
1막: 워밍업
2막: 본격 분리 작업
에필로그: 1년간 운영해보니...

프롤로그 : 무엇이 문제인가?

일체형 웹 서비스(with MVC) 방식은 기능과 화면이 적을 땐 괜찮았다.
점점 비대해지는 웹 서비스
- 모두가 꺼리게 된 자바스크립트 코드
- 페이지는 무거워지고 서스테이닝은 점점 어려워 진다.
어떻게 하면 될까요?
- SPA를 도입하자.
- 웹 페이지 구현에 필요한 모든 정적 리소스를 최초 한번 다운 받고
- 이후 필요한 데이터는 그때그때 비동기로 받아서 화면을 만든다.
- 하나의 페이지만 존재하고 페이지 전환 및 구성을 자바스크립트로 구현한다.
  - 장점
    - 성능 개선
    - 불필요한 네트워크 통신이 없어 진다
  - 단점
    - 검색엔진 최적화에 어려움이 있다
  - 언제 쓰면 좋은가?
    - UI 구성이 복잡하고, 데이터가 많이 필요한 웹 페이지
    - 페이지 내에 정적인 요소보다 동적인 요소가 많은 경우
    - 로그인을 필수로 해야되는 경우(검색엔진 최적화가 불필요한 경우)
  - 개편에 앞서 동료와 협업 부서 설득하기.

워밍업

무기를 고르자
- 앵귤러, 리액트, vue.js
  - 뭐가 제일 좋을까?(X)
  - 뭐가 우리 조직에 잘 맞을까?(O)
  - 앵귤러
    - 모든걸 갖췄지만 러닝커브가 높다
  - 리액트
    - 강력한 기능을 가지고 있지만, 더 필요한 도구는 필요에 따라서 선택해야 한다.
  - vue.js
    - 최소한의 있을건 다 있고, 배우기 쉬우며, 빠르게 만들어 낼 수 있다.
우리 팀은 어떤가?
- 자바 개발자가 많고, 자바스크립트 개발 비중은 상대적으로 적은 편
Vue.js 를 골랐다
- 러닝커브가 가장 낮고, 가이드 문서도 잘 되어 있다.
- single file component로 개발하면 하나의 파일에서 컴포넌트 단위로 작업할 수 있다.(퍼블리싱 팀과 협업시 용이)
많이 변해버린 자바스크립트
- ES6 문법이다.
  - let, const
  - Arrow function
  - import, export
  - class
  - 등 구글링해서 10분만 보자.
- webpack 설정은 어떻게?
  - 프론트엔드 프레임워크를 도입할때 최대 고비.
  - gradle 학습할때와 비슷한 느낌으로 공부하자..

본격 분리 작업

프로젝트 구성
- Back-end, Front-end 어떻게 구성할까?
- 어떻게든 둘을 합쳐보자
  - Spring-boot-vuejs
    - 부트와 vuejs를 maven으로 한번에 빌드
- 빌드 프로세스
  - 프론트 엔드 빌드
  - 백엔드 리소스 디렉토리에 copy
  - 백엔드 빌드
- 모든 요청을 was에서 해결하기
  - static 파일인데도 was로 서비스 해야되나?
  - UI 변경이 잦은 편인데, 매번 백엔드 포함하서 빌드/배포 해야되나?
  - 전과 차리가 없는데?
  - UI요청과 API 요청을 구분하자
    - 리소스 요청은 웹서버에서
    - 나머지는 was에서
- 결론
  - 굳이 둘을 섞어서 프로젝트를 구성할 필요가 없었다.
  - 모놀리스 개발을 하다보니 합치는 것에 강박이 있었던 것 같다.
  - 백엔드 프로젝트와 프론트엔드 프로젝트는 과감하게 나누자
API 호출 방식
- 일체형 웹 서비스에서는?
  - 서버 렌더를 위해 API 명세에 맞는 VO클래스를 만들어야 한다.
  - 클라이언트 렌더링에서도 이렇게 해야 될까?
    - API Gateway 사용 - 많은 기능중 API 라우팅 기능에 집중
    - Zuul 사용
      - 부트에서 간단하게 적용 가능
  - 백엔드는 API Gateway의 역할을 충실하게 하게 된다.
    - 기존의 VO를 제거하고 json으로 쭉쭉 내리면 된다.
- 결론
  - API Gateway를 적용하고 불필요한 중복 코드를 걷어내자.
상태 관리
- 프론트엔드의 복잡한 컴포넌트 간 데이터 전달
- 컴포넌트간 의존 관계가 복잡하다.
  - 컴포넌트 통신이나 이벤트 버스로는 벅차다
  - 중략 ...
  - 상태 관리 라이브러리 vuex 사용하자는 결론
- vuex 사용 팁
  - api 호출 횟수 줄여보기
    - lodash의 debounce를 적용하여 여러 번 호출해도 한 번만 호출되도록 구성
    - 이미 로드한 데이터라면 추가로 호출되지 않도록
  - 데이터 가공은 어떻게?
    - RxJS에는 데이터 가공을 위한 유용한 연산자가 많이 존재함
  - vuex의 state, getter는 컴포넌트뿐만 아니라 다른 곳에서도 호출이 가능하다.
    - router에서 사용하면 데이터 로딩이 완료된 다음에 화면을 노출할 수 있음(서버 렌더링 처럼 보이는 효과)
- 결론
  - 상태관리 라이브러리 사용해서 중앙 집중식 데이터 관리 하자
다국어 처리
- Spring MVC에서 다국어 처리
  - Spring MessageSource 사용
  - 서버 렌더 방식이다 보니 언어 변경을 하려면 반드시 새로 고침
- 이제 다국어 처리도 프론트엔드에서
  - vue-i18n 플러그인 사용
  - 새로고침 없이도 언어 변경 가능
- 아직 남아있는 문제점
  - 문구 수정 요청이 잦다
  - 문구 수정을 위해서는 여전히 빌드/배포가 필요하다.
- 해결 책
  - 메시지 서비스를 만들자
  - 다국어 메세지를 관리하는 통합 메세지 서비스
  - 동일한 key를 사용하여 4개 국어 저장
  - 빌드 배포를 하지 않더라도 메세지 서비스에 요청해서 처리할 수 있다.
배포 환경에 따른 설정 값 처리
- 프론트엔드에서는 배포 환경에 따라 설정값을 어떻게 처리?
  - development
  - production
- 실무에서는?
  - 팀, 프로젝트마다 사용중인 환경설정이 제각각
- webpack 설정 파일의 분리
  - 각 환경별로 webpack 설정 파일 분리
  - DefinePlugin 사용하여 각 환경별로 다른 설정값 추가
  - package.json에서 각 환경에 맞게 빌드 명령어 구성

에필로그 : 1년간 운영해보니...

성능 측면
- 확실히 줄어든 API 호출 횟수
- 웹 리소스 최적화
  - 웹팩 빌드 최적화 되면서 리소스 용량 작아짐
운영 측면
- 빌드/배포는 꼭 필요할 때 필요한 모듈만
개발 측면
- 프론트엔드 프레임워크의 도입
  - 규칙과 일관성이 생긴 코드
  - ESLint가 많이 도와줌
  - 가독성 증가
  - 재사용 가능한 컴포넌트 개발 지향
- 백엔드는 데이터에만 집중하기
  - 서버 렌더링이 없으니 데이터만 생각하면 됨
  - API Gateway의 역할에 집중

3. Spring Data JPA의 사실과 오해

NHN Dooray개발실 - 신동민
Spring JPA의 사실과 오해
연관 관계 맵핑에 대한 모든 것
Spring Data JPA Repository의 숨겨진(?) 기능

요약

연관관계 매핑
- 사실상 단방향 매핑만으로 연관관계 매핑은 이미 완료
- 대개의 경우 단방향 매핑이면 충분하다.
- 하지만, 일대다 단방향 연관관계 매핑에서 영속성 전이(cascade)를 사용할 경우 양방향으로 변경하자
  - 추가 update 쿼리 방지
Spring Data JPA Repository

JpaRepository 상속하면 웬만한 CRUD, Paging, Sorting 메서드 사용가능
메서드 이름 규칙을 통한 쿼리 생성 가능
- 이름 규칙에 따라 interface에 메서드 선언만 하면 쿼리 생성
JPA Repository 메서드로도 JOIN 쿼리 수행 가능
- 이름 규칙에 따라 Entity 내 연관관계 필드 탐색함
JPA Repository 메서드에서도 다양한 DTO
Projection 지원

Dynamic DTO Projection도 가능하다.

관련 예제

https://www.baeldung.com/spring-data-jpa-projections

4. 바르게, 빠르게! Reactive를 품은 Spring Kafka

NHN 이병찬
Kafka 메시지를 비동기로 처리하는 방법
ReactiveX에서 제공하는 연산자를 활용하는 사례
Project Reactor의 내부 구조(Publisher-Subscriber 간 처리 흐름)
예제 코드 저장소 - https://github.com/EleganceLESS/nhn-forward-2019

01. Kafka 그리고 Spring

가장 인기 있고 대중적인 스트리밍 플랫폼
Spring에서 Kafka 쓰는 방법이 매우 간단해 졌다. JMS 리스너와 유사.
제약 조건
- 1스레드당 1개의 일감을 처리할 수 있는데, 일감이 오래걸리면 병목이 발생한다.
- 병렬로 처리할 순 있으나 동일한 문제는 여전히 존재 한다.
스트리밍 플랫폼의 본질?
- producer의 publish
- consumer의 subscribe
- 그 사이의 stream
Kafka를 reactive하게 사용하기 위해 Reactor Kafka 또는 Spring Kafka 사용
- producer가 publish 할 때, Flux를 만들어서 stream에 밀어 넣는다.
- consumer도 subscribe 할 때, Flux로 가져와서 처리한다.

02. 적용 프로젝트 소개

서버 모니터링 시스템에서 reactive kafka를 활용했다
기본 로직은 서버에서 메트릭 정보를 가져와서 메트릭DB에 넣고 그것을 보여준다.
그 사이에서 Detector(관찰자)가 존재하여 메트릭 정보를 활용해 사용자에게 Event를 전달한다.
이 때 Detector는 수 많은 서버에서 오는 메트릭을 다 관장해야 한다. 커버링 범위가 매우 크다.
- 1000 대 이상의 서버에서 동시다발적으로 이벤트가 감지되면?
- 해당 이벤트가 짧은 간격으로 수차례 반복하면?
어쨋든 이상 이벤트 통지에 지연이 발생해서는 안되며, 각 이벤트는 상호 독립성이 보장되어야 한다.

03. 기본 기능 구현

이벤트가 발생하면 Detector는 그 정보를 메세지로 만들고 스트림에 집어 넣는다.
이벤트 프로세서에서는 메세지를 읽고 DB에 기록 후, 필요하면 메세지 발송 요청을 보내자.

04. 메세지 중복 제거

서버에서 Dector에게 데이터 보내고, 문제가 있으면 Event에 집어 넣는다.
우리는 Detector가 매우 중요하므로 HA 구성을 하게 된다.
2대의 Detector는 2개의 input과 2개의 ouput이 발생한다. 이벤트 중복을 제거하자.
- Flux Operator의 sampleFirst(), groupBy()를 이용해서 처리

05. 데이터 모아서 처리하기

최악의 상황의 경우? 동시다발적 또는 많은 양의 메세지 발생
기준 시간 동안 발생한 여러 이벤트는 하나의 메세지로 모아서 통지하자.
- 발생하는대로 메세지를 보내게 되면 1000건 발생하면 1000개의 메세지를 받게 된다.
- ex) 30초 단위로 버퍼에 쌓아서 1건으로.
Flux Operator의 buffer() 이용해서 처리 가능하다.

public void process() {
  consume().flatMap(this::recordToNotifyObject)
    .groupBy(Message::key)
    .flatMap(flux -> flux.buffer(Duration.ofSeconds(30))) //버퍼링 - 30초
    .flatMap(this::notify)
    .flatMap(this::saveResult)
    .subscribe();
}

06. 정해진 양 만큼만 처리

우리가 잘 만들었다고 쳐도, 이 시스템을 사용하는 연관 시스템이 해당 API Call을 견딜 수 있는지 확인해야 한다.
API 서버도 reactive하게 만들었다. 해결 됐지 않나?
- 결국 그 요청은 DB가 다 받는다.
발송 시스템의 경우에도 과도하게 요청을 다 보내면 과금이 어마어마하게 늘어난다.
Custom Subscriber를 만들어서 subscribe할 때, hookOnSubscribe() 를 정의할 수 있다. (정해진 양 만큼 발송)

07. 시간을 달리는 메시지

subscribe 시작시점에는 순차지만, 비동기기 때문에 끝나는 시점에 순서를 보장할 수 없다.
request(4)로 요청해서 1243 순서로 끝났는데 서버가 뻗었다.
그 다음 요청은 3부터 시작해서 onNext() 4567을 처리하게 된다.
해결 - offset이 증가하는 경우에만 commit을 하자.
- 코드는 추후 제공되는 영상 참조

08. 몇 가지 결론

많이 공부하고, 많이 고민하고, 적게 코딩하자

우아한 Redis 세미나 후기

nroo — Fri, 22 Nov 2019 14:05:47 +0900

우아한 레디스

2019.11.21 우아한 형제들 테크 세미나
강대명 - 유데미 데이터 엔지니어
Redis 소개
왜 Collection이 중요한가
Redis Collection
Redis 운영
Redis 데이터 분산
Redis Failover
Monitoring Factor
결론
다루지 않는 것들
Redis Persistence
Redis Pub/Sub
Redis Stream
확률적 자료구조
Redis Modules
한줄 후기
Redis Intro와 사용법 내용은 압축과 생략으로 과감하게 진행하고, 경험에 의해 쌓인 redis 운영과 관리에 관한 이야기를 중점적으로 들을 수 있어서 매우 흥미로웠습니다.
모든 내용을 담진 못했으므로, 미흡한 부분은 테크 세미나 유튜브 채널에 공개될 영상을 참고하시면 좋을 것 같습니다.
https://www.youtube.com/channel/UC-mOekGSesms0agFntnQang

P.S. 세미나 킬링파트 - 몸으로 이해하는 레디스(PT 30-40장 스킵 스킬, 발표시간 맞추기 스킬)

1. Redis 소개

In-Memory Data Structure Store
오픈소스
Support data structures
- strings, set, sorted-set, hashes, list
Only 1 Committer
파레토 법칙 2:8
- 전체 요청의 80%는 20%의 사용자가 만들어낸다.
캐시구조
- Look aside Cache
  - 캐시에 있으면 리턴, 없으면 캐시에 저장하고 리턴
- Write Back
  - 모든 데이터를 캐시에 저장, 특정 시점에만 캐시 데이터 DB에 저장
  - ex) 로그를 캐시에 쌓아두고, 특정 시점마다 DB로

2. 왜 Collection이 중요한가

개발의 편의성
개발의 난이도
랭킹 서버를 구현한다면?
- 간단한 방법은 DB에 넣고 score로.
- 유저가 많다면?
- Redis Sorted Set을 이용하면 랭킹을 구현할 수 있음.
- 덤으로 Replication도 가능
친구리스트를 key-value 형태로 저장해야 한다면?
- 레디스의 경우 자료구조가 Atomic하기 때문에 Race Condition을 피할 수 있음.
외부의 Collections을 잘 이용하는 것으로 우리가 비즈니스 로직에 집중할 수 있음. 시간 단축, 문제를 줄여줌.
Redis 사용처
- Remote Data Store
  - A, B, C 에서 데이터를 공유하고 싶을때
- 한대에서만 필요하다면, 전역 변수를 쓰면 되지 않을까?
  - Redis 자체가 Atomic을 보장해준다.(싱글 스레드라서)
- 주로 많이 쓰이는 곳들
  - 인증 토큰 등을 저장
  - 랭킹
  - 유저 API limit
  - 좌표

3. Redis Collections

데이터 컬렉션을 잘못 선택해서 속도 차이가 날 수 있음.
Strings
- Key-value
- 사용법은 생략
- Key를 어떻게 잡을 것인가가 중요하다.
  - 키를 어떻게 잡느냐에 따라서 분산이 바뀔 수 있다.
List
- Lpush, Rpush : 시작과 끝이 데이터 추가 가능
- LPOP, RPOP : 마찬가지로 시작과 끝 꺼내기 가능.
Set
- 중복 제거, 순서 없음. find 빠름
- SADD, SMEMBERS, SISMEMBERS
- 특정 유저를 Follow 하는 목록을 저장해 둔다면
Sorted Set
- score를 포함한 순서가 있는 Set
- ZADD <Key> <Score> <Value>
- 범위를 대상으로 데이터 가져올 수 있음
  - zrange
- 유저 랭킹 보드로 사용할 수 있음
- (주의) Sorted set의 score는 double 타입이기 때문에 값이 정확하지 않을 수 있다.
  - score는 실수형이기 때문에 실수하기 쉽다.(?ㅎ)
  - 어떤 특정 정수는 실수에서 표현이 안된다.
  - 컴퓨터에서는 실수가 표현할 수 없는 정수값들이 존재한다.
  - 자바스크립트에서 유저 ID를 보낸다면 Long 정수형으로 보내면 안된다. String으로 보내야 정상적으로 동작한다.
Hash
- Key Value 안에 sub key value가 존재하는 형태
Collection 주의 사항
- 하나의 컬렉션에 너무 많은 아이템을 담으면 좋지 않다.
  - 1만개 이하로 유지하는게 좋음
- Expire는 Collection의 아이템 개별로 걸리지 않고 전체 Collection에 대해서만 걸린다.

4. Redis 운영

메모리 관리를 잘하자

Physical 메모리 이상을 사용하면 문제가 발생한다.
- Swap이 있다면 Swap 사용으로 해당 메모리 Page 접근시 마다 늦어진다.
- Swap 이 한번 발생하면 계속 발생한다. 디스크 사용으로 인해 느려진다.
- Swap이 없다면? OOM으로 죽을 수 있다.
Maxmemory를 설정하더라도 이보다 더 사용할 가능성이 크다.
- 레디스는 메모리 allocator에 의존하는데. jemaloc
- 1바이트만 달라고해도 jemaloc는 페이지 단위에 의해서 메모리를 주므로 4096을 할당한다.
- 메모리 파편화가 일어나면, 레디스 사용량과 jemaloc 할당량이 달라진다.
RSS
많은 업체가 현재 메모리를 사용해서 Swap을 쓰고 있다는 것을 모를때가 많다.
큰 메모리를 사용하는 instance 하나보다는 적은 메모리를 사용하는 instance 여러개가 안전하다.
- 레디스는 Fork를 하게 되는데, read만 하면 상관없지만, write를 하게되면 최대 2배 사용한다.
- 예를 들면 4코어 24기가 한대가 2배 사용하면 48기가 사용하지만,
- 8기가 3대에서 1대가 2배를 사용하게 되면, 32기가만 사용하게 된다.
레디스는 메모리 파편화가 발생할 수 있음. 4.x대 부터...
메모리가 부족할 때는?
- Cache is Cach!!!
  - 좀 더 메모리 많은 장비로 마이그레이션. 시점은 75% 정도
  - 메모리가 빡빡하면 마이그레이션 중에 문제가 발생할 수도
- 아니면, 데이터 줄이기..
메모리를 줄이기 위한 설정
- 기본적으로 Collection 들은 아래와 같은 자료구조 사용
  - Hash -> HashTable 하나 더 사용
  - Sorted Set -> Skiplist 와 HashTable 사용
  - Set -> HashTable 사용
  - 해당 자료구조들은 메모리를 많이 사용함
- ziplist를 사용하자
  - 선형으로 저장한다.
  - 인메모리 특성상 적은 개수라면 선형 탐색을 하더라도 빠르다.
  - List, Hash, Sorted Set을 ziplist로 대체해서 처리하는 설정이 존재한다.
    - 30% 정도까지 적게 사용 가능하다.

O(N) 관련 명령어는 주의하자

레디스는 Sigle Threaded
- 동시에 여러개의 명령을 처리할 수 있을까?
- 참고로 단순한 get/set의 경우 초당 10만 TPS 이상 가능하다(CPU영향 가능)
- 작업 하나가 1초 걸리면? 300ms 타임아웃 설정되어있으면 터진다.
- Pocket으로 하나의 Command가 완성되면 processCommand로 처리함
- 한번에 하나의 명령을 처리하므로 오래걸리는 명령을 수행하면 안된다.
- 대표적인 O(N) 명령들
  - KEYS
  - FLUSHALL, FLUSHDB
  - Delete Collections
  - Get All Collections
대표적인 실수 사례
- Key가 백만개 이상인데 확인을 위해 KEYS 명령을 사용하는 경우
  - 모니터링 스크립트가 1초에 한번씩 호출
- 아이템이 몇만개든 hash, sorted set, set에서 데이터를 가져오는 경우
- Spring security oath RedisTokenStore 이슈
KEYS는 어떻게 대체할 것인가?
- Scan 명령을 사용하는 것으로 하나의 긴 명령을 짧은 여러번의 명령으로 바꿀 수 있다.(cursor 방식)
- 짧은 명령들 사이에 read 몇만개가 처리될 수 있다.
Collection의 모든 아이템을 가져와야 할 때?
- Collection의 일부만 가져오거나
- 큰 Collections을 여러개의 Collection으로 나눠서 저장
Spring security oath RedisTokenStore 이슈
- Access Token의 저장을 List 자료구조를 통해서 이루어졌었음
- 검색, 삭제시에 모든 item을 매번 찾아야함
- 최신 버전에서는 Set(O(1))로 해결 함.

Replication

Async Replication
- Replication lag이 발생할 수 있다.
- 리플리케이션 하는 틈 사이에 데이터가 바뀔 수 있다.
'Replicaof'(5.0.0 버전 이상) 명령으로 설정 가능
- Replicaof hostname port
DBMS로 보면 statement replication과 유사
- DB에서 now는 1, 2가 다를 수 있음.
Replication 설정 과정
- Replicaof 명령 전달
- Secondary는 Primary에 sync 명령 전달
- Primary는 현재 메모리 상태 저장하기 위해 Fork
- ... 생략
주의할 점
- Replication 과정에서 Fork가 발생하므로 메모리 부족이 발생할 수 있다.
- Redis-cli --rdb 명령은 현재 상태의 메모리 스냅샷을 가져오므로 문제를 발생시킴. 치명적
- AWS나 클라우드의 Redis는 좀 다르게 구현되어서 해당 부분이 안정적
- 많은 대수의 Redis 서버가 많은 Replica를 두고 있다면?
- 네트웍 이슈나, 사람의 작업으로 동시에 replication이 재시도 되도록 하면 문제가 발생할 수 있다.
권장 설정 Tip
- Maxclient 설정 50000
- RDB/AOF 설정 off
  - 마스터에서는 무조건 off
- 특정 commands disable
  - Keys
  - AWS의 ElasticCache는 이미 하고 있음
- 전체 장애의 99%는 KEYS나 SAVE설정을 사용해서 발생
  - SAVE 주의.
- 적절한 ziplist 설정

5. Redis 데이터 분산

데이터의 특성에 따라서 선택할 수 있는 방법이 달라진다.
Consistent Hashing
- 서버가 추가되거나 빠지더라도 해당 서버에 있는 데이터들만 리밸런싱이 일어남.
- 1,2,3 번 서버중에 2번 죽으면 2번에 있는 데이터들만 이동.
Sharding
- 데이터를 어떻게 나눌것인가? 는 데이터를 어떻게 찾을것인가? 와 같다.
- 하나의 데이터를 모든 서버에서 찾아야 하면?
- Range
  - 특정 Range를 정의 하고 해당 Range에 속하면 거기에 저장.
  - 불균형이 생긴다. 이벤트 처리 할때 많이 발생한다.
  - 확장은 편한데, 서버 상황에 따라서 놀고 있는 서버와 열일하는 서버가 나뉜다.
- Modular
  - 서버 한대 추가할 때 재분배 양이 많아 진다.
- Indexed
  - 해당 Key가 어디에 저장되어야 할 관리 서버가 따로 존재.
  - 단일 장애 포인트 문제 존재.
Redis Cluster
- Hash 기반으로 slot 16384로 구분
  - Hash 알고리즘은 CRC16을 사용
  - 특정 Redis 서버는 이 slot range를 가지고 있고, 데이터 마이그레이션은 이 slot 단위의 데이터를 다른 서버로 전달하게 된다.(migrateCommand 사용)
- 장점
  - 자체적인 Failover 기능
  - slot 단위의 데이터 관리
- 단점
  - 메모리 사용량이 더 많다
  - 마이그레이션 자체는 관리자가 시점 결정해야 함
  - 라이브러리 구현이 필요함.

6. Redis Failover

Coordinator 기반
- Zookeeper, etcd, consul 등의 Coordinator 사용
- Health checker
- Coordinator가 API서버에 Primary notify 해줌
- 해당 기능을 이용하도록 개발이 필요하다.
VIP 기반
- API 서버는 가상 IP 10.0.0.1로만 접속하고
- Health checker는 10.0.0.1 할당 받은 1번 서버 레디스가 죽으면 10.0.0.1을 redis 2번 서버에 할당
DNS 기반
- VIP 기반 방식과 같음.
VIP/DNS 특징
- 클라이언트에 추가적인 구현이 필요없다.
- VIP 기반은 외부로 서비스를 제공해야 하는 서비스 업자에 유리
- DNS 기반은 DNS cache 를 관리해야함

7. Monitor Factor

Redis Info를 통한 정보
- RSS
- Used Memory
- Connection 수
- 초당 처리 요청 수
System
- CPU
- Disk
- Network rx/tx
CPU 100%를 칠 경우
- 처리량이 매우 많다면?
  - CPU 성능 좋은 서버로 이전
  - 실제 CPU 성능에 영향을 받음
    - 그러나 단순 get/set은 초당 10만 이상 처리 가능
- O(N) 계열의 특정 명령이 많은 경우
  - Monitor 명령을 통해 특정 패턴을 파악하는 것이 필요
  - Monitor 잘못쓰면 부하로 해당 서버에 더 큰 문제를 일이킬 수도 있음(짧게 쓰는게 중요함)

8. 결론

레디스는 기본적으로 매우 좋은 툴이다
그러나 메모리를 빡빡하게 쓸 경우 관리가 어렵다.
- 32기가 장비면 24기가 이상 사용하면 장비 증설을 고려하는 것이 좋음
- Write가 Heavy할 경우 마이그레이션도 주의해야 함.
레디스를 Cache로 쓰는 경우 - 문제가 적게 발생
- 레디스가 문제가 있을 때 DB등의 부하가 어느정도 증가하는지 확인 필요함
- Consistent Hashing도 부하를 아주 균등하게 나누지는 않음
레디스를 Persistent Store로 쓰는 경우
- 무조건 Primary/Secondary 구조로 구성이 필요함
- 메모리를 절대로 빡빡하게 사용하면 안됨
  - 정기적인 마이그레이션 필요
  - 가능하면 자동화 툴 만들어 사용
- RDB/AOF가 필요하다면 Secondary에서만 구동

[JPA] 즉시 로딩과 지연 로딩(FetchType.LAZY or EAGER)

nroo — Mon, 9 Sep 2019 17:34:38 +0900

즉시 로딩과 지연 로딩

프록시 학습 처음에 했던 질문. Member를 조회할 때 Team도 함께 조회 해야 할까?
- 비즈니스 로직에서 단순히 멤버 로직만 사용하는데 함께 조회하면, 아무리 연관관계가 걸려있다고 해도 손해이다.
JPA는 이 문제를 지연로딩 LAZY를 사용해서 프록시로 조회하는 방법으로 해결 한다.

코드로 이해하기

Member와 Team 사이가 다대일 @ManyToOne 관계로 매핑되어 있는 상황에서,
@ManyToOne 어노테이션에 fetch 타입을 줄 수 있다.

FetchType.LAZY

@Entity
@Getter
@Setter
public class Member extends BaseEntity {

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

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

    private Integer age;

    @Enumerated(EnumType.STRING)
    private RoleType roleType;

    @Lob
    private String description;

    // 패치 타입 LAZY 설정
    @ManyToOne(fetch = FetchType.LAZY)
    @JoinColumn(name = "team_id", insertable = false, updatable = false)
    private Team team;

    @OneToOne
    @JoinColumn(name = "locker_id")
    private Locker locker;

    @OneToMany(mappedBy = "member")
    private List<MemberProduct> memberProducts = new ArrayList<>();

    public void changeTeam(Team team) {
        this.team = team;
        this.team.getMembers().add(this);
    }
}

메인 함수에서 팀과 멤버를 저장하고 조회 해보자.

Member를 조회하고, Team 객체의 클래스를 확인해보면 Proxy 객체가 조회 된다.

Team team = new Team();
team.setName("teamA");
em.persist(team);

Member member = new Member();
member.setUsername("memberA");
em.persist(member);

member.changeTeam(team);

em.flush();
em.clear();

Member findMember = em.find(Member.class, member.getId());

System.out.println(findMember.getTeam().getClass());

Hibernate: 
    select
        member0_.id as id1_4_0_,
        member0_.createdBy as createdB2_4_0_,
        member0_.createdDate as createdD3_4_0_,
        member0_.lastModifiedBy as lastModi4_4_0_,
        member0_.lastModifiedDate as lastModi5_4_0_,
        member0_.age as age6_4_0_,
        member0_.description as descript7_4_0_,
        member0_.locker_id as locker_10_4_0_,
        member0_.roleType as roleType8_4_0_,
        member0_.team_id as team_id11_4_0_,
        member0_.name as name9_4_0_,
        locker1_.id as id1_3_1_,
        locker1_.name as name2_3_1_ 
    from
        Member member0_ 
    left outer join
        Locker locker1_ 
            on member0_.locker_id=locker1_.id 
    where
        member0_.id=?
        
class hello.jpa.Team$HibernateProxy$e97rdqZR  // 프록시 객체

팀의 이름을 출력해보자

이 시점에. 실제로 팀 객체의 조회가 필요한 시점에 쿼리가 나간다.

Team team = new Team();
team.setName("teamA");
em.persist(team);

Member member = new Member();
member.setUsername("memberA");
em.persist(member);

member.changeTeam(team);

em.flush();
em.clear();

Member findMember = em.find(Member.class, member.getId());

System.out.println(findMember.getTeam().getClass());
System.out.println("TEAM NAME : " + findMember.getTeam().getName());

Hibernate: 
    select
        member0_.id as id1_4_0_,
        member0_.createdBy as createdB2_4_0_,
        member0_.createdDate as createdD3_4_0_,
        member0_.lastModifiedBy as lastModi4_4_0_,
        member0_.lastModifiedDate as lastModi5_4_0_,
        member0_.age as age6_4_0_,
        member0_.description as descript7_4_0_,
        member0_.locker_id as locker_10_4_0_,
        member0_.roleType as roleType8_4_0_,
        member0_.team_id as team_id11_4_0_,
        member0_.name as name9_4_0_,
        locker1_.id as id1_3_1_,
        locker1_.name as name2_3_1_ 
    from
        Member member0_ 
    left outer join
        Locker locker1_ 
            on member0_.locker_id=locker1_.id 
    where
        member0_.id=?
        
class hello.jpa.Team$HibernateProxy$z4JtUeLD  // 프록시 객체

Hibernate: 
    select
        team0_.id as id1_8_0_,
        team0_.createdBy as createdB2_8_0_,
        team0_.createdDate as createdD3_8_0_,
        team0_.lastModifiedBy as lastModi4_8_0_,
        team0_.lastModifiedDate as lastModi5_8_0_,
        team0_.name as name6_8_0_ 
    from
        Team team0_ 
    where
        team0_.id=?
        
TEAM NAME : teamA

지연 로딩(LAZY)

내부 매커니즘은 위의 그림과 같다.
로딩되는 시점에 Lazy 로딩 설정이 되어있는 Team 엔티티는 프록시 객체로 가져온다.
후에 실제 객체를 사용하는 시점에(Team을 사용하는 시점에) 초기화가 된다. DB에 쿼리가 나간다.
- getTeam()으로 Team을 조회하면 프록시 객체가 조회가 된다.
- getTeam().getXXX()으로 팀의 필드에 접근 할 때, 쿼리가 나간다.

대부분 비즈니스 로직에서 Member와 Team을 같이 사용한다면?

이런 경우 LAZY 로딩을 사용한다면, SELECT 쿼리가 따로따로 2번 나간다.
네트워크를 2번 타서 조회가 이루어 진다는 이야기이다. 손해다.
이때는 즉시 로딩(EAGER) 전략을 사용해서 함께 조회하면 된다.

즉시 로딩(EAGER)

fetch 타입을 EAGER로 설정하면 된다.
대부분의 JPA 구현체는 가능하면 조인을 사용해서 SQL 한번에 함께 조회하려고 한다.
이렇게 하면, 실제 조회할 때 한방 쿼리로 다 조회해온다.(실제 Team을 사용할 때 쿼리 안나가도 된다.)

실행 결과를 보면 Team 객체도 프록시 객체가 아니라 실제 객체이다.

@Entity
@Getter
@Setter
public class Member extends BaseEntity {

    ...

    @ManyToOne(fetch = FetchType.EAGER)
    @JoinColumn(name = "team_id", insertable = false, updatable = false)
    private Team team;

    ...
}

Team team = new Team();
team.setName("teamA");
em.persist(team);

Member member = new Member();
member.setUsername("memberA");
em.persist(member);

member.changeTeam(team);

em.flush();
em.clear();

Member findMember = em.find(Member.class, member.getId());

System.out.println(findMember.getTeam().getClass());
System.out.println("TEAM NAME : " + findMember.getTeam().getName());
tx.commit();

실행 결과

Hibernate: 
    select
        member0_.id as id1_4_0_,
        member0_.createdBy as createdB2_4_0_,
        member0_.createdDate as createdD3_4_0_,
        member0_.lastModifiedBy as lastModi4_4_0_,
        member0_.lastModifiedDate as lastModi5_4_0_,
        member0_.age as age6_4_0_,
        member0_.description as descript7_4_0_,
        member0_.locker_id as locker_10_4_0_,
        member0_.roleType as roleType8_4_0_,
        member0_.team_id as team_id11_4_0_,
        member0_.name as name9_4_0_,
        locker1_.id as id1_3_1_,
        locker1_.name as name2_3_1_,
        team2_.id as id1_8_2_,
        team2_.createdBy as createdB2_8_2_,
        team2_.createdDate as createdD3_8_2_,
        team2_.lastModifiedBy as lastModi4_8_2_,
        team2_.lastModifiedDate as lastModi5_8_2_,
        team2_.name as name6_8_2_ 
    from
        Member member0_ 
    left outer join
        Locker locker1_ 
            on member0_.locker_id=locker1_.id 
    left outer join
        Team team2_ 
            on member0_.team_id=team2_.id 
    where
        member0_.id=?
        
class hello.jpa.Team

TEAM NAME : teamA

프록시와 즉시 로딩 주의할 점

실무에서는 가급적 지연 로딩만 사용하다. 즉시 로딩 쓰지 말자.
- JPA 구현체도 한번에 가저오려고 하고, 한번에 가져와서 쓰면 좋지 않나?
즉시 로딩을 적용하면 예상하지 못한 SQL이 발생한다.
- @ManyToOne이 5개 있는데 전부 EAGER로 설정되어 있다고 생각해보자.
- 조인이 5개 일어난다. 실무에선 테이블이 더 많다.

즉시 로딩은 JPQL에서 N+1 문제를 일으킨다.

실무에서 복잡한 쿼리를 많이 풀어내기 위해서 뒤에서 학습할 JPQL을 많이 사용한다.
em.find()는 PK를 정해놓고 DB에서 가져오기 때문에 JPA 내부에서 최적화를 할 수 있다.(한방 쿼리)
하지만, JPQL에선 입력 받은 query string이 그대로 SQL로 변환된다.
- "select m from Member m" 이 문장으로 당연히 Member만 SELECT 하게 된다.
- MEMBER를 쭉 다 가져와서 보니까
어 근데, Member 엔티티의 Team의 fetchType이 EAGER네?
- LAZY면 프록시를 넣으면 되겠지만, EAGER는 반환하는 시점에 다 조회가 되어 있어야 한다.
- 따라서, Member를 다 가져오고 나서, 그 Member와 연관된 Team을 다시 다 가져온다.

코드로 이해하기

멤버가 2명이고, 팀도 2개다. 각각 다른 팀이다.

모든 멤버를 조회해보자.

Team team1 = new Team();
team1.setName("teamA");
em.persist(team1);

Team team2 = new Team();
team2.setName("teamB");
em.persist(team2);

Member member1 = new Member();
member1.setUsername("memberA");
em.persist(member1);
member1.changeTeam(team1);

Member member2 = new Member();
member2.setUsername("memberB");
em.persist(member2);
member2.changeTeam(team2);

em.flush();
em.clear();

List<Member> members = em
                .createQuery("select m from Member m", Member.class)
  .getResultList();

tx.commit();

실행 결과를 보면,
일단 멤버를 조회해서 가져온다.
그리고 나서 Member들의 Team이 비어있으니까 채워서 반환시키기 위해서 TEAM을 각각 쿼리 날려서 가져온다.
멤버가 수천 수만명이라고 생각하면...... 아찔해진다.

N + 1의 문제의 의미는

아래 처럼 쿼리를 1개 날렸는데, 그것 때문에 추가 쿼리가 N개 나간다는 의미이다.

Hibernate: 
    /* select
        m 
    from
        Member m */ select
            member0_.id as id1_4_,
            member0_.createdBy as createdB2_4_,
            member0_.createdDate as createdD3_4_,
            member0_.lastModifiedBy as lastModi4_4_,
            member0_.lastModifiedDate as lastModi5_4_,
            member0_.age as age6_4_,
            member0_.description as descript7_4_,
            member0_.locker_id as locker_10_4_,
            member0_.roleType as roleType8_4_,
            member0_.team_id as team_id11_4_,
            member0_.name as name9_4_ 
        from
            Member member0_
Hibernate: 
    select
        team0_.id as id1_8_0_,
        team0_.createdBy as createdB2_8_0_,
        team0_.createdDate as createdD3_8_0_,
        team0_.lastModifiedBy as lastModi4_8_0_,
        team0_.lastModifiedDate as lastModi5_8_0_,
        team0_.name as name6_8_0_ 
    from
        Team team0_ 
    where
        team0_.id=?
Hibernate: 
    select
        team0_.id as id1_8_0_,
        team0_.createdBy as createdB2_8_0_,
        team0_.createdDate as createdD3_8_0_,
        team0_.lastModifiedBy as lastModi4_8_0_,
        team0_.lastModifiedDate as lastModi5_8_0_,
        team0_.name as name6_8_0_ 
    from
        Team team0_ 
    where
        team0_.id=?

결론. 실무에서는 LAZY 로딩 전략을 가져가자.
- 근데 실무에서 대부분 멤버 팀을 함께 사용하는 경우가 있는데, 그러면 LAZY로 해놓고 계속 쿼리 두방 날려서 조회 해올까요?
- 이런 경우를 위해서 JPQL의 fetch join 을 통해서 해당 시점에 한방 쿼리로 가져와서 쓸 수 있다.
- 추가적으로 엔티티그래프와 어노테이션으로 푸는 방법, 배치 사이즈 설정으로 해결하는 방법이 있다.
- 대부분 fetch join으로 해결 한다.

@ManyToOne, @OneToOne과 같이 @XXXToOne 어노테이션들은 기본이 즉시 로딩(EAGER) 이다.
- 꼭 LAZY로 명시적으로 설정해서 사용하자
@OneToMany와 @ManyToMany는 기본이 지연 로딩(LAZY)이다.

지연 로딩 활용

Member와 Team을 자주 함께 사용한다 -> 즉시 로딩
Member와 Order는 가끔 사용한다 -> 지연 로딩
Order와 Product는 자주 함꼐 사용한다 -> 즉시 로딩
위와 같이 설정해 놓고 쓸 수 있지만, 굉장히 이론적인 개념이고
실무에서는 다 LAZY로 쓰자. 즉시 로딩 사용하지 말자.
JPQL fetch join이나, 엔티티 그래프 기능으로 해결하자.
즉시 로딩은 상상하지 못한 쿼리가 나간다.

Reference

자바 ORM 표준 JPA 프로그래밍

[JPA] 프록시란?

nroo — Mon, 9 Sep 2019 17:27:18 +0900

프록시

질문으로 부터 프록시에 대한 학습을 시작한다.
Member 엔티티를 조회할 때 Team도 함께 조회해야 할까?
- 실제로 필요한 비즈니스 로직에 따라 다르다.
- 비즈니스 로직에서 필요하지 않을 때가 있는데, 항상 Team을 함께 가져와서 사용할 필요는 없다.
- 낭비가 발생하게 된다.
- JPA는 이 낭비를 하지 않기 위해, 지연로딩과 프록시라는 개념으로 해결한다.

프록시 기초

지연 로딩을 이해하려면, 프록시의 개념에 대해서 명확하게 이해해야 한다.
JPA에서 em.find() 말고, em.getReference()라는 메서드도 제공 된다.
em.find() 는 DB를 통해서 실제 엔티티 객체를 조회하는 메서드이고
em.getReference() 는 DB의 조회를 미루는 가짜(프록시) 엔티티 객체를 조회하는 메서드이다.

Member 엔티티

@Entity
@Getter
@Setter
public class Member extends BaseEntity {

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

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

    private Integer age;

    @Enumerated(EnumType.STRING)
    private RoleType roleType;

    @Lob
    private String description;

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

    @OneToOne
    @JoinColumn(name = "locker_id")
    private Locker locker;

    @OneToMany(mappedBy = "member")
    private List<MemberProduct> memberProducts = new ArrayList<>();
}

em.find()로 멤버를 조회하면 아래와 같이 데이터베이스에 쿼리가 바로 나간다.

Member member = new Member();
member.setCreatedBy("creator");

em.persist(member);

em.flush();
em.clear();

Member findMember = em.find(Member.class, member.getId());
System.out.println("findMember.id = " + findMember.getId());
System.out.println("findMember.username = " + findMember.getUsername());

tx.commit();

Hibernate: 
    /* insert hello.jpa.Member
        */ insert 
        into
            Member
            (id, createdBy, createdDate, lastModifiedBy, lastModifiedDate, age, description, locker_id, roleType, name) 
        values
            (null, ?, ?, ?, ?, ?, ?, ?, ?, ?)
Hibernate: 
    select
        member0_.id as id1_4_0_,
        member0_.createdBy as createdB2_4_0_,
        member0_.createdDate as createdD3_4_0_,
        member0_.lastModifiedBy as lastModi4_4_0_,
        member0_.lastModifiedDate as lastModi5_4_0_,
        member0_.age as age6_4_0_,
        member0_.description as descript7_4_0_,
        member0_.locker_id as locker_10_4_0_,
        member0_.roleType as roleType8_4_0_,
        member0_.team_id as team_id11_4_0_,
        member0_.name as name9_4_0_,
        locker1_.id as id1_3_1_,
        locker1_.name as name2_3_1_,
        team2_.id as id1_8_2_,
        team2_.createdBy as createdB2_8_2_,
        team2_.createdDate as createdD3_8_2_,
        team2_.lastModifiedBy as lastModi4_8_2_,
        team2_.lastModifiedDate as lastModi5_8_2_,
        team2_.name as name6_8_2_ 
    from
        Member member0_ 
    left outer join
        Locker locker1_ 
            on member0_.locker_id=locker1_.id 
    left outer join
        Team team2_ 
            on member0_.team_id=team2_.id 
    where
        member0_.id=?
findMember.id = 1
findMember.username = creator

그러나, em.getReference()로 멤버를 조회하면, 실제로 필요한 시점에 데이터베이스에 쿼리가 나간다.

실행결과에서 보면 findMember.username 필드를 출력할 때, DB에서 조회가 필요하므로 그때 쿼리가 나간다.
그리고 findMember.getClass()로 객체를 확인하면 Member객체가 아니라, 하이버네이트가 강제로 만든 가짜 클래스인 HibernateProxy 객체인 것을 볼 수 있다.

Member member = new Member();
member.setUsername("creator");

em.persist(member);

em.flush();
em.clear();

Member findMember = em.getReference(Member.class, member.getId());
System.out.println("findMember = " + findMember.getClass());
System.out.println("findMember.id = " + findMember.getId());
System.out.println("findMember.username = " + findMember.getUsername());

tx.commit();

Hibernate: 
    /* insert hello.jpa.Member
        */ insert 
        into
            Member
            (id, createdBy, createdDate, lastModifiedBy, lastModifiedDate, age, description, locker_id, roleType, name) 
        values
            (null, ?, ?, ?, ?, ?, ?, ?, ?, ?)
findMember = class hello.jpa.Member$HibernateProxy$yJgMgbkR
findMember.id = 1
Hibernate: 
    select
        member0_.id as id1_4_0_,
        member0_.createdBy as createdB2_4_0_,
        member0_.createdDate as createdD3_4_0_,
        member0_.lastModifiedBy as lastModi4_4_0_,
        member0_.lastModifiedDate as lastModi5_4_0_,
        member0_.age as age6_4_0_,
        member0_.description as descript7_4_0_,
        member0_.locker_id as locker_10_4_0_,
        member0_.roleType as roleType8_4_0_,
        member0_.team_id as team_id11_4_0_,
        member0_.name as name9_4_0_,
        locker1_.id as id1_3_1_,
        locker1_.name as name2_3_1_,
        team2_.id as id1_8_2_,
        team2_.createdBy as createdB2_8_2_,
        team2_.createdDate as createdD3_8_2_,
        team2_.lastModifiedBy as lastModi4_8_2_,
        team2_.lastModifiedDate as lastModi5_8_2_,
        team2_.name as name6_8_2_ 
    from
        Member member0_ 
    left outer join
        Locker locker1_ 
            on member0_.locker_id=locker1_.id 
    left outer join
        Team team2_ 
            on member0_.team_id=team2_.id 
    where
        member0_.id=?
findMember.username = creator

프록시 특징

실제 클래스를 상속 받아서 만들어진다.
- 하이버네이트가 내부적으로 상속받아서 만든다.
실제 클래스와 겉 모양이 같다.
사용하는 입장에서는 진짜 객체인지 프록시 객체인지 구분하지 않고 사용하면 된다.

프록시 객체는 실제 객체의 참조(target)을 보관한다.
프록시 객체를 호출하면 프록시 객체는 실제 객체의 메소드를 호출한다.

프록시 객체의 초기화

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

em.getReference()로 프록시 객체를 가져온 다음에, getName() 메서드를 호출 하면
MemberProxy 객체에 처음에 target 값이 존재하지 않는다. JPA가 영속성 컨텍스트에 초기화 요청을 한다.
영속성 컨텍스트가 DB에서 조회해서
실제 Entity를 생성해준다.
그리고 프록시 객체가 가지고 있는 target(실제 Member)의 getName()을 호출해서 결국 member.getName()을 호출한 결과를 받을 수 있다.
프록시 객체에 target이 할당 되고 나면, 더이상 프록시 객체의 초기화 동작은 없어도 된다.

실제로는 위와 같이 프록시 객체가 동작 한 것이다.

프록시 특징 정리

프록시 객체는 처음 사용할 때 한 번만 초기화 된다.
프록시 객체를 초기화 할 때, 프록시 객체가 실제로 엔티티로 바뀌는 것은 아니다.
- 초기화 되면 프록시 객체를 통해서 실제 엔티티에 접근 가능하다.
- 정확히 말하면 target에 값이 채워지는 것 뿐이다.
- em.getReference()로 조회한 클래스를 getClass()로 보면, HibernateProxy 클래스였던 것을 위에서 학습했다.

(심화)프록시 객체는 원본 엔티티를 상속 받는다고 했다. 프록시 객체와 원본 객체가 타입이 다르다. 타입 체크시 주의해야 한다.

== 비교 실패한다. jpa에서 타입 비교는 웬만하면, instanceOf를 사용해야 한다.

Member find = em.find(Member.class, member1.getId());
Member reference = em.getReference(Member.class, member2.getId());
System.out.println("m1 == m2 : " + (m1 == m2));

find == reference : false

System.out.println("find : " + (find instanceof Member));
System.out.println("reference : " + (reference instanceof Member));

find : true
reference : true

(심화)영속성 컨텍스트에 찾는 엔티티가 이미 있으면, em.getReference()를 호출해도 실제 엔티티를 반환한다. 반대도 똑같다.
- 생각을 해보면, 이미 영속성 컨텍스트에 올려논 객체를 굳이 다시 프록시로 감싸서 반환하는게 의미가 없다. 이점이 없다. JPA는 그렇게 하지 않는다.
- JPA는 하나의 영속성 컨텍스트에서 조회하는 같은 엔티티의 동일성을 보장한다.
  - JPA가 기본적으로 제공하는 매커니즘 중 하나이다. 반복가능한 읽기(repeatable read) 제공
- 따라서, 아래의 코드에서 두 객체는 같다. em.gerReference()로 프록시 객체를 굳이 가져오지 않는다.
```
Member find = em.find(Member.class, member.getId());
Member reference = em.getReference(Member.class, member.getId());

System.out.println("find == reference : " + (find == reference)); // true
```
- (더 심화) 그렇다면 둘다 getReference() 로 가져오면?!
  - 둘 다, 프록시 객체이다. 근데, 같은 프록시 객체다. JPA는 한 트랜잭션에서 조회하는 같은 엔티티의 동일성을 보장한다. 프록시 객체도.
```
Member reference1 = em.getReference(Member.class, member.getId());
Member reference2 = em.getReference(Member.class, member.getId());

System.out.println("reference1 == reference2 : " + (reference1 == reference2)); // true
```
  - 그러면, getReference()로 먼저 가져오고, find()로 실제 객체를 조회하면?
    - 하나는 프록시 객체, 하나는 당연히 find니까 실제 객체이지 않을까?
    - 결론 부터 말하면 둘 다 같은 프록시 객체를 반환한다.
    - 한 트랜잭션에서 조회하는 같은 엔티티의 동일성을 보장 하기 위해서.
    - 한 트랜잭션 내에서 reference == find를 true로 반환하기 위해서 이렇게 동작한다.
    - 여기서 가장 중요한 것은, 이렇게 내부적으로 JPA가 복잡하게 다 처리해주지만, 우리가 개발할때는 프록시던 진짜 객체던 중요하지 않다. 그냥 멤버 조회 하면서 개발 하면 된다.
```
Member reference = em.getReference(Member.class, member.getId());
Member find = em.find(Member.class, member.getId());

System.out.println("reference == find : " + (reference == find)); // true
```

실무에서 많이 만나게 되는 문제

영속성 컨텍스트의 도움을 받을 수 없는 준영속 상태일 때, 초기화 문제가 발생한다.
즉, 트랜잭션의 범위 밖에서 프록시 객체를 조회하려고 할 때!

하이버네이트는 org.hibernate.LazyInitializationException 예외를 터트린다.

이를 해결하기 위해서 Spring Boot에서는 open-in-view 설정을 true로 가져간다.
영속성 컨텍스트(하이버네이트 세션)를 뷰 렌더링하는 시점까지 유지시키는 방법인데,
open-session-in-view와 관련해서는 추가로 학습하자.(블로그 url만 봐도 알만한 분들의 좋은 글로 대신...)

em.detach(), em.close(), em.clear() 모두 똑같은 예외가 발생한다.

프록시 객체를 초기화 할 수 없다. 더이상 영속성 컨텍스트의 도움을 받지 못한다.

Member member = new Member();
member.setUsername("creator");

em.persist(member);

em.flush();
em.clear();

Member reference = em.getReference(Member.class, member.getId());

em.detach(reference);
//em.close도 동일

System.out.println("findMember.username = " + reference.getUsername());

tx.commit();

org.hibernate.LazyInitializationException: could not initialize proxy [hello.jpa.Member#1] - no Session
  at org.hibernate.proxy.AbstractLazyInitializer.initialize(AbstractLazyInitializer.java:169)
  at org.hibernate.proxy.AbstractLazyInitializer.getImplementation(AbstractLazyInitializer.java:309)
  at org.hibernate.proxy.pojo.bytebuddy.ByteBuddyInterceptor.intercept(ByteBuddyInterceptor.java:45)
  at org.hibernate.proxy.ProxyConfiguration$InterceptorDispatcher.intercept(ProxyConfiguration.java:95)
  at hello.jpa.Member$HibernateProxy$bCLaGKb1.getUsername(Unknown Source)
  at JpaMain.main(JpaMain.java:35)

프록시 관련 Utils

프록시 확인을 도와주는 Util성 메소드들이 있다.

프록시 인스턴스의 초기화 여부를 직접 확인

PersistenceUnitUtil.isLoaded(Object entity);

// 엔티티 매니저 팩토리로 부터 get
boolean isLoaded = emf.getPersistenceUnitUtil().isLoaded(referenceMember);

프록시 클래스 확인 방법
- entity.getClass().getName() 출력 (..javasist.. or HibernateProxy...)
프록시 강제 초기화
- org.hibernate.Hibernate.initialize(entity);
```
Hibernate.initialize(referenceMamber);
```
참고로

JPA 표준은 강제 초기화 메서드(initialize)가 없다. Hibernate가 지원한다.
그냥 프록시 객체에서 getXXX() 호출해서 강제로 초기화 한다.

Reference

자바 ORM 표준 JPA 프로그래밍

[JPA] 영속성 컨텍스트와 플러시 이해하기

nroo — Tue, 27 Aug 2019 18:47:32 +0900

영속성 컨텍스트

JPA를 공부할 때 가장 중요한게

객체와 관계형 데이터베이스를 매핑하는 것(Object Relational Mapping) 과

영속성 컨텍스트를 이해하는 것 이다.

두가지 개념은 꼭 알고 JPA를 활용하자.

엔티티 매니저 팩토리와 엔티티 매니저

JPA는 스레드가 하나 생성될 때 마다(매 요청마다) EntityManagerFactory에서 EntityManager를 생성한다.
EntityManager는 내부적으로 DB 커넥션 풀을 사용해서 DB에 붙는다.

영속성 컨텍스트

영속성 컨텍스트는 JPA를 이해하는데 가장 중요한 용어이다.
"엔티티를 영구 저장하는 환경"이라는 뜻
EntityManager.persist(entity);
- 앞의 예제에서 persist()로 db에 객체를 저장하는 것이라고 배웠지만,
- 실제로는 DB에 저장하는 것이 아니라, 영속성 컨텍스트를 통해서 엔티티를 영속화 한다는 뜻이다.
- 정확히 말하면 persist() 시점에는 영속성 컨텍스트에 저장한다. DB 저장은 이후이다.
엔티티 매니저? 영속성 컨텍스트?
- 영속성 컨텍스트는 논리적인 개념이다.
- 눈에 보이지 않는다.
- 엔티티 매니저를 통해서 영속성 컨텍스트에 접근한다.

스프링에서 EntityManager를 주입 받아서 쓰면, 같은 트랜잭션의 범위에 있는 EntityManager는 동일 영속성 컨텍스트에 접근한다.

엔티티의 생명주기

비영속(new/transient)

영속성 컨텍스트와 전혀 관계가 없는 상태

// 객체를 생성만 한 상태(비영속)
Member member = new Member();
member.setId("member1");
member.setUsername("회원1");

영속(managed)
- 영속성 컨텍스트에 저장된 상태
- 엔티티가 영속성 컨텍스트에 의해 관리된다.
- 이때 DB에 저장 되지 않는다. 영속 상태가 된다고 DB에 쿼리가 날라가지 않는다.
- 트랜잭션의 커밋 시점에 영속성 컨텍스트에 있는 정보들이 DB에 쿼리로 날라간다.
```
// 객체를 생성한 상태(비영속)
Member member = new Member();
member.setId("member1");
member.setUsername("회원1");

EntityManager em = emf.createEntityManager();
em.getTransaction().begin();

// 객체를 저장한 상태(영속)
em.persist(member);
```

준영속(detached)

영속성 컨텍스트에 저장되었다가 분리된 상태

// 회원 엔티티를 영속성 컨텍스트에서 분리, 준영속 상태
em.detach(member);

삭제(removed)

삭제된 상태. DB에서도 날린다.

// 객체를 삭제한 상태
em.remove(member);

영속성 컨텍스트의 이점

애플리케이션과 DB사이에 왜 중간에 영속성 컨텍스트가 있냐. 왜 필요하냐. 아래와 같은 개념들이 가능하려면, 영속성 컨텍스트가 존재해야 한다.

1차 캐시

영속성 컨텍스트(엔티티 매니저)에는 내부에 1차 캐시가 존재한다.
엔티티를 영속성 컨텍스트에 저장하는 순간. 1차 캐시에
key : @Id로 선언한 필드 값, value : 해당 엔티티 자체로 캐시에 저장된다.
1차 캐시가 있으면 어떤 이점이있을까? 조회할 때 이점이 생긴다.
find()가 일어나는 순간, 엔티티 매니저 내부의 1차 캐시를 먼저 찾는다.
1차 캐시에 엔티티가 존재하면 바로 반환한다. DB 들리지 않는다.
주의! 1차 캐시는 글로벌하지 않다. 해당 스레드 하나가 시작할때 부터 끝날때 까지 잠깐 쓰는거다. 공유하지 않는 캐시다
- 100명 한테 요청 100개 오면, 엔티티 매니저 100개 생기고 1차캐시도 100개 생긴다. 스레드 종료되면, 그때 다 사라진다.
- 트랜잭션의 범위 안에서만 사용하는 굉장히 짧은 캐시 레이어이다.
- 전체에서 쓰는 글로벌 캐시는 2차 캐시라고 한다.
```
Member member = new Member();
member.setId("member1");
member.setUsername("회원1");

...

// 1차 캐시에 저장됨
em.persist(member);

// 1차 캐시에서 조회
Member findMember = em.find(Member.class, "Member1");
```
1차 캐시에 데이터가 없다면? 데이터베이스에서 조회 한다.
- member2를 조회하는데 1차 캐시에 해당 엔티티가 없다.
- 그러면 DB에서 꺼내온다.
- 그리고 1차 캐시에 저장한다.
- 그 후에 member2를 반환한다.
- 다시 member2를 조회하면, 1차 캐시에 있는 member2가 반환된다.
  - SELECT 쿼리가 안나간다. 한 트랜잭션 내에서.

동일성(identity) 보장

영속 엔티티의 동일성을 보장한다.
1차 캐시 덕분에 member1을 두번 조회해도 다를 객체가 아니다. 같은 레퍼런스가 된다.
1차 캐시로 반복 가능한 읽기(REPEATABLE READ) 등급의 트랜잭션 격리 수준을 데이터베이스가 아닌 애플리케이션 차원에서 제공한다.
```
Member a = em.find(Member.class, "Member1");
Member b = em.find(Member.class, "Member2");

Systen.out.println(a == b); // 동일성 비교 true 
```

트랜잭션을 지원하는 쓰기 지연(transactional write-behind) - 엔티티 등록

트랜잭션 내부에서 persist()가 일어날 때,
엔티티들을 1차 캐시에 저장하고, 논리적으로 쓰기 지연 SQL 저장소 라는 곳에 INSERT 쿼리들을 생성해서 쌓아 놓는다.
DB에 바로 넣지 않고 기다린다.
언제 넣냐. commit()하는 시점에 DB에 동시에 쿼리들을 쫙 보낸다.(쿼리를 보내는 방식은 동시 or 하나씩 옵션에 따라)
이렇게 쌓여있는 쿼리들을 DB에 보내는 동작이 flush() 이다.
flush() 는 1차캐시를 지우지는 않는다. 쿼리들을 DB에 날려서 DB와 싱크를 맞추는 역할을 한다.
실제로 쿼리를 보내고 나서, commit()한다.

트랜잭션을 커밋하게 되면, flush() 와 commit() 두가지 일을 하게 되는 것이다.

EntityManager em = emf.createEntityManager();
EntityTransaction transaction = em.getTransaction();
// 엔티티 매니저는 데이터 변경시 트랜잭션을 시작해야 한다.
transaction.begin(); // 트랜잭션 시작

em.persist(memberA);
em.persist(memberB);
// 이때까지 INSERT SQL을 데이터베이스에 보내지 않는다.

// 커밋하는 순간 데이터베이스에 INSERT SQL을 보낸다.
transaction.commit(); // 트랜잭션 커밋

persistence.xml에 아래와 같은 옵션을 줄 수 있다.
- JDBC 일괄 처리 옵션으로 커밋 직전까지 insert 쿼리를 해당 사이즈 만큼 모아서 한번에 처리한다.
```
<property name="hibernate.jdbc.batch_size" value=10/>
```

변경 감지(Dirty Checking) - 엔티티 수정

엔티티 수정이 일어나면 update()나 persist()로 영속성 컨텍스트에 알려줘야 하지 않을까?

EntityManager em = emf.createEntityManager();
EntityTransaction transaction = em.getTransaction();
transaction.begin(); // 트랜잭션 시작

// 영속 엔티티 조회
Member memberA = em.find(Member.class, "memberA");

// 영속 엔티티 수정
memberA.setUsername("nj");
memberA.setAge(27);

//em.update(member) 또는 em.persist(member)로 다시 저장해야 하지 않을까?

transaction.commit(); // 트랜잭션 커밋

엔티티 데이터만 수정하면 끝이다. 데이터만 set하고 트랜잭션을 커밋하면 자동으로 업데이트 쿼리가 나간다.
어떻게 이게 가능할까?
변경 감지를 Dirty Checking이라고 한다.
사실은 1차 캐시에 저장할 때 동시에 스냅샷 필드도 저장한다.
그러고나서 commit()또는 flush()가 일어날 때 엔티티와 스냅샷을 비교해서, 변경사항이있으면 UPDATE SQL을 알아서 만들어서 DB에 저장한다.
update() 만들면 되지 왜 이렇게 복잡한 방법으로 처리하나...
- 사상 때문이다. 우리는 자바 컬렉션에서, 리스트에서 값을 변경하고 리스트에 다시 그 값을 담지 않는다.
- 값을 변경하면 변경된 리스트가 유지되는 것과 같은 컨셉이다.
따라서, 영속상태의 엔티티를 가져와서 값만 바꾸면 수정은 끝이다.
엔티티 수정시 기본적으로 전체 필드 다 업데이트, 변경된 필드만 반영 되도록 할 수도 있음. @DynamicUpdate
- https://jojoldu.tistory.com/415

엔티티 삭제

Member memberA = em.find(Member.class, "memberA");

em.remove(memberA); // 엔티티 삭제

삭제는 위의 매커니즘이랑 같고, 트랜잭션의 commit 시점에 DELETE 쿼리가 나간다.

플러시

플러시는 영속성 컨텍스트의 변경 내용을 데이터베이스에 반영한다.
트랜잭션 커밋이 일어날 때 플러시가 동작하는데, 쓰기 지연 저장소에 쌓아 놨던 INSERT, UPDATE, DELETE SQL들이 데이터베이스에 날라간다.
쉽게 얘기해서 영속성 컨텍스트의 변경 사항들과 데이터베이스를 싱크하는 작업이다.

플러시 발생

플러시가 발생하면 어떤 일이 생기나
- 변경을 감지한다. Dirty Checking.
- 수정된 엔티티를 쓰기 지연 SQL 저장소에 등록한다.
- 쓰기 지연 SQL 저장소의 쿼리를 데이터베이스에 전송한다.(등록, 수정, 삭제 SQL)
- 플러시가 발생한 다고 커밋이 이루어지는게 아니고, 플러시 다음에 커밋이 일어난다.

영속성 컨텍스트를 Flush 하는 방법

em.flush() 로 직접호출

// 영속
Member member = new Member(200L, "A");
em.persist(member);

em.flush();

System.out.println("플러시 직접 호출하면 쿼리가 커밋 전 플러시 호출 시점에 나감");

transaction.commit();

트랜잭션 커밋시 플러시 자동 호출
JPQL 쿼리 실행하면 플러시 자동 호출
- JPQL 쿼리 실행시 플러시가 자동으로 호출되는 이유는
- 아래와 같이 member1,2,3을 영속화한 상태에서. 쿼리는 안날라간 상태
- JPQL로 SELECT 쿼리를 날리려고 하면 저장되어 있는 값이 없어서 문제가 생길 수 있다.
- JPA는 이런 상황을 방지하고자 JPQL 실행 전에 무조건 flush()로 DB와의 싱크를 맞춘 다음에 JPQL 쿼리를 날리도록 설정 되어 있다.
- 그래서 아래의 상황에서는 JPQL로 멤버들을 조회할 수 있다.
```
em.persist(memberA);
em.persist(memberA);
em.persist(memberA);

// 중간에 JPQL 실행
query = em.createQuery("select m from Member m", Member.class);
List<Member> members = query.getResultList();
```
플러시가 일어나면 1차 캐시가 삭제될까?
- 삭제 되지 않는다. 쓰기 지연 SQL 저장소에 있는 쿼리들만 DB에 전송되고 1차 캐시는 남아있다.

플러시 모드 옵션

em.setFlushMode(FlushModeType.COMMIT);
- FlushModeType.AUTO
  - 커밋이나 쿼리를 실행할 때 플러시(기본값)
- FlushModeType.COMMIT
  - 커밋 할때만 플러시

플러시 정리

플러시는 영속성 컨텍스트를 비우지 않는다. 오해하면 안된다.
플러시는 영속성 컨텍스트의 변경 내용을 데이터베이스에 동기화 한다.
플러시가 동작할 수 있는 이유는 데이터베이스 트랜잭션이라는 작업 단위(개념)가 있기 때문이다.
- 어쨋든 트랜잭션이 시작되고 커밋되는 시점에만 동기화 해주면 되기 때문에, 그 사이에서 플러시 매커니즘의 동작이 가능한 것이다.
JPA는 기본적으로 데이터를 맞추거나 동시성에 관련된 것들은 데이터베이스 트랜잭션에 위임한다. 참고로 알아두자.

준영속 상태

영속 상태
- 영속성 컨텍스트의 1차 캐시에 올라간 상태가 영속 상태이다. 엔티티 매니저가 관리하는 상태.
- em.persist()로 영속성 컨텍스트에 저장한 상태도 영속 상태이지만,
- em.find()로 조회를 할 때, 영속성 컨텍스트 1차 캐시에 없어서 DB에서 조회해와서 1차 캐시에 저장한 상태도 영속 상태다.
- 코드로 보면
  - em.find()가 일어 날때, 1차 캐시에 없으므로 DB에서 조회한 엔티티를 1차 캐시에 넣는다. 영속상태가 됐다.
  - setName으로 이름을 바꾸고 커밋 하려니까, Dirty Checking이 일어나서 1차 캐시의 엔티티와 스냅샷이 다른 것을 감지하고 Update 쿼리를 날리게 된다.
```
Member member = em.find(Member.class, 150L);

member.setName("AAAAA");
transaction.commit();
```
준영속 상태 - 영속 상태의 엔티티가 영속성 컨텍스트에서 분리된 상태(detached)
- em.detach(member); 로 멤버를 영속성 컨텍스트에서 분리하고
- 트랜잭션을 커밋하면, 아무 일도 일어나지 않는다. JPA가 관리 하지 않는 객체가 된다.
- 실제로 아래에선 UPDATE 쿼리가 나가지 않는다.
```
Member member = em.find(Member.class, 150L);
member.setName("AAAAA");

em.detach(member);

transaction.commit();
```
영속성 컨텍스트가 제공하는 기능을 사용하지 못함. 쿼리 안나감.
준영속 상태로 만드는 방법
- em.detach(entity) - 특정 엔티티만 준영속 상태로 전환
- em.clear() - 영속성 컨텍스트를 완전히 초기화
  - 아래 코드의 경우 첫번째 find에서 멤버를 SELECT 해서 영속성 컨텍스트에 저장하고
  - 영속성 컨텍스트를 초기화 했다.
  - 그러고나서 같은 아이디를 가지는 멤버를 다시 조회했을때는 SELECT 쿼리가 다시 나간다.
  - 총 2번의 SELECT 쿼리가 발생한다.
  - clear는 테스트 케이스 작성시에 도움이 된다.
```
Member member = em.find(Member.class, 150L);
member.setName("AAAAA");

em.clear();

Member member1 = em.find(Member.class, 150L);

transaction.commit();
```
- em.close() - 영속성 컨텍스트를 종료

Reference

자바 ORM 표준 JPA 프로그래밍

[JPA] @MappedSuperclass

nroo — Mon, 26 Aug 2019 19:45:18 +0900

@MappedSuperclass

객체의 입장에서 공통 매핑 정보가 필요할 때 사용한다.
id, name은 객체의 입장에서 볼 때 계속 나온다.
이렇게 공통 매핑 정보가 필요할 때, 부모 클래스에 선언하고 속성만 상속 받아서 사용하고 싶을 때 @MappedSuperclass를 사용한다.
DB 테이블과는 상관없다. 아래에 보면 DB는 매핑 정보 다 따로 쓰고 있다. 객체의 입장이다.

코드로 이해하기

생성자, 생성시간, 수정자, 수정시간을 모든 엔티티에 공통으로 가져가야 하는 상황에서
아래와 같이 BaseEntity를 정의해서 활용할 수 있다.

BaseEntity.java

매핑정보만 상속받는 Superclass라는 의미의 @MappedSuperclass 어노테이션 선언

@Getter
@Setter
@MappedSuperclass
public abstract class BaseEntity {

    private String createdBy;

    private LocalDateTime createdDate;

    private String lastModifiedBy;

    private LocalDateTime lastModifiedDate;
}

Member.java, Team.java

BaseEntity 상속

@Entity
public class Member extends BaseEntity {
    ...
}

@Entity
public class Team extends BaseEntity {
    ...
}

실행된 DDL

BaseEntity에 선언된 컬럼들이 생성 된다.

Hibernate: 
    create table Member (
       id bigint generated by default as identity,
        createdBy varchar(255),
        createdDate timestamp,
        lastModifiedBy varchar(255),
        lastModifiedDate timestamp,
        age integer,
        description clob,
        roleType varchar(255),
        name varchar(255),
        locker_id bigint,
        team_id bigint,
        primary key (id)
    )
Hibernate: 
    create table Team (
       id bigint generated by default as identity,
        createdBy varchar(255),
        createdDate timestamp,
        lastModifiedBy varchar(255),
        lastModifiedDate timestamp,
        name varchar(255),
        primary key (id)
    )
...

정리

상속광계 매핑이 아니다.
@MappedSuperclass가 선언되어 있는 클래스는 엔티티가 아니다. 당연히 테이블과 매핑도 안된다.
단순히 부모 클래스를 상속 받는 자식 클래스에 매핑 정보만 제공한다.
조회, 검색이 불가하다. 부모 타입으로 조회하는 것이 불가능하다는 이야기.(em.find(BaseEntity) 불가능)
직접 생성해서 사용할 일이 없으므로 추상 클래스로 만드는 것을 권장한다.
테이블과 관계가 없고, 단순히 엔티티가 공통으로 사용하는 매핑 정보를 모으는 역할을 한다.
주로 등록일, 수정일, 등록자, 수정자 같은 전체 엔티티에서 공통으로 적용하는 정보를 모을 때 사용한다.
참고
- JPA에서 @Entity 클래스는 @Entity나 @MappedSuperclass로 지정한 클래스만 상속할 수 있다.

Reference

자바 ORM 표준 JPA 프로그래밍

[JPA] 상속관계 매핑 전략(@Inheritance, @DiscriminatorColumn)

nroo — Mon, 26 Aug 2019 19:42:13 +0900

상속관계 매핑

객체는 상속관계가 존재하지만, 관계형 데이터베이스는 상속 관계가 없다.(대부분)
그나마 슈퍼타입 서브타입 관계라는 모델링 기법이 객체 상속과 유사하다.
상속관계 매핑이라는 것은 객체의 상속 구조와 DB의 슈퍼타입 서브타입 관계를 매핑하는 것이다.

슈퍼타입 서브타입 논리 모델 -> 물리모델 구현 방법

객체는 상속을 지원하므로 모델링과 구현이 똑같지만, DB는 상속을 지원하지 않으므로 논리 모델을 물리 모델로 구현할 방법이 필요하다.
DB의 슈퍼타입 서브타입 논리 모델을 실제 물리 모델로 구현하는 방법은 세가지 있다.
중요한건, DB입장에서 세가지로 구현하지만 JPA에서는 어떤 방식을 선택하던 매핑이 가능하다.
JPA가 이 세가지 방식과 매핑하려면
- @Inheritance(strategy=InheritanceType.XXX)의 stategy를 설정해주면 된다.
  - default 전략은 SINGLE_TABLE(단일 테이블 전략)이다.
  - InheritanceType 종류
    - JOINED
    - SINGLE_TABLE
    - TABLE_PER_CLASS
- @DiscriminatorColumn(name="DTYPE")
  - 부모 클래스에 선언한다. 하위 클래스를 구분하는 용도의 컬럼이다. 관례는 default = DTYPE
- @DiscriminatorValue("XXX")
  - 하위 클래스에 선언한다. 엔티티를 저장할 때 슈퍼타입의 구분 컬럼에 저장할 값을 지정한다.
  - 어노테이션을 선언하지 않을 경우 기본값으로 클래스 이름이 들어간다.

객체의 상속관계 구현

Item

@Entity
@Inheritance(strategy = InheritanceType.XXX) // 상속 구현 전략 선택
public class Item {

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

    private String name;
    private int price;
}

Album

@Entity
public class Album extends Item {

    private String artist;
}

Movie

@Entity
public class Movie extends Item {

    private String director;
    private String actor;
}

Book

@Entity
public class Book extends Item {

    private String author;
    private String isbn;
}

1 - 각각의 테이블로 변환하는 조인 전략(JOINED)

가장 정규화 된 방법으로 구현하는 방식이다.
NAME, PRICE가 ITEM 테이블에만 저장되고, ALBUM, MOVIE, BOOK이 각자의 데이터만 저장한다.

Item 엔티티 - @Inheritance(strategy = InheritanceType.JOINED) 전략

하이버네이트의 조인 전략에서는 @DiscriminatorColumn을 선언하지 않으면 DTYPE 컬럼이 생성되지 않는다.
어차피 조인하면 앨범인지 무비인지 알 수 있다. 그래도, DTYPE을 넣어주는 것이 명확하다. 넣어주자.

@Entity
@Inheritance(strategy = InheritanceType.JOINED)
@DiscriminatorColumn // 하위 테이블의 구분 컬럼 생성(default = DTYPE)
public class Item {

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

    private String name;
    private int price;
}

실제 실행된 DDL

테이블 4개 생성
하위 테이블에 외래키 제약조건 생성. 하위 테이블 입장에서는 ITEM_ID가 PK이면서 FK로 잡아야 한다.
조인 전략에 맞는 테이블들이 생섬됨.

Hibernate: 
    create table Album (
       artist varchar(255),
        id bigint not null,
        primary key (id)
    )
Hibernate: 
    create table Book (
       author varchar(255),
        isbn varchar(255),
        id bigint not null,
        primary key (id)
    )
Hibernate: 
    create table Item (
       DTYPE varchar(31) not null,
        id bigint generated by default as identity,
        name varchar(255),
        price integer not null,
        primary key (id)
    )
Hibernate: 
    create table Movie (
       actor varchar(255),
        director varchar(255),
        id bigint not null,
        primary key (id)
    )
    
    
Hibernate: 
    alter table Album 
       add constraint FKcve1ph6vw9ihye8rbk26h5jm9 
       foreign key (id) 
       references Item
Hibernate: 
    alter table Book 
       add constraint FKbwwc3a7ch631uyv1b5o9tvysi 
       foreign key (id) 
       references Item
Hibernate: 
    alter table Movie 
       add constraint FK5sq6d5agrc34ithpdfs0umo9g 
       foreign key (id) 
       references Item

Movie 객체를 저장하면?

Insert 쿼리가 두개 나간다.
Item 테이블, Movie 테이블 저장.
DTYPE에 클래스 이름이 디폴트로 저장됨.

Movie movie = new Movie();
movie.setDirector("감독A");
movie.setActor("배우B");
movie.setName("분노의질주");
movie.setPrice(35000);

em.persist(movie);

tx.commit();

Hibernate: 
    /* insert advancedmapping.Movie
        */ insert 
        into
            Item
            (id, name, price, DTYPE) 
        values
            (null, ?, ?, 'Movie')
Hibernate: 
    /* insert advancedmapping.Movie
        */ insert 
        into
            Movie
            (actor, director, id) 
        values
            (?, ?, ?)

Movie 객체를 조회하면?

flush(), clear() 해주면, DB에 insert쿼리 날리고, 1차 캐시 지우므로 find에서 SELECT 쿼리가 나간다.
Item과 inner join을 통해서 결과를 조회한다.

Movie movie = new Movie();
movie.setDirector("감독A");
movie.setActor("배우B");
movie.setName("분노의질주");
movie.setPrice(35000);

em.persist(movie);

em.flush();
em.clear();  //DB에 insert쿼리 날리고, 1차 캐시 지우므로 find에서 SELECT 쿼리가 나간다.

em.find(Movie.class, movie.getId());

tx.commit();

Hibernate: 
    select
        movie0_.id as id2_2_0_,
        movie0_1_.name as name3_2_0_,
        movie0_1_.price as price4_2_0_,
        movie0_.actor as actor1_3_0_,
        movie0_.director as director2_3_0_ 
    from
        Movie movie0_ 
    inner join
        Item movie0_1_ 
            on movie0_.id=movie0_1_.id 
    where
        movie0_.id=?

2 - 통합 테이블로 변환하는 단일 테이블 전략(SINGLE_TABLE)

서비스 규모가 크지 않고, 굳이 조인 전략을 선택해서 복잡하게 갈 필요가 없다고 판단 될 때에는
한 테이블에 다 저장하고, DTYPE으로 구분하는 단일 테이블 전략을 선택할 수 있다.
INSERT 쿼리도 한 번, SELECT 쿼리도 한 번이다. 조인할 필요가 없고, 성능이 좋다.

단일 테이블 적용

strategy를 SINGLE_TABLE로 변경하면 끝난다.
- JPA의 장점이다. 테이블 구조의 변동이 일어났는데, 코드를 거의 손대지 않고 어노테이션만 수정했다.
- 만약 JPA를 쓰지 않았더라면, 테이블 구조의 변경이 일어나면 거의 모든 코드를 손대야 할 것이다.
단일 테이블 전략에서는 @DiscriminatorColumn을 선언해 주지 않아도, 기본으로 DTYPE 컬럼이 생성된다.

한 테이블에 모든 컬럼을 저장하기 때문에, DTYPE 없이는 테이블을 판단할 수 없다.

@Entity
@DiscriminatorColumn
@Inheritance(strategy = InheritanceType.SINGLE_TABLE)
public class Item {

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

    private String name;
    private int price;
}

실행된 DDL

통합 테이블이 하나 생성된다.

Hibernate: 
    create table Item (
       DTYPE varchar(31) not null,
        id bigint generated by default as identity,
        name varchar(255),
        price integer not null,
        artist varchar(255),
        author varchar(255),
        isbn varchar(255),
        actor varchar(255),
        director varchar(255),
        primary key (id)
    )

조인 전략에서 실습했던 Movie 저장, 조회 예제를 그대로 돌려보면?

Item 테이블을 그냥 조회한다. 조인하지 않고, DTYPE을 검색 조건으로 추가해서 Movie를 조회

Hibernate: 
    select
        movie0_.id as id2_0_0_,
        movie0_.name as name3_0_0_,
        movie0_.price as price4_0_0_,
        movie0_.actor as actor8_0_0_,
        movie0_.director as director9_0_0_ 
    from
        Item movie0_ 
    where
        movie0_.id=? 
        and movie0_.DTYPE='Movie'

3 - 서브타입 테이블로 변환하는 구현 클래스마다 테이블을 생성하는 전략(TABLE_PER_CLASS)

조인 전략과 유사하지만, 슈퍼 타입의 컬럼들을 서브 타입으로 내린다. NAME, PRICE 컬럼들이 중복되도록 허용하는 전략이다.

구현 클래스마다 테이블 생성 전략 적용

@Id 생성 전략 GenerationType.AUTO를 사용하는 경우 strategy를 TABLE_PER_CLASS로 변경하고
이때, ITEM 엔티티는 실제 생성되는 테이블이 아니므로 abstract 클래스여야 하고, @DiscriminatorColumn도 필요가 없어진다.
- 하지만, @Id 생성 전략 GenerationType.IDENTITY를 사용하는 경우 문제가 있다.
- @Inheritance의 TABLE_PER_CLASS와 @Id의 GenerationType을 IDETITY를 같이 사용할 경우 에러 발생
  - Cannot use identity column key generation with <union-subclass> mapping for
  - @Id의 GenerationType을 TABLE 타입으로 변경 적용해서 해결. 그러나, 시퀀스 테이블이 생성되므로 이것에 대한 매핑까지 추가해줘야 완벽히 해결이 된다.
  - https://stackoverflow.com/questions/916169/cannot-use-identity-column-key-generation-with-union-subclass-table-per-clas

Item 엔티티 설정

@Entity
@Inheritance(strategy = InheritanceType.TABLE_PER_CLASS)
public abstract class Item {

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

    private String name;
    private int price;
}

생성된 DDL

하위 테이블 3개만 생성된다.

Hibernate:
    create table Album (
       id bigint not null,
        name varchar(255),
        price integer not null,
        artist varchar(255),
        primary key (id)
    )
Hibernate: 
    create table Book (
       id bigint not null,
        name varchar(255),
        price integer not null,
        author varchar(255),
        isbn varchar(255),
        primary key (id)
    )
Hibernate: 
    create table Movie (
       id bigint not null,
        name varchar(255),
        price integer not null,
        actor varchar(255),
        director varchar(255),
        primary key (id)
    )

조인 전략에서의 Movie 저장, 조회를 그대로 실행한 결과는?

Movie 테이블에 insert
Movie 테이블에서 select

Hibernate: 
    /* insert advancedmapping.Movie
        */ insert 
        into
            Movie
            (name, price, actor, director, id) 
        values
            (?, ?, ?, ?, ?)
Hibernate: 
    select
        movie0_.id as id1_2_0_,
        movie0_.name as name2_2_0_,
        movie0_.price as price3_2_0_,
        movie0_.actor as actor1_3_0_,
        movie0_.director as director2_3_0_ 
    from
        Movie movie0_ 
    where
        movie0_.id=?

문제점

객체지향 프로그래밍에서는 MOVIE, ALBUM, BOOK 객체를 ITEM 타입으로도 조회할 수 있다.

Movie movie = new Movie();
movie.setDirector("감독A");
movie.setActor("배우B");
movie.setName("분노의질주");
movie.setPrice(35000);

em.persist(movie);

em.flush();
em.clear();

em.find(Item.class, movie.getId());

tx.commit();

실행된 SQL

union all로 전체 하위 테이블을 다 찾는다.
INSERT 까진 심플했으나, 조회가 시작되면 굉장히 비효율적으로 동작한다.

Hibernate: 
    select
        item0_.id as id1_2_0_,
        item0_.name as name2_2_0_,
        item0_.price as price3_2_0_,
        item0_.artist as artist1_0_0_,
        item0_.author as author1_1_0_,
        item0_.isbn as isbn2_1_0_,
        item0_.actor as actor1_3_0_,
        item0_.director as director2_3_0_,
        item0_.clazz_ as clazz_0_ 
    from
        ( select
            id,
            name,
            price,
            artist,
            null as author,
            null as isbn,
            null as actor,
            null as director,
            1 as clazz_ 
        from
            Album 
        union
        all select
            id,
            name,
            price,
            null as artist,
            author,
            isbn,
            null as actor,
            null as director,
            2 as clazz_ 
        from
            Book 
        union
        all select
            id,
            name,
            price,
            null as artist,
            null as author,
            null as isbn,
            actor,
            director,
            3 as clazz_ 
        from
            Movie 
    ) item0_ 
where
    item0_.id=?

상속관계 매핑 정리

조인 전략
- 장점
  - 테이블이 정규화가 되어있고,
  - 외래 키 참조 무결성 제약조건 활용 가능
    - ITEM의 PK가 ALBUM, MOVIE, BOOK의 PK이자 FK이다. 그래서 다른 테이블에서 아이템 테이블만 바라보도록 설계하는 것이 가능 하다
  - 저장공간 효율화
    - 테이블 정규화로 저장공간이 딱 필요한 만큼 소비된다.
- 단점
  - 조회시 조인을 많이 사용한다. 단일 테이블 전략에 비하면 성능이 안나온다. 조인하니까.
  - 그래서 조회 쿼리가 복잡하다
  - 데이터 저장시에 INSERT 쿼리가 상위, 하위 테이블 두번 발생한다.
- 정리
  - 성능 저하라고 되어있지만, 실제로는 영향이 크지 않다.
  - 오히려 저장공간이 효율화 되기 때문에 장점이 크다.
  - 기본적으로는 조인 정략이 정석이라고 보면 된다. 객체랑도 잘 맞고, 정규화도 되고, 그래서 설계가 깔끔하게 나온다.
단일 테이블 전략
- 장점
  - 조인이 필요 없으므로 일반적인 조회 성능이 빠르다.
  - 조회 쿼리가 단순핟.
- 단점
  - 자식 엔티티가 매핑한 컬럼은 모두 NULL을 허용해야 한다.
  - 단일 테이블에 모든 것을 저장하므로 테이블이 커질 수 있다.
  - 상황에 따라서 조인 전략보다 성능이 오히려 느려질 수 있다.
    - 보통 이 상황에 해당하는 임계점을 넘을 일은 많지 않다.
구현 클래스마다 테이블 전략
- 결론은
  - 이 전략은 쓰지말자.
  - ORM을 하다보면 데이터 쪽과 객체 쪽에서 trade off를 할 때가 있는데, 이 전략은 둘 다 추천하지 않는다.
- 장점
  - 서브 타입을 명확하게 구분해서 처리할 때 효과적이다
  - NOT NULL 제약조건을 사용할 수 있다.
- 단점
  - 여러 자식 테이블을 함께 조회할 때 성능이 느리다(UNION SQL)
  - 자식 테이블을 통합해서 쿼리하기 어렵다.
  - 변경이라는 관점으로 접근할 때 굉장히 좋지 않다.
    - 예를 들어, ITEM들을 모두 정산하는 코드가 있다고 가정할 때, ITEM 하위 클래스가 추가되면 정산 코드가 변경된다. 추가된 하위 클래스의 정산 결과를 추가하거나 해야 한다.
상속관계 매핑 정리
- 기본적으로는 조인 전략을 가져가자.
- 그리고 조인 전략과 단일 테이블 전략의 trade off를 생각해서 전략을 선택하자.
- 굉장히 심플하고 확장의 가능성도 적으면 단일 테이블 전략을 가져가자. 그러나 비즈니스 적으로 중요하고, 복잡하고, 확장될 확률이 높으면 조인 전략을 가져가자.

Reference

자바 ORM 표준 JPA 프로그래밍

[JPA] @ManyToMany, 다대다[N:M] 관계

nroo — Fri, 23 Aug 2019 19:08:40 +0900

다대다[N:M]

실무에선 사용하지 않는 것을 추천한다. 사용하면 안되는 이유를 학습하자.
관계형 데이터베이스는 정규화된 테이블 2개로 다대다 관계를 표현할 수 없다.
연결 테이블(조인 테이블)을 추가해서 일대다, 다대일 관계로 풀어내야한다.
객체는 컬렉션을 사용해서 객체 2개로 다대다 관계가 가능하다.
- ORM 입장에서는 테이블은 안되고, 객체는 안되는 것을 지원해줘야 한다.
- 따라서, 아래의 그림에서와 같이 객체의 다대다 관계(멤버와 프로덕트가 서로 리스트를 가짐)와
- 테이블에서 다대다 관계를 일대다 다대일 관계로 풀어낸 것 두개의 차이를 연결해준다.
JPA @ManyToMany 어노테이션을 사용하고
@JoinTable로 연결 테이블을 지정해줄 수 있다.

다대다 단방향

@Entity
public class Member {
    ...
    
    @ManyToMany
    @JoinTable(name = "member_product")
    private List<Product> products = new ArrayList<>();
    
    ...
}

실행된 SQL

조인 테이블이 하나 생성되고, 외래 키 제약조건도 두가지가 설정 된다.

    ...
   
Hibernate: 
    
    create table member_product (
       Member_id bigint not null,
        products_id bigint not null
    )
    
    ...
    
Hibernate: 
    
    alter table member_product 
       add constraint FK17rh8i9jrsy7yqy2j6e9yijuw 
       foreign key (products_id) 
       references Product
Hibernate: 
    
    alter table member_product 
       add constraint FK3cjijenmv5sgu1w04p4ofy6ik 
       foreign key (Member_id) 
       references Member

다대다 양방향

똑같이 @ManyToMany 설정을 해주고, mappedBy 설정을 해줘야 한다.

@Entity
public class Product {

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

    private String name;

    @ManyToMany(mappedBy = "products")
    private List<Member> members = new ArrayList<>();
}

다대다 매핑의 한계

편리해 보이지만 실무에서 사용하면 안된다.
개발하다 보면, 연결 테이블이 단순히 연결만 하고 끝나지 않는다. 조인 테이블 자체에 주문시간, 수량 같은 추가 데이터가 많이 들어갈 수 있다.
하지만, 매핑 정보만 넣는 것이 가능하고, 추가 정보를 넣는 것 자체가 불가능하다.
그리고 중간 테이블이 숨겨져 있기 때문에 예상하지 못하는 쿼리들이 나간다.
이런 문제점들 때문에 실무에서는 안쓰는게 맞다고 본다.

다대다 한계 극복

어떻게 한계를 극복할까.
연결 테이블용 엔티티를 추가한다. 사실상 연결 테이블을 엔티티로 승격시킨다.
그리고 @ManyToMany를 각각 일대다, 다대일로 관계를 맺어준다.
- 사실 개인적으로 이부분에 대해서는 @ManyToOne, 다대일 관계 두개로 풀어낸다는 표현이 맞는 것 같다.
- 앞서 일대다 관계를 학습할 때, 결론적으로 다대일 양방향 매핑을 사용하자는 결론을 내기도 했고,
- 실제로 아래의 코드상으로 봐도 FK 2개를 중간테이블에서 관리하고, @ManyToOne 양방향 매핑 2개로 이어져있다.
- 테이블의 배치 순서상(Member -> MemberProduct(Order) -> Product) 표현을 @OneToMany, @ManyToOne으로 표현했던 것이라면 이해가 간다.
JPA가 만들어주는 숨겨진 매핑테이블의 존재를 바깥으로 꺼내는 것이다.
위에 다대다 매핑의 한계 첨부 그림에서는 MemberProduct의 MEMBER_ID, PRODUCT_ID를 묶어서 PK로 썻지만, 실제로는 아래 처럼 독립적으로 generated되는 id를 사용하는 것을 권장한다. ID가 두개의 테이블에 종속되지 않고 더 유연하게 개발 할 수 있다. 시스템을 운영하면서 점점 커지는데 만약 비즈니스적인 제약 조건이 커지면 PK를 운영중에 업데이트 하는 상황이 발생할 수도 있다.

코드로 이해하기

Member

멤버 엔티티에서 @OneToMany 관계로 변경한다.

@Entity
public class Member {
    ...
        
    @OneToMany(mappedBy = "member")
    private List<MemberProduct> memberProducts = new ArrayList<>();

    ...
}

Product

마찬가지로 @OneToMany 관계로 변경한다.

@Entity
public class Product {

    ...

    @OneToMany(mappedBy = "product")
    private List<MemberProduct> members = new ArrayList<>();
    
    ...
}

MemberProduct

연결 테이블을 엔티티로 승격시킨다. 그리고 @ManyToOne 매핑을 두개 한다.(연관관계의 주인)

여기서 추가 데이터가 들어간다면 아예 의미있는 엔티티 이름(Order)으로 변경 될 것이다.

@Entity
@Getter
@Setter
public class MemberProduct {

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

    @ManyToOne
    @JoinColumn(name = "member_id")
    private Member member;

    @ManyToOne
    @JoinColumn(name = "product_id")
    private Product product;
}

Reference

자바 ORM 표준 JPA 프로그래밍

[JPA] @OneToOne, 일대일[1:1] 관계

nroo — Fri, 23 Aug 2019 18:54:11 +0900

일대일 [1:1]

일대일 관계는 그 반대도 일대일이다.
일대일 관계는 특이하게 주 테이블이나 대상 테이블 중에 외래 키를 넣을 테이블을 선택 가능하다.
- 주 테이블에 외래 키 저장
- 대상 테이블에 외래 키 저장
외래 키에 데이터베이스 유니크 제약조건 추가되어야 일대일 관계가 된다.

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

회원이 딱 하나의 락커를 가지고 있는 상황이다. 반대로 락커도 회원 한명만 할당 받을 수 있는 비즈니스 적인 룰이 있고, 이때, 둘의 관계는 일대일 관계이다.
이 경우 멤버를 주 테이블로 보고 주 테이블 또는 대상 테이블에 외래 키를 저장할 수 있다. 단, 유니크 제약조건을 추가한 상태에서만.
다대일[N:1] 단방향 관계 매핑과 JPA 어노테이션만 달라지고, 거의 유사하다.

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

다대일[N:1] 양방향 매핑 처럼 외래키가 있는 곳이 연관관계의 주인이다.
JPA @OneToOne 어노테이션으로 일대일 단방향 관계를 매핑하고, @JoinColumn을 넣어준다.
- @JoinColumn은 Default 값이 있긴 하지만 지저분하게 들어간다. name을 정해주자.
- 여기까지만 매핑하면 단방향 관계이고
```
@Entity
public class Member {
    ...
        
    @OneToOne
    @JoinColumn(name = "locker_id")
    private Locker locker;
 
    ...
}
```
반대편에 mappedBy를 적용시켜주면 일대일 양방향 관계 매핑이 된다.
- mappedBy = "locker" 는 Member엔티티에 있는 Locker 필드와 매핑 되었다는 것을 의미.
- 이 member 필드는 읽기 전용 필드이다.
```
@Entity
public class Locker {
    ...
        
    @OneToOne(mappedBy = "locker")
    private Member member;
}
```

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

일대일관계에서 대상 테이블에 외래 키를 저장하는 단방향 관계는 JPA에서 지원하지 않는다.

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

일대일 주 테이블에 외래 키 양방향 매핑을 반대로 뒤집었다고 생각하면 된다. 매핑 방법은 같다.
주 테이블은 멤버 테이블이지만, 외래 키를 대상 테이블에서 관리하고 주 테이블의 락커 필드는 읽기 전용이 된다.

정리

주 테이블에 외래 키
- (주 테이블 : 많이 접근하는 테이블)
- 주 객체(많이 사용하는 객체)가 대상 객체의 참조를 가지는 것 처럼
- 주 테이블에 외래 키를 두고 대상 테이블을 찾는 방식.
- 객체지향 개발자들이 선호하고, JPA 매핑이 편리하다.
- 장점
  - 주 테이블만 조회해도 대상 테이블에 데이터가 있는지 확인이 가능하다.
- 단점
  - 값이 없으면 외래 키에 NULL을 허용해야 한다. DB입장에서는 치명적일 수 있다.
대상 테이블에 외래키

대상 테이블에 외래 키가 존재한다.
전통적인 데이터베이스 개발자들이 선호하는 방식이다. NULL을 허용해야 하는 문제도 없다.
장점
- 주 테이블과 대상 테이블을 일대일에서 일대다 관계로 변경할 때 테이블 구조를 유지할 수 있다.(멤버가 락커를 여러개 가지도록 비즈니스 룰이 변경될 경우 테이블 구조 유지하면서 유지보수 가능)
단점

코드상에서는 주로 멤버 엔티티에서 락커를 많이 엑세스 하는데, 어쩔 수 없이 양방향 매핑을 해야한다.
- 일대일 - 대상 테이블에 외래 키 단방향 매핑을 JPA에서 지원하지 않으므로, 단방향 매핑만 해서는 멤버 객체를 업데이트 했을 때 락커 테이블에 FK를 업데이트 할 방법이 없다. 따라서 양방향 매핑을 해야 한다.
JPA가 제공하는 기본 프록시 기능의 한계로 지연 로딩으로 설정해도 항상 즉시 로딩 된다.(프록시는 뒤에서 학습)

JPA 입장에서 일대일 관계의 주 테이블에 외래 키를 저장하는 상황에서는, 멤버 객체를 로딩할 때, 멤버 테이블의 FK에 락커 ID가 있는지 없는지만 판단하면 된다. 있으면 프록시 객체를 넣어주고, 없으면 null을 넣으면 된다. 나중에 진짜 락커 필드에 엑세스 할 때, 그때 쿼리가 나간다.
그런데, 대상 테이블에 외래 키를 저장한다면, JPA가 멤버의 락커를 조회하는 상황에서 DB의 멤버 테이블만 조회해서는 모른다. 어차피 락커 테이블을 찾아서 멤버가 있는지 확인 해야(쿼리를 날려 봐야) 알 수 있다. 어차피 쿼리가 나간단 이야기는 프록시를 만들 필요가 없다는 이야기이다. 그래서 하이버네이트 구현체 같은 경우는 지연 로딩으로 설정해도 항상 즉시 로딩 된다.

Reference

자바 ORM 표준 JPA 프로그래밍

[JPA] @OneToMany, 일대다[1:N] 관계

nroo — Fri, 23 Aug 2019 18:48:22 +0900

일대다 [1:N]

일대다 관계에서는 일이 연관관계의 주인이다.
일 쪽에서 외래키를 관리하겠다는 의미가 된다.
결론을 먼저 말하자면, 표준스펙에서 지원은 하지만 실무에서 이 모델은 권장하지 않는다.
일대다 단방향 매핑
- 팀과 멤버가 일대다 관계이다.
- Team이 Members를 가지는데, Member 입장에서는 Team을 참조하지 않아도 된다라는 설계가 나올 수 있다. 객체 입장에서 생각하면 충분히 나올 수 있는 설계이다.
- 그러나 DB 테이블 입장에서 보면, 무조건 일대다의 다쪽에 외래키가 들어간다.
- Team에서 members가 바뀌면, DB의 Member 테이블에 업데이트 쿼리가 나가는 상황이다.

일대다 단방향 매핑

JPA @OneToMany와 @JoinColumn()을 이용해서 일대다 단방향 매핑 코드로 이해하기

Member는 코드상 연관관계 매핑 없고, 팀에서만 일대다 단방향 매핑 설정.

@Entity
public class Team {
    ...
    
    @OneToMany
    @JoinColumn(name = "TEAM_ID")
    private List<Member> members = new ArrayList<>();
    
    ...
}

Main.java

...
Member member = new Member();
member.setUsername("NJ");
em.persist(member);

System.out.println("-----멤버 저장");

Team team = new Team();
team.setName("A");
team.getMembers().add(member);
em.persist(team);

System.out.println("-----팀 저장");

tx.commit();

실제 발생한 쿼리

log에서 확인해보면 트랜잭션 커밋 시점에 create one-to-many row로 시작되는 주석과 함께 Member 테이블을 업데이트 하는 쿼리가 나간다.

Hibernate: 
    /* insert hello.jpa.Member
        */ 
        insert 
        into
            Member
            (id, age, createdDate, description, lastModifiedDate, roleType, name) 
        values
            (null, ?, ?, ?, ?, ?, ?)
-----멤버 저장
Hibernate: 
    /* insert hello.jpa.Team
        */
        insert 
        into
            Team
            (id, name) 
        values
            (null, ?)
-----팀 저장
Hibernate: 
    /* create one-to-many row hello.jpa.Team.members */ 
    update
        Member 
    set
        TEAM_ID=? 
    where
        id=?

일대다 단방향 정리 - 문제점과 실무적인 해결 방안

일대다 단방향은 일대다(1:N)의 일(1)이 연관관계의 주인이다.
테이블 일대다 관계는 항상 다(N) 쪽에 외래키가 있다.
객체와 테이블의 패러다임 차이 때문에 객체의 반대편 테이블의 외래키를 관리하는 특이한 구조이다.

@JoinColumn을 꼭 사용해야 한다. 그렇지 않으면 조인 테이블 방식을 사용한다.(중간에 테이블을 하나 추가한다.)

실제로 TEAM_MEMBER라는 테이블이 하나 생성되고, INSERT 쿼리가 나간다.

Hibernate: 
    
    create table Team_Member (
       Team_id bigint not null,
        members_id bigint not null
    )
    
...(생략)

-----팀 저장 이후에
Hibernate: 
    /* insert collection
        row hello.jpa.Team.members */ 
        insert 
        into
            Team_Member
            (Team_id, members_id) 
        values
            (?, ?)

문제점
- 일단 업데이트 쿼리가 나간다. 성능상 좋지않다.
- Main.java 파일을 보자. 코드를 보면서 쿼리를 추적할 때,
- 팀 엔티티를 수정했는데 멤버 테이블에 업데이트 쿼리가 나가는 상황이 나오게되고,
- 실무에서는 테이블이 수십개가 엮여서 돌아가는 상황에서 위와 같은 상황은 운영을 힘들게 한다.
답은 위에서 먼저 학습한 다대일 단방향 관계로 매핑하고, 필요할 경우 양방향 매핑을 통해서 해결한다.
객체 입장에서보면, 반대방향으로 참조할 필요가 없는데 관계를 하나 만드는 것이지만, DB의 입장으로 설계의 방향을 조금 더 맞춰서 운영상 유지보수하기 쉬운 쪽으로 선택할 수 있다.

일대다 양방향 매핑

이런 매핑은 공식적으로는 존재하지 않는다.
@JoinColumn(name = "team_id", insertable = false, updatable = false) 사용.
@ManyToOne과 @JoinColumn을 사용해서 연관관계를 매핑하면, 다대일 단방향 매핑이 되어버린다. 근데 반대쪽 Team에서 이미 일대다 단방향 매핑이 설정되어있다. 이런 상황에서는 두 엔티티에서 모두 테이블의 FK 키를 관리 하게 되는 상황이 벌어진다.
그걸 막기 위해서 insertable, updatable 설정을 FALSE로 설정하고 읽기 전용 필드로 사용해서 양방향 매핑처럼 사용하는 방법이다.
읽기 전용으로 사용할 경우도 있을 수 있으니, 알아두자.

그러나, 결론은 다대일 양방향을 사용하자.

테이블이 수십개 있는데, 매핑이나 설계는 단순해야 팀원 누구나 사용할 수 있다.

@Entity
public class Member {
  ...
    
  @ManyToOne
  @JoinColumn(name = "team_id", insertable = false, updatable = false)
  private Team team;
  
  ...
}

Reference

자바 ORM 표준 JPA 프로그래밍

[JPA] @ManyToOne, 다대일[N:1] 관계

nroo — Fri, 23 Aug 2019 18:41:49 +0900

다대일 [N:1]

JPA에서 가장 많이 사용하고, 꼭 알야야 되는 다중성이다.
아래 테이블에서 보면, DB 설계상 일대다에서 다 쪽에 외래키가 있어야 한다. 그렇지 않으면 잘못된 설계다.
객체로 와서, 다대일 관계에서 다인 멤버에서 단순하게 팀으로 단방향 참조를 하고 싶다고 할 때, 테이블에 외래키 있는 쪽인 멤버 객체에서 팀객체로 연관관계 매핑 하면 된다.
테이블에서 FK가 팀을 찾기 위해 존재하고, 객체에서 Team 필드도 Team을 참조하기 위해 존재한다.
다대일의 반대는 일대다

다대일 단방향 매핑

JPA @ManyToOne 어노테이션을 사용해서 다대일 관계를 매핑한다.

@JoinColumn은 외래 키를 매핑할 때 사용한다. name은 매핑할 외래 키 이름이다.

public class Member {
  ...
  
    @ManyToOne
    @JoinColumn(name = "TEAM_ID")
    private Team team;
  
  ...
}

다대일 양방향 매핑

다대일 관계에서 단방향 매핑을 진행하고, 양방향 매핑을 진행할 때
반대쪽에서 일대다 단방향 매핑을 해주면 된다.(객체에서 컬렉션 추가해주면 된다.)
여기서 중요한건, 반대에서 단방향 매핑을 한다고 해서 DB 테이블에 영향을 전혀 주지 않는다.
다대일관계의 다 쪽에서 이미 연관관계의 주인이 되어서 외래키를 관리하고 있다.

반대쪽에서 일대다 단방향 매핑. JPA의 @OneToMany 어노테이션을 사용한다.
- 연관관계의 주인이 아니고, 어디에 매핑 됐는지에 관한 정보 (mappedBy = "team")을 꼭 넣어줘야 한다.
- (mappedBy="team")이 의미하는 바는 Team의 members 필드가 Member 엔티티의 team 필드에 의해 매핑 되어졌다는 것이다.
```
public class Team {
    ...

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

실제 발생한 쿼리 확인.

Main.java

Team team = new Team();
team.setName("A");
em.persist(team);
System.out.println("-----팀 저장");

Member member = new Member();
member.setUsername("NJ");
member.changeTeam(team);
em.persist(member);
System.out.println("-----멤버 저장");

tx.commit();

실제 발생한 쿼리

Hibernate: 
    /* insert hello.jpa.Team
        */ 
        insert 
        into
            Team
            (id, name) 
        values
            (null, ?)
-----팀 저장
Hibernate: 
    /* insert hello.jpa.Member
        */ 
        insert 
        into
            Member
            (id, age, createdDate, description, lastModifiedDate, roleType, TEAM_ID, name) 
        values
            (null, ?, ?, ?, ?, ?, ?, ?)
-----멤버 저장

정리
- 외래키가 있는 쪽이 연관관계의 주인이고,
- 양쪽을 서로 참조하도록 개발하면 된다.

Reference

자바 ORM 표준 JPA 프로그래밍

[JPA] 연관관계 매핑시 고려사항

nroo — Fri, 23 Aug 2019 18:34:23 +0900

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

다중성

JPA 에서는 다중성을 위한 어노테이션을 제공한다.
이 JPA 어노테이션들은 DB와 매핑하기 위해 존재 한다.
그래서 데이터베이스 관점에서의 다중성을 기준으로 고민 하면 된다.
다대일 - @ManyToOne
일대다 - @OneToMany
일대일 - @OneToOne
다대다 - @ManyToMany
다중성을 고민하다가 풀리지 않으면 대칭성을 고려하자. 다중성의 관계들은 대칭성을 다 가지고 있다. 예를 들면, 회원과 팀 - 팀과 회원 둘다를 고려하면 쉬워 진다.

단방향, 양방향

이전 학습 내용 정리

단방향 연관관계 - https://ict-nroo.tistory.com/121
양방향 연관관계 - https://ict-nroo.tistory.com/122

테이블은
- 외래 키 하나로 양쪽을 조인할 수 있다.
- 사실 방향이라는 개념이 없다.
객체는
- 참조용 필드가 있는 쪽으로만 참조할 수 있다.
- 한쪽만 참조하면 단방향이고
- 양쪽이 서로 참조하면 양방향이다.
  - 앞서 말했듯이 사실은 단방향이 두개가 마주보고 있는 것이다

연관관계의 주인

위의 단방향, 양방향의 개념을 알아야. 연관관계의 주인을 이해할 수 있다.
테이블은 외래 키 하나로 두 테이블이 연관관계를 맺는데,
객체의 양방향 관계는 A->B, B->A 처럼 참조가 2군데에서 일어난다.
그렇기 때문에 객체에서 둘중 테이블의 외래키를 관리할 곳을 정해야 한다.
연관관계의 주인은 외래 키를 관리하는 참조이다.
주인의 반대편에서는 외래키에 영향을 주지 않고, 단순 읽기만 할 수 있다.

Reference

자바 ORM 표준 JPA 프로그래밍

[JPA] 양방향 연관관계

nroo — Fri, 16 Aug 2019 18:16:20 +0900

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

Team을 통해서도 getMemberList()로 특정 팀에 속한 멤버 리스트를 가져오고 싶다.
객체 설계는 위와 같이 Member에서는 Team을 가지고 있고, Team에서는 Members를 가지고 있도록 설계하면 된다.
DB를 보자. DB는 단방향 매핑때와 바뀌는게 없다. 왜냐. 둘을 join 하면 된다. DB는 방향이 없다!
이 두가지가 큰 차이다.

코드로 이해

Member 엔티티는 단방향과 동일하다.

@Entity
public class Member {
  @Id
  @GeneratedValue
  private Long id;
  
  @Column(name = "USERNAME")
  private String name;
  
  private int age;

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

Team 엔티티는 컬렉션을 추가해주면 된다.
- 팀의 입장에서 바라보는일대다, @OneToMany 어노테이션을 설정하고,
- mappedBy로 team과 연관이 있는 것을 알려준다.
- 컬렉션을 매핑한다. 관례로 ArrayList로 초기화 한다. NPE 방지.
```
@Entity
public class Team {
  @Id
  @GeneratedValue
  private Long id;
  
  private String name;
  
  @OneToMany(mappedBy = "team")
  private List<Member> members = new ArrayList<Member>();
  ...
}
```

반대 방향으로 객체 그래프 탐색할 수 있다.

//팀 조회
Team findTeam = em.find(Team.class, team.getId());

// 역방향으로 멤버들 조회
int memberSize = findTeam.getMembers().size();

연관관계 주인과 mappedBy

계속 강조하지만, 객체는 방향을 가지고 있고, DB는 방향성이 없다. FK선언 하나면 양방향 관계를 맺을 수 있다.
mappedBy = JPA의 멘붕 클래스, mappedBy는 처음에는 이해하기 어렵다.
객체와 테이블간에 연관관계를 맺는 차이를 이해해야 한다.

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

객체 연관관계
- 회원 -> 팀 연관관계 1개(단방향)
- 팀 -> 회원 연관관계 1개(단방향)
- 객체의 양방향 관계
  - 객체의 양방향 관계는 사실 양방향 관계가 아니라 서로 다른 단방향 관계 2개다.
  - 객체를 양방향으로 참조하려면 억지로 단방향 연관관계를 2개 만들어야 한다.
    - A -> B(a.getB())
```
class A {
  B b;
}
```
    - B -> A(b.getA())
```
class B {
  A a;
}
```
    - 테이블 연관관계
      - 회원 <-> 팀의 연관관계 1개(양방향)
      - 테이블의 양방향 연관관계
        테이블은 외래 키 하나로 두 테이블의 연관관계를 관리한다.
        MEMBER.TEAM_ID 외래 키 하나로 양방향 연관관계를 가진다.(양쪽으로 조인할 수 있다.)
        SELECT *
        FROM MEMBER M
        JOIN TEAM T ON M.TEAM_ID = T.TEAM_ID
        
        SELECT *
        FROM TEAM T
        JOIN MEMBER M ON T.TEAM_ID = M.TEAM_ID

둘 중 하나로 외래 키를 관리해야 한다

객체로 보자. 멤버에 팀을 넣고, 팀에 멤버를 넣는다. 두군데 모두 넣어 주는데.
둘 중에 뭘로 연관관계를 매핑해야 되나?
- 멤버의 팀값을 업데이트 할때 FK 업데이트?
- 팀의 members를 업데이트 했을때 FK 업데이트?
하지만 DB 에서는 객체가 참조를 어떻게 하던, FK값만 업데이트 되면 된다.
단방향 연관관계 매핑에서는 참조와 외래키만 업데이트 하면 됐지만, 양방향 관계 매핑에서는 다르다.
이게 가장 큰 패러다임의 문제이다.

연관관계의 주인(Owner)

패러다임의 문제를 해결하기 위해 만들어진 개념이다.
양방향 매핑 규칙
- 객체의 두 관계중 하나를 연관관계의 주인으로 지정
- 연관관계의 주인만이 외래 키를 관리(등록, 수정) 한다. DB에 접근한다.
  - 객체에 둘다 정보를 업데이트 해도, 연관관계의 주인 것만 DB에 영향을 준다.
- 주인이 아닌쪽은 읽기만 가능
  - Member에 Team값을 업데이트 하면 mappedBy로 매핑된 Team의 members로 업데이트 된 DB의 멤버들을 읽을 수 있다는 이야기이다.
  - Member에 Team 정보 update 했는데, Team에서 getMembers로 가져왔는데 반영 안됐네? -> 연관관계 설정 안했구나.. 라고 바로 알 수 있다.
  - mappedBy 키워드로 연관관계 매핑이 되었다. 라는 것을 의미한다. 그래서 JoinColumn도 없다.
  - 주인은 mappedBy 속성 사용 하지 않고, @ JoinColumn
  - 주인이 아니면 mappedBy 속성으로 주인을 지정한다.

누구를 주인으로 해야 할까?

외래 키가 있는 곳을 주인으로 정해라. @JoinColumn이 있는 쪽.
- Team.members를 주인으로 선택했다고 가정하고, members를 업데이트 했다. 결과는? Team의 필드값을 바꿨는데, Member로 업데이트 쿼리가 날라간다. ???
여기서는 Member.team이 연관관계의 주인이다.
멤버와 팀이 다대일 관계인데, DB에서 보면 다쪽이 FK를 가지고 있다. 다쪽이 주인이 된다.
연관관계의 주인은 비즈니스 적으로 중요하지 않다. 단지 FK를 가진 쪽이 주인이 되면 된다.
예를 들면, 자동차와 자동차 바퀴가 있는데 비즈니스적으로는 자동차가 중요하지만, 자동차와 바퀴는 일대다 관계다. 다인 바퀴가 연관관계의 주인이 된다.
이렇게 설계 해야,
- 뒤에서 나올 성능이슈도 없고,
- 엔티티랑 테이블이 매핑이 되어있는 테이블에서 FK가 관리가 된다.
모 민족에서 프로젝트 중에, 모두 단방향으로 설계하고 개발했다. 양방향으로 뚫어서 조회가 필요한 경우에 그 때 양방향 매핑 하면 된다. 자바 코드만 수정이 일어나기 때문에 DB에 영향 주지 않는다.
- 이미, 단방향 매핑만으로 ORM 매핑이 다 끝났다. 양방향은 단순히 조회를 편하게 하기 위해 부가 기능이 조금더 들어가는 거라고 보면 된다. 어차피 조회할 수 있는 기능만 있다.

양방향 매핑시 가장 많이 하는 실수

연관관계의 주인에 값을 입력하지 않음
연관관계의 주인을 Member.team으로 잡아놓고, Team의 members에만 연관관계를 설정한다.
주인이 아닌 mappdBy가 설정 되어있는 Team의 members는 조회 권한만 가지고 있고, DB에 영향을 주지 못한다.
따라서, DB에 Member를 조회해보면, TEAM_ID 가 NULL인 상황이 발생한다.

양방향 매핑에 대해서 잘 이해하고 있으면, DB 모델링에 따라서 객체 모델링은, ORM 모델링은 이렇게 엮어 가면 되겠구나 라고 생각하는데 많은 도움이 된다.

Team team = new Team();
team.setName("TeamA");
em.persist(team);

Member member = new Member();
member.setName("member1");
em.persist(member);

//이 작업을 하지 않고,
//member.setTeam(team);

//역방향(주인이 아닌 방향)만 연관관계 설정
team.getMembers().add(member);

tx.commit();

양방향 매핑시 주의할점

양방향 매핑시 연관관계의 주인에 값을 입력해야 한다.

JPA 입장에서만 보면, 연관관계의 주인인 멤버에다가 팀을 세팅해주면 끝난다. DB에 FK값 세팅 되고 문제가 없다.
굳이 team의 members 컬렉션에 멤버를 새로 넣어주지 않아도, 지연 로딩을 통해서 해당 멤버를 조회해올 수 있기 때문에 (아래의 코드에서는)아무 문제가 없다.
- 아래의 코드에서는 em.flush(), clear() 하는 순간에 DB에 FK 세팅 된다. 그래서 지연 로딩을 해도 FK로 조인해서 가져올 수 있다.
- 하지만, em.flush(), clear()가 일어나지 않으면 DB에 쿼리가 안날라가고, FK도 없이 MEMBER가 1차 캐시에만 영속화 되어있는 상태이다. members 조회해봤자 size 0이다.
결론은 진짜 객체 지향적으로 고려하면 항상 양쪽다 값을 넣어 주는 것이 맞다.
- 추가적으로 JPA 없이 순수 자바 Object로 테스트 케이스가 동작하게끔 테스트 코드를 짤때도 NPE 발생한다. 양쪽다 넣어주자.

Team team = new Team();
team.setName("TeamA");
em.persist(team);

Member member = new Member();
member.setName("member1");
em.persist(member);

// 연관관계의 주인에 값 설정
member.setTeam(team);

// 역방향 연관관계를 설정하지 않아도, 지연 로딩을 통해서 아래에서 Member에 접근할 수 있다.
//team.getMembers().add(member);

// 이 동작이 수행되지 않으면 FK가 설정되어 있지 않은 1차캐시에만 영속화 된 상태이다. SELECT 쿼리로 조회해봤자 list 사이즈 0이다.
em.flush();
em.clear();

Team findTeam = em.find(Team.class, team.getId());
List<Member> findMembers = findTeam.getMembers();

for (Member m : findMembers) {
    // flush, clear가 일어난 후에는 팀의 Members에 넣어주지 않았지만, 조회를 할 수 있음. 이것이 지연로딩
    System.out.println(m.getUsername());
}

tx.commit();

순수 객체 상태를 고려해서 항상 양쪽에 값을 설정하자.
연관관계를 설정하다 보면 휴먼에러가 생길 여지가 많다. 연관관계 편의 메소드를 생성하는 것을 권장한다.
- 편의 메소드에서는 주인쪽에서 연관관계의 값을 설정할때, 역방향 값도 함께 설정해준다. 메소드를 원자적으로 사용해서 세트로 움직이면 실수할 일이 없어진다.
- 혹시 편의 메소드 안에 비즈니스 로직이 들어가는 복잡한 경우. 책을 참조해보자.
```
class Member {
    ...
        
    public void changeTeam(Team team) {
        this.team = team;
        team.getMembers().add(this);
    }
}
```
양방향 매핑시에 무한 루프를 주의하자

lombok이 자동으로 만드는 toString()을 사용하지 말자.

Member의 toString()

@Override
    public String toString() {
        return "Member{" +
            "id=" + id +
            ", username='" + username + '\'' +
            ", team=" + team +
            '}';
    }

Team의 toString()

@Override
    public String toString() {
        return "Team{" +
            "id=" + id +
            ", name='" + name + '\'' +
            ", members=" + members +
            '}';
    }

Member의 toString()을 호출하는 순간 Team의 toString()의 members가 호출하는 각 member의 toString()때문에 무한루프 생성. 스택오버플로우 발생

JSON 생성 라이브러리

양방향 관계의 엔티티를 JSON으로 시리얼라이즈 하는순간 무한루프에 빠져버린다.
컨트롤러에서는 엔티티를 절대 직접 반환하지 말자.

1 - 엔티티 -> JSON 시 무한루프 걸린다.
2 - 엔티티는 충분히 변경의 여지가 있는데, 엔티티 변경시 API 스펙 자체가 변경된다.

실무에서 웬만하면 DTO로 변환해서 반환하자. 그렇게 하면 JSON 생성 라이브러리 때문에 생기는 문제는 없다.

양방향 매핑 정리

단방향 매핑만으로도 이미 연관관계 매핑은 끝이다.
- 설계할 때 객체 입장에서 보면 양방향 매핑은 양쪽다 신경을 써야 하므로 복잡도가 올라간다.
- 실무에서 JPA 모델링 할 때, 단방향 매핑으로 처음에 설계를 끝내야 한다(객체와 테이블을 매핑하는 것). 일대다에서 다쪽에 단방향 매핑으로 쭉 설계하면 이미 테이블 FK 설정은 끝났다. 거기서 필요할때 양방향 매핑을 추가해서 역방향 조회 기능을 쓰면 된다. 자바 코드에 컬렉션만 추가하면 된다.
양방향 매핑은 반대 방향으로 조회(객체 그래프 탐색) 기능이 추가된 것 뿐이다.
JPQL에서 역방향으로 탐색할 일이 많다. 현업에서 많이 쓴다.
단방향 매핑을 잘 하고, 테이블이 굳어진 뒤에 양방향 매핑은 필요할 때 추가해도 된다. 테이블에 영향주지 않는다.
- 그동안 학습한 것을 보면, 단방향 매핑에서 양방향 매핑으로 넘어가면서 추가된 것은 팀 객체(엔티티)에 members 컬렉션이 들어간것 뿐이다. 테이블은 똑같다.
연관관계의 주인을 정하는 기준은
- 비즈니스 로직을 기준으로 주인을 선택하면 안된다.
- 연관관계 주인은 외래 키의 위치를 기준으로 정해야 한다.

Reference

자바 ORM 표준 JPA 프로그래밍

[JPA] 단방향 연관관계

nroo — Fri, 16 Aug 2019 18:07:05 +0900

단방향 연관관계 매핑 이론

객체지향 모델링

객체 연관관계 사용해서 아래의 객체 참조와 테이블의 외래키를 매핑하는 방법 학습

객체의 참조와 테이블의 외래 키를 매핑한다.
- 외래 키 대신에 TEAM 객체를 넣고
- TEAM_ID를 매핑한다. @JoinColumn으로 조인 컬럼을 명시한다. 안적어도 default로 들어간다. 적어주는게 더 명시적이다.
- 그리고 연관관계를 설정한다 @ManyToOne.
- 하나의 Team이 여러개의 Member를 가지고 있다.
- 그렇게 보면 TEAM 입장에서는 일대다,
- Member 입장에서는 다대일이다. @ManyToOne.
- 이렇게 설정하면 Team 이라는 필드가 DB에 있는 TEAM_ID라는 FK와 매핑이 된다.
- 관계를 선언하고 조인할 컬럼을 매핑 했다.
- 이것을 연관관계 매핑이라고 한다. ORM 매핑!!!!!!!
```
@Entity
public class Member {
  @Id
  @GeneratedValue
  private Long id;
  
  @Column(name = "USERNAME")
  private String name;
  
  private int age;
  
//  @Column(name = "TEAM_ID")
//  private Long teamId;
  
  @ManyToOne
  @JoinColumn(name = "TEAM_ID")
  private Team team;
  ...
}
```

객체의 참조와 테이블의 외래키를 매핑한 후의 모델링(ORM 매핑)

연관관계 저장 방법

member.setTeam(team)
Team 객체를 그대로 넣어버린다.

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

//회원 저장
Member member = new Memeber();
member.setName("member1");
member.setTeam(team);    //단방향 연관관계 설정, 참조 저장
em.persist(member);

Member findMember = em.find(Member.class,  member.getId());

이렇게 했을때 조회시 Member를 가져와서 getTeam()으로 팀을 바로 조회할 수 있다.
- 참조로 연관관계 조회 가능. 객체 그래프 탐색!!
- 물론, 위의 em.find()시 select 쿼리는 날라가지 않는다.
  - persist()시 JPA 내부에서 1차캐시를 저장하기 때문에, select 쿼리가 안나가고 캐시에서 리턴한다.
- 아래의 코드에서 1차 캐시를 클리어 하고, 멤버와 팀의 연관관계를 조회한 쿼리를 보면 애초에 JPA가 조인을 해서 한방쿼리로 가져오는 걸 확인할 수 있다.
- 하지만, 처음부터 조인해서 가져오지 않고 일단 멤버만 가져오고 싶다라고 하면
- @ManyToOne에 패치 옵션을 줄 수 있다.
  - @ManyToOne(fetch = FetchType.LAZY)
    - 레이지 로딩, 지연로딩. 실제 연관관계를 가진 팀이 Touch 될 때, 그 때 Team을 조회하는 쿼리를 날려서 가져온다.
  - @ManyToOne(fetch = FetchType.EAGER)
    - 패치 옵션의 기본값은 EAGER이다. 연관관계를 가진 객체를 조인해서 먼저 다 가져온다.
    - 현업에서는 전부다 LAZY로 기본 설정 해 놓고,
    - 꼭 필요한 데서만, 쿼리를 실제 날리는 시점에 원하는 결과를 최적화해서 가져오는 방법을 사용하는 것을 권장한다.
```
//캐시 클리어해서 find시 날라가는 쿼리 확인 가능
em.flush();
em.clear();

//조회
Member findMember = em.find(Member.class, member.getId());

//참조를 사용해서 연관관계 조회
Team findTeam = findMember.getTeam();
```

연관관계 수정

setTeam()으로 새로운 팀을 할당하면, 연관관계가 바뀐다.
Update 쿼리를 통해서 FK에 들어간 Value가 바뀐다.

//새로운 팀B
Team teamB = new Team();
team.setName("TeamB");
em.persist(teamB);

//회원1에 새로운 팀B 설정
member.setTeam(teamB);

Reference

자바 ORM 표준 JPA 프로그래밍

[Spring Framework] IoC Container, ApplicationContext와 Bean

nroo — Thu, 1 Aug 2019 20:50:34 +0900

1. 스프링 IoC 컨테이너와 빈

Inversion of Control
- 의존 관계 주입(Dependency Injection)이라고도 하며, 어떤 객체가 사용하는 의존 객체를 직접 만들어 사용하는게 아니라, 주입 받아 사용하는 방법을 말함.
스프링 IoC 컨테이너
- BeanFactory
  - 스프링 프레임워크의 중요한 인터페이스
- 애플리케이션 컴포넌트의 중앙 저장소
- 빈 설정 소스로부터 빈 정의를 읽어들이고, 빈을 구성하고 제공한다.
Bean - 빈
- 스프링 IoC 컨테이너가 관리 하는 객체
- 장점
  - 의존성 관리
    - 의존성 관리를 할 수 없다고 생각해보자
    - 예를 들어, 서비스 객체 내에서 Repository 의존성을 직접 만들어서 사용하는 경우, 서비스 단의 단위 테스트를 독립적으로 작성하기가 힘들다.
    - 의존성을 주입 받을 수 있기 때문에 객체(Repository)를 Mocking 해서 얼마든지 단위 테스트를 할 수 있다.
  - 스코프
    - 싱글톤: 하나
      - 빈의 기본 스코프 설정은 싱글톤
      - 메모리 관리 등 성능 최적화 이점
    - 프로토타입: 매번 다른 객체 생성
  - 라이프 사이클 인터페이스
    - @PostConstruct 등
ApplicationContext
- ApplicationContext는 spring-context 모듈 안에 위치함
- spring-beans 모듈의 BeanFactory(스프링 IoC 컨테이너)를 상속받고, 그외 다양한 기능을 가지는 인터페이스도 추가로 상속받은 인터페이스
  - ListableBeanFactory
  - HierarchicalBeanFactory
  - EnvironmentCapable
    - spring-core 모듈
    - 프로파일과 프로퍼티를 다루는 인터페이스
  - MessageSource
    - spring-context 모듈
    - 메세지 소스 처리 기능(i18n)
  - ApplicationEventPublisher
    - spring-context 모듈
    - 이벤트 발행 기능
  - ResourcePatternResolver
    - spring-core 모듈
    - ResourceLoader
    - 리소스 로딩 기능 등

2. ApplicationContext와 다양한 빈 설정 방법

스프링 IoC 컨테이너의 역할
- 빈 인스턴스 생성
- 의존 관계 설정
- 빈 제공
ClassPathXmlApplicationContext로 빈과 의존관계 등을 XML 파일로 일일히 설정하는 방법이 있었고, 이 굉장한 번거로움을 피하고자 등장한 것이 component-scan 이다.
- 특정 패키지 하위에 있는 빈이 될 클래스들을 모두 스캔해서 빈으로 등록하는 방법이다.
- 빈 스캐닝시 기본적으로 @Component 어노테이션을 사용해서 빈으로 등록할 수 있고,
- @Component를 확장한 @Controller, @Service, @Repository 모두 컴포넌트 스캔의 대상이 된다.

Java Config로 직접 빈 설정도 사용할 수 있다.

AnnotationConfigApplicationContext

@Configuration
public class ApplicationConfig{
   
   @Bean
   public BookRepository bookRepository() {
       return new BookRepository();
  }
   
   @Bean
   public BookService bookService() {
       BookService bookService() = new BookService();
       bookService.setBookRepository(boookRepository());
       return bookService; 
  }
}

사실, Java Config로 일일히 하는 것도 번거롭다. 그래서 여기서도 @ComponentScan을 사용할 수 있다 :)
- ComponentScan 대상 지정을 basePackages와 basePackageClasses 두가지 방법으로 할 수 있지만, 더 타입세이프 한 방법은 클래스 기준으로 가져가는 것이다.
- 이 방법이 Spring Boot를 기반으로 Spring을 사용하는 것과 가장 가까운 방법이다.
```
@Configuration
@ComponentScan(basePackageClasses = DemoApplication.class)
public class ApplicationConfig {

}
```
```
public class DemoApplication {
   public static void main(String[] args) {
       ApplicationContext context = new AnnotationConfigApplicationContext(ApplicationConfig.class);
       
      ...
           
  }
}
```
- 물론 스프링 부트에서는 ApplicationContext를 만드는 것 조차 @SpringBootApplication이 해준다.
  - @SpringBootApplication을 타고 들어가보면, @SpringBootConfiguration이 @Configuration을 가지고 있고, @ComponentScan이 선언되어있다.
  - 따라서 Java Config 설정때 만들었던 ApplicationConfig도 필요 없다.
  - @SpringBootApplication이 다 해준다.
```
@SpringBootApplication
public class DemoApplication {
   public static void main(String[] args) {
           
  }
}
```

3. Bean Scope

ApplicationContext에 생성된 빈들은 스코프를 가지고 있다. 아무 설정도 해주지 않았으면. default인 싱글톤 스코프를 가진다.
스코프
- 싱글톤
  - 애플리케이션 전반에 걸쳐서, 해당 빈의 인스턴스가 오직 한개
- 프로토타입
  - 빈을 주입 받아올 때마다 새로운 빈이 생성된다.
프로토타입 빈이 싱글톤 빈을 참조하면?
- 아무 문제 없다.
싱글톤 빈이 프로토타입 빈을 참조하면?
- 프로토타입 빈이 업데이트가 안되네...???
  - 싱글톤 빈을 통해서 프로토타입 빈을 조회하면 동일한 빈이 참조 된단 이야기.
- 업데이트 하려면, 여러가지 방법이 있지만 그중 하나. scoped-proxy를 쓰는 방법
  - scoped-proxy
    - 빈 선언부에 스코프 설정과 같이 함
```
@Bean
@Scope(value = "prototype", proxyMode = ScopedProxyMode.TARGET_CLASS)
public class Proto {
 
}
```
    - proxyMode를 설정해야함. default는 프록시를 사용하지 않는다는 옵션.
    - 빈에 적용해야하므로 ScopedProxyMode.TARGET_CLASS를 프록시 모드로 설정한다.
    - 이 설정은, 클래스기반의 프록시로 감싸서 빈으로 등록하고, 다른 빈들이 사용할 때 프록시로 감싼 빈을 사용하게 하라는 설정이다.
    - 이렇게 하지 않으면, 프로토타입 빈을 바꿔줄 여지가 없다.
    - 싱글톤 빈에서 프로토타입 빈을 사용하려면 이와 같은 설정을 하고, 싱글톤 빈이 프록시로 감싸진 빈을 참조하게 해서 매번 다른 빈을 참조하게 해야한다.
  - Object-Provider
    - 소스 코드에 침투함.
  - Provider(표준)
싱글톤 객체 사용시 주의할 점
- 필드가 공유된다.
- 멀티스레드 환경에서 빈의 필드를 변경하려고 하기때문에 스레드 세이프한 코딩이 필수적이다.
- 모든 싱글톤 빈들은 ApplicationContext 초기 구동시 인스턴스가 생성된다.

Reference

https://spring.io/projects/spring-framework
스프링 프레임워크 핵심 기술 - 백기선

[Spring Boot] Spring REST Client

nroo — Fri, 5 Jul 2019 10:21:24 +0900

스프링 REST 클라이언트

스프링 부트가 REST 클라이언트 관련해서 직접적으로 기능을 제공하는 것은 아니다. REST 클라이언트는 Spring Framework에서 제공하는 것이고, 부트는 그걸 쉽게 사용할 수 있도록 빈을 등록해준다.

주의 할 것은 RestTemplate과 WebClient 두 타입의 빈을 등록해주는 것이 아니라, 빌더를 등록해준다. 그래서 우리는 빌더를 주입받아서 필요할 때마다 REST 클라이언트를 빌드해서 사용해야한다.

RestTemplate과 WebClient

REST 클라이언트를 사용하는데에 두가지 선택사항이 있다. 차이점은 아래와 같다.

RestTemplate

Blocking I/O 기반의 Synchronous API

Blocking I/O 기반의 Synchronous 개념을 이해하기 위한 예제 코드

https://github.com/namjunemy/spring-boot-concept-and-utilization/commit/d2297945ffd022c912118af8aabca2738c894d0f
RestRunner에서 hi API를 호출한 뒤, Blocking 되므로 해당 메서드가 끝나기 전까지 다음 라인이 실행되지 않는다.
따라서 두개의 API를 호출하고 시간을 찍어보면 약 8초가 나온다.

@RestController
public class RestClientController {

    @GetMapping("/hi")
    public String hi() throws InterruptedException {
        Thread.sleep(5000L);
        return "hi";
    }

    @GetMapping("/bye")
    public String bye() throws InterruptedException {
        Thread.sleep(3000L);
        return "bye";
    }
}

@Slf4j
@Component
public class RestRunner implements ApplicationRunner {

    @Autowired
    RestTemplateBuilder restTemplateBuilder;

    @Override
    public void run(ApplicationArguments args) throws Exception {
        RestTemplate restTemplate = restTemplateBuilder.build();

        StopWatch stopWatch = new StopWatch();
        stopWatch.start();

        String hiResult = restTemplate.getForObject("http://localhost:8080/hi", String.class);
        log.info("/hi API Result : " + hiResult);

        String byeResult = restTemplate.getForObject("http://localhost:8080/bye", String.class);
        log.info("/bye API Result : " + byeResult);

        stopWatch.stop();
        log.info(stopWatch.prettyPrint());
    }
}

2019-06-30 17:17:52.271  INFO 37526 --- [           main] i.n.s.restclient.RestRunner              : /hi API Result : hi
2019-06-30 17:17:55.280  INFO 37526 --- [           main] i.n.s.restclient.RestRunner              : /bye API Result : bye
2019-06-30 17:17:55.281  INFO 37526 --- [           main] i.n.s.restclient.RestRunner              : StopWatch '': running time (millis) = 8425
-----------------------------------------
ms     %     Task name
-----------------------------------------
08425  100%

RestTemplateAutoConfiguration.class 설정 클래스 내부

프로젝트에 spring-web 모듈이 있다면 RestTemplateBuilder를 빈으로 등록해준다.

@Configuration
@AutoConfigureAfter(HttpMessageConvertersAutoConfiguration.class)
@ConditionalOnClass(RestTemplate.class)
public class RestTemplateAutoConfiguration {

    private final ObjectProvider<HttpMessageConverters> messageConverters;

    private final ObjectProvider<RestTemplateCustomizer> restTemplateCustomizers;

    public RestTemplateAutoConfiguration(
        ObjectProvider<HttpMessageConverters> messageConverters,
        ObjectProvider<RestTemplateCustomizer> restTemplateCustomizers) {
        this.messageConverters = messageConverters;
        this.restTemplateCustomizers = restTemplateCustomizers;
    }

    @Bean
    @ConditionalOnMissingBean
    public RestTemplateBuilder restTemplateBuilder() {
        RestTemplateBuilder builder = new RestTemplateBuilder();
        HttpMessageConverters converters = this.messageConverters.getIfUnique();
        if (converters != null) {
            builder = builder.messageConverters(converters.getConverters());
        }

        List<RestTemplateCustomizer> customizers = this.restTemplateCustomizers
            .orderedStream().collect(Collectors.toList());
        if (!CollectionUtils.isEmpty(customizers)) {
            builder = builder.customizers(customizers);
        }
        return builder;
    }
}

https://docs.spring.io/spring/docs/current/spring-framework-reference/integration.html#rest-client-access

WebClient

WebClientAutoConfiguration
프로젝트에 spring-webflux 모듈이 있다면 WebClient.Builder를 빈으로 등록해준다.
- 가장 쉬운 방법은 spring-boot-starter-webflux를 의존성에 추가하는 방법이다.

Non-Blocking I/O 기반의 Asynchronous API

개념을 이해하기 위한 예제 코드(컨트롤러는 위와 동일)

https://github.com/namjunemy/spring-boot-concept-and-utilization/commit/08fcec6bfcaaa0cb812d3d45e6a36297e6a6a136
WebClient로 부터 Mono를 만드는 라인은 Blocking되지 않는다. 실제로 subscribe가 일어날 때 요청해서 String객체를 파싱하는 동작을 한다. 이 동작도 Non-Blocking으로 동작한다. 단지, Asynchronous하게 응답이 오면 subscribe의 콜백함수가 동작을 하게 된다. 호출만 되고 밑라인을 수행한다.
그렇기 때문에, 늦게 호출한 /bye 에 대한 동작이 3초밖에 소요되지 않으므로 먼저 끝나서 로그로 찍히고, 뒤에 5초가 소요되는 /hi 의 로그가 찍힌다.
총 소요시간은 5초밖에 되지 않는다.

@Slf4j
@Component
public class RestRunner implements ApplicationRunner {

    @Autowired
    WebClient.Builder builder;

    @Override
    public void run(ApplicationArguments args) throws Exception {
        WebClient webClient = builder.build();

        StopWatch stopWatch = new StopWatch();
        stopWatch.start();

        // 이 라인이 실행되도 아무런 동작을 하지 않는다.
        Mono<String> hiMono = webClient.get().uri("http://localhost:8080/hi")
            .retrieve()
            .bodyToMono(String.class);

        // subscribe를 해줘야 스트리밍이 일어난다.
        hiMono.subscribe(hiResult -> {
            log.info("/hi API Result : " + hiResult);

            // Asynchronus 이므로 어느것이 먼저 끝날지 모른다. 스탑워치가 돌고있으면 멈추고,
            if (stopWatch.isRunning()) {
                stopWatch.stop();
            }

            // 로그를 찍고, 스탑워치를 다시 돌려줘야 한다. Asynchronus 이므로 순서보장이 안되기 때문에.
            log.info(stopWatch.prettyPrint());
            stopWatch.start();
        });

        Mono<String> byeMono = webClient.get().uri("http://localhost:8080/bye")
            .retrieve()
            .bodyToMono(String.class);

        byeMono.subscribe(byeResult -> {
            log.info("/bye API Result : " + byeResult);

            if (stopWatch.isRunning()) {
                stopWatch.stop();
            }

            log.info(stopWatch.prettyPrint());
            stopWatch.start();
        });
    }
}

2019-06-30 17:39:27.124  INFO 39877 --- [ctor-http-nio-2] i.n.s.restclient.RestRunner              : /bye API Result : bye
2019-06-30 17:39:27.125  INFO 39877 --- [ctor-http-nio-2] i.n.s.restclient.RestRunner              : StopWatch '': running time (millis) = 3375
-----------------------------------------
ms     %     Task name
-----------------------------------------
03375  100%  

2019-06-30 17:39:29.064  INFO 39877 --- [ctor-http-nio-4] i.n.s.restclient.RestRunner              : /hi API Result : hi
2019-06-30 17:39:29.065  INFO 39877 --- [ctor-http-nio-4] i.n.s.restclient.RestRunner              : StopWatch '': running time (millis) = 5314
-----------------------------------------
ms     %     Task name
-----------------------------------------
03375  064%  
01939  036%

https://docs.spring.io/spring/docs/current/spring-framework-reference/web-reactive.html#webflux-client

REST 클라이언트 커스터마이징

RestTemplate
- 기본으로 java.net.HttpURLConnection 사용
- 커스터마이징
  - 로컬 커스터마이징
    - 로컬에서 정의 후 안에서만 사용
  - 글로벌 커스터마이징
    - RestTemplate이 기본적으로 사용하는 java.net.HttpURLConnection를 HttpClient로 사용해야 하는 상황이 있을 수 있다.
    - 먼저 HttpClient를 빈으로 만들기 위해서 의존성에 추가한다.
    - 그리고 RestTemplateCustomizer를 빈으로 등록해서 전역 사용한다.
    - 커스터마이저 안에서 restTemplate.setRequestFactory()로 맞는 구현체를 등록한다.(이것 역시 Spring의 PSA(Portable Service Abstraction)가 잘 적용 되어있다.)
    - 이렇게 되면 더이상 기본 커넥션이 아닌, apache에서 제공하는 org.apache.http.client.HttpClient를 RestTemplate이 사용하게 된다.
```
@Bean
public RestTemplateCustomizer restTemplateCustomizer() {
  return new RestTemplateCustomizer() {
    @Override
    public void customize(RestTemplate restTemplate) {
      restTemplate.setRequestFactory(new HttpComponentsClientHttpRequestFactory());
    }
  };
}
```
    - 빈 재정의

WebClient

기본으로 Reactor Netty의 HTTP 클라이언트 사용

커스터마이징

로컬 커스터마이징

WebClient webClient = builder
  .baseUrl("http://localhost:8080")
  .build();

...
  
Mono<String> hiMono = webClient.get().uri("/hi")
  .retrieve()
  .bodyToMono(String.class);

...

Mono<String> byeMono = webClient.get().uri("/bye")
  .retrieve()
  .bodyToMono(String.class);

글로벌 커스터마이징
- WebClientCustomizer를 빈으로 등록해서 전역 사용
  - 빈으로 등록해 놓고, 사용하는 쪽에서는 build()만 해서 사용
```
@Bean
public WebClientCustomizer webClientCustomizer() {
  return webClientBuilder -> webClientBuilder.baseUrl("http://localhost:8080");
}
```
- 또는 빈 재정의 해서 사용해도 됨.

Reference

[Spring Boot] Spring Security 자동 설정과 커스터마이징

nroo — Fri, 5 Jul 2019 10:21:04 +0900

스프링 시큐리티

웹 시큐리티
메소드 시큐리티
다양한 인증 방법 지원
- LDAP, 폼 인증, Basic 인증, OAuth, ...

1. 스프링 부트 시큐리티 자동 설정

spring-boot-starter-security

SecurityAutoConfiguration.class 설정파일 참조

스프링 시큐리티가 의존성으로 등록되어 있으면,

DefaultAuthenticationEventPublisher가 @Bean으로 등록된다.

@Configuration
@ConditionalOnClass(DefaultAuthenticationEventPublisher.class)
@EnableConfigurationProperties(SecurityProperties.class)
@Import({SpringBootWebSecurityConfiguration.class, WebSecurityEnablerConfiguration.class,
    SecurityDataConfiguration.class})
public class SecurityAutoConfiguration {

    @Bean
    @ConditionalOnMissingBean(AuthenticationEventPublisher.class)
    public DefaultAuthenticationEventPublisher authenticationEventPublisher(
        ApplicationEventPublisher publisher) {
        return new DefaultAuthenticationEventPublisher(publisher);
    }

}

이 이벤트 퍼블리셔는
- BadCredentialsException
- UsernameNotFoundException
- AccountExpiredException
- 등의

이벤트를 매핑해서 발생시켜 준다. => 인증 관련 각종 이벤트 발생

DefaultAuthenticationEventPublisher.java

그러면 우리는 이벤트 에러 핸들러를 등록해서 유저의 상태를 변경하는 등의 특정 동작을 수행할 수 있다.

...
  
public DefaultAuthenticationEventPublisher(ApplicationEventPublisher applicationEventPublisher) {
  this.applicationEventPublisher = applicationEventPublisher;

  addMapping(BadCredentialsException.class.getName(),
             AuthenticationFailureBadCredentialsEvent.class);
  addMapping(UsernameNotFoundException.class.getName(),
             AuthenticationFailureBadCredentialsEvent.class);
  addMapping(AccountExpiredException.class.getName(),
             AuthenticationFailureExpiredEvent.class);
  addMapping(ProviderNotFoundException.class.getName(),
             AuthenticationFailureProviderNotFoundEvent.class);
  addMapping(DisabledException.class.getName(),
             AuthenticationFailureDisabledEvent.class);
  addMapping(LockedException.class.getName(),
             AuthenticationFailureLockedEvent.class);
  addMapping(AuthenticationServiceException.class.getName(),
             AuthenticationFailureServiceExceptionEvent.class);
  addMapping(CredentialsExpiredException.class.getName(),
             AuthenticationFailureCredentialsExpiredEvent.class);
  addMapping(
    "org.springframework.security.authentication.cas.ProxyUntrustedException",
    AuthenticationFailureProxyUntrustedEvent.class);
}

...

스프링 부트의 시큐리티 설정파일인 SpringBootWebSecurityConfiguration.class를 보면,

WebSecurityConfigurerAdapter를 상속받아서 그대로 사용하고 있다.

/**
 * The default configuration for web security. It relies on Spring Security's
 * content-negotiation strategy to determine what sort of authentication to use. If the
 * user specifies their own {@link WebSecurityConfigurerAdapter}, this will back-off
 * completely and the users should specify all the bits that they want to configure as
 * part of the custom security configuration.
 *
 * @author Madhura Bhave
 * @since 2.0.0
 */
@Configuration
@ConditionalOnClass(WebSecurityConfigurerAdapter.class)
@ConditionalOnMissingBean(WebSecurityConfigurerAdapter.class)
@ConditionalOnWebApplication(type = Type.SERVLET)
public class SpringBootWebSecurityConfiguration {

    @Configuration
    @Order(SecurityProperties.BASIC_AUTH_ORDER)
    static class DefaultConfigurerAdapter extends WebSecurityConfigurerAdapter {

    }

}

스프링 시큐리티가 제공하는 기본설정을 그대로 쓴다는 의미가 된다.
- @ConditionalOnMissingBean(WebSecurityConfigurerAdapter.class)가 의미하는 것은
- 만약, WebSecurityConfigurerAdapter.class 를 상속받은 빈을 만들면
- 커스텀하게 우리의 시큐리티 설정을 가져갈 수 있다는 이야기가 된다.
WebSecurityConfigurerAdapter.class 안에서 특히 configure() 메서드를 보면,
- 기본적으로 사용자 인증이 된 요청에 대해서만 요청을 허용하고.
- 로그인 폼과, HttpBasic을 사용하도록 되어 있는것을 볼 수 있다.
  - formLogin - 사용자가 폼기반 로그인으로 인증 할 수 있다.
  - httpBasic - 사용자가 Http기반 인증으로 인증 할 수 있다.

우리가 부트에서 시큐리티 스타터를 등록만 했는데 모든 인증 없는 컨트롤러 테스트가 깨지고, 웹에선 로그인 페이지로 리다이렉트 되는 이유가 여기에 있다.

...
protected void configure(HttpSecurity http) throws Exception {
  logger.debug("Using default configure(HttpSecurity). If subclassed this will potentially override subclass configure(HttpSecurity).");
  
  http
    .authorizeRequests()
    .anyRequest().authenticated()
    .and()
    .formLogin().and()
    .httpBasic();
}
...

부트에서 시큐리티 스타터 의존성을 추가하고, application을 run하면 아래와 같은 로그가 찍힌다.

2019-06-28 14:45:37.001  INFO 18612 --- [  main] .s.s.UserDetailsServiceAutoConfiguration : 

Using generated security password: 960d55de-dd62-415c-b7ff-8f5083e78498

spring-boot-autoconfigure의 security쪽 자동 설정중 하나인 UserDetailsServiceAutoConfiguration의 역할이다.

코드를 보면

@ConditionalOnMissingBean({ AuthenticationManager.class, AuthenticationProvider.class, UserDetailsService.class }) 에 의해서 3개의 클래스가 없을때 아래의 설정 파일이 적용되고,
inMemoryUserDetailsManager() 에 의해서 인메모리로 UserDetailsManager를 만들어서, 랜덤하게 유저가 만들어지게 된다.
만약, UserDetailsService.class를 상속받아서 재정의하거나 하면 랜덤 유저는 생성되지 않는다.

@Configuration
@ConditionalOnClass(AuthenticationManager.class)
@ConditionalOnBean(ObjectPostProcessor.class)
@ConditionalOnMissingBean({AuthenticationManager.class, AuthenticationProvider.class,
    UserDetailsService.class})
public class UserDetailsServiceAutoConfiguration {

    private static final String NOOP_PASSWORD_PREFIX = "{noop}";

    private static final Pattern PASSWORD_ALGORITHM_PATTERN = Pattern
        .compile("^\\{.+}.*$");

    private static final Log logger = LogFactory
        .getLog(UserDetailsServiceAutoConfiguration.class);

    @Bean
    @ConditionalOnMissingBean(type = "org.springframework.security.oauth2.client.registration.ClientRegistrationRepository")
    @Lazy
    public InMemoryUserDetailsManager inMemoryUserDetailsManager(
        SecurityProperties properties,
        ObjectProvider<PasswordEncoder> passwordEncoder) {
        SecurityProperties.User user = properties.getUser();
        List<String> roles = user.getRoles();
        return new InMemoryUserDetailsManager(User.withUsername(user.getName())
            .password(getOrDeducePassword(user, passwordEncoder.getIfAvailable()))
            .roles(StringUtils.toStringArray(roles)).build());
    }

    private String getOrDeducePassword(SecurityProperties.User user,
        PasswordEncoder encoder) {
        String password = user.getPassword();
        if (user.isPasswordGenerated()) {
            logger.info(String.format("%n%nUsing generated security password: %s%n",
                user.getPassword()));
        }
        if (encoder != null || PASSWORD_ALGORITHM_PATTERN.matcher(password).matches()) {
            return password;
        }
        return NOOP_PASSWORD_PREFIX + password;
    }

}

commit log

2 시큐리티 설정 커스터마이징

1 - 웹 시큐리티 설정

6.1에서 설명했던것 처럼 SpringBootWebSecurityConfiguration는 WebSecurityConfigurerAdapter가 빈으로 등록되어 있지 않을 경우에 등록된다.
따라서, 아래와 같이 WebSecurityConfigurerAdapter를 상속받은 커스텀 설정을 빈으로 등록하면 스프링 부트의 기본 시큐리티 설정은 사용하지 않게 된다.
- "/", "/hello"는 모든 사용자에게 허용하고,
- 그 외의 요청은 인증이 필요하도록 설정하는 코드이다.

@Configuration
public class WebSecurityConfig extends WebSecurityConfigurerAdapter {

    @Override
    protected void configure(HttpSecurity http) throws Exception {
        http.authorizeRequests()
            .antMatchers("/", "/hello").permitAll()
            .anyRequest().authenticated()
            .and()
            .formLogin()
            .and()
            .httpBasic();
    }
}

2 - UserDetailsService 구현

https://docs.spring.io/spring-security/site/docs/current/reference/htmlsingle/#jc-authentication-userdetailsservice
스프링 시큐리티가 랜덤생성해주는 유저 말고, 우리가 원하는 유저로 인증
보통 Account를 관리하는 서비스 계층에서 UserDetailsService를 implements 한다.
UserDetailsService 타입의 빈이 등록이 되어있어야지 부트가 기본으로 생성해주는 유저가 더 이상 등록되지 않는다.

password 검증을 위해서 passwordEncoder가 꼭 필요하다.

스프링 시큐리티에서 권장하는 인코더를 시큐리티 설정에 빈으로 등록해주면 된다.

https://docs.spring.io/spring-security/site/docs/current/reference/htmlsingle/#core-services-password-encodin

@Configuration
public class WebSecurityConfig extends WebSecurityConfigurerAdapter {

    @Override
    protected void configure(HttpSecurity http) throws Exception {
        http.authorizeRequests()
            .antMatchers("/", "/hello").permitAll()
            .anyRequest().authenticated()
            .and()
            .formLogin()
            .and()
            .httpBasic();
    }

    @Bean
    public PasswordEncoder passwordEncoder() {
        return PasswordEncoderFactories.createDelegatingPasswordEncoder();
    }
}

AccountService.class

@Service
@RequiredArgsConstructor
public class AccountService implements UserDetailsService {

    private final AccountRepository accountRepository;
    private final PasswordEncoder passwordEncoder;

    public Account createAccount(String username, String password) {
        Account account = new Account();
        account.setUsername(username);
        account.setPassword(passwordEncoder.encode(password));
        return accountRepository.save(account);
    }

    @Override
    public UserDetails loadUserByUsername(String username) throws UsernameNotFoundException {
        Account account = accountRepository.findByUsername(username)
            .orElseThrow(() -> new UsernameNotFoundException(username));

        return new User(account.getUsername(), account.getPassword(), authorities());
    }

    private Collection<? extends GrantedAuthority> authorities() {
        return Arrays.asList(new SimpleGrantedAuthority("ROLE_USER"));
    }
}

commit log

Reference

[JPA] Spring Data JPA와 QueryDSL 이해, 실무 경험 공유

nroo — Tue, 30 Apr 2019 00:19:34 +0900

Spring Data JPA와 QueryDSL

JPA 기반 프로젝트
Spring Data JPA
QueryDSL

Spring Data JPA

지루하게 반복되는 CRUD 문제를 세련된 방법으로 해결
개발자는 인터페이스만 작성한다
스프링 데이터 JPA가 구현 객체를 동적으로 생성해서 주입

스프링 데이터 JPA 적용 전

public class MemberRepository {
    public void save(Member member) {...}
    public Member findOne(Long id) {...}
    public List<Member> findAll() {...}
    
    public Member findByUsername(String username) {...}
}

public class ItemRepository {
    public void save(Item item) {...}
    public Item one(Long id) {...}
    public List<Item> findAll() {...}
}

스프링 데이터 JPA 적용 후
- 스프링 데이터 JPA에서는 JpaRepository 인터페이스를 제공한다.
- 우리가 상상할 수 있는 모든 API를 모두 처리한다.
- 인터페이스가 인터페이스를 상속받을 때는 extends를 사용한다.
```
public interface MemberRepository extends JpaRepository<Member, Long> {
    Member findByUsername(String username);
}
```
```
public interface ItemRepository extends JpaRepository<Item, Long> {
    // 비어있음
}
```

스프링 데이터 JPA 적용 후 클래스 다이어그램

JpaRepository에서 엄청 많은 기능을 제공한다. 인터페이스 상속 받아서 사용하면 된다.
기본적으로 CRUD를 구현하지 않아도 된다. 인터페이스 호출해서 쓸 수 있다.
스프링 로딩 시점에 MemberRepository와 ItemRepository의 구현체를 만든다.

공통 인터페이스 기능

JpaRepository 인터페이스: 공통 CRUD 제공
제네릭은 <엔티티, 식별자>로 설정한다.
스프링에 스프링 데이터 프로젝트와 스프링 데이터 JPA프로젝트가 따로 존재한다.
스프링 데이터 프로젝트에 공통적인 기능을 가지고 있고, JPA 특화된 기능을 스프링 데이터 JPA 프로젝트에서 가지고 있다.

쿼리 메서드 기능

위에서 스프링 데이터 JPA 적용 전의 코드를 보면 findByUsername() 메서드가 있다.
JpaRepository만으로 이걸 어떻게 처리하나?
이를 위해 쿼리 메서드라는 엄청난 기능이 존재한다.
메서드 이름으로 쿼리를 생성한다. @Query 어노테이션으로 쿼리를 직접 정의할 수 있다.

메서드 이름으로 쿼리 생성

메서드 이름만으로 JPQL 쿼리를 생성한다.
선언된 메서드에 대해서는 애플리케이션 로딩 시점에 쿼리를 다 만들어 버린다.

그래서 에러를 사전에 잡을 수 있다.

public interface MemberRepository extends JpaRepository<Member, Long> {
    List<Member> findByName(String username);
}

List<Member> member = memberRepository.findByName("hello")

// 실행된 SQL
SELECT * FROM MEMBER M WHERE M.NAME = "hello"

이름으로 검색 + 정렬

자주 쓰는 기능 정렬을 위해 Sort를 넣어줄 수 있다. 스프링 데이터에서 만들어 놨다.

public interface MemberRepository extends JpaRepository<Member, Long> {
    List<Member> findByName(String username, Sort sort);
}

// 실행된 SQL
SELECT * FROM MEMBER M WHERE M.NAME = "hello" ORDER BY AGE DESC

이름으로 검색 + 정렬 + 페이징

추가로 페이징을 위한 기능도 만들어 놨다.
실제로 사용할땐 꼭 DTO로 변환해서 뿌리자.
Page객체의 content에 데이터가 나오고,

Pageable, sort, first, empty등의 정보를 얻을 수 있다.

public interface MemberRepository extends JpaRepository<Member, Long> {
    Page<Member> findByName(String username, Pageable pageable);
}

// 예를 들어 이런식으로 사용할 수 있다.
@GetMapping("/hello")
public Page<Member> member() {
    PageRequest request = PageRequest.of(1, 10);
    return repository.findByName("hello1", request);
}

사용 예시

Pageable page = new PageRequest(1, 20, new Sort...);
Page<Member> result = memberRepository.findByName("hello", page);

//전체 수
int total = result.getTotalElements();

//데이터
List<Member> members = result.getContent();

전체 페이지 수, 다음 페이지 및 페이징을 위한 API 다 구현되어 있음

실행된 SQL 2가지

데이터 조회

SELECT *
FROM
    ( SELECT ROW_.*, ROWNUM ROWNUM_
      FROM
          ( SELECT M.*
            FROM MEMBER M WHERE M.NAME = 'hello'
            OEDER BY M.NAME
          ) ROW_
     WHERE ROWNUM <= ?
    )
WHERE ROWNUM_>?

전체 수 조회

SELECT COUNT(1) FROM MEMBER M WEHRE M.NAME = 'hello'

@Query, JPQL 정의

@Query 어노테이션을 사용해서 직접 JPQL을 지정할 수 있다.

마찬가지로 Named 쿼리도 애플리케이션 로딩 시점에 파싱을 하므로, 이로 인해 런타임 에러를 내지 않을 수 있다.

public interface MemberRepository extends JpaRepository<Member, Long> {
    
    @Query("select m from Member m where m.username = ?1")
    Member findByUsername(String username, Pageable pageable);
}

Web 페이징과 정렬 기능

컨트롤러에서 페이징 처리 객체를 바로 인젝션 받을 수 있다
page: 현재 페이지
size: 한 페이지에 노출할 데이터 건수
sort: 정렬 조건

/members?page=0&size=20&sort=name,desc

@RequestMapping(value = "/members", method = RequestMethod.GET)
String list(Pageable pageable, Model mobel) {}

QueryDSL

SQL, JPQL을 코드로 작성할 수 있도록 도와주는 빌더 API
JPA 크리테이라에 비해서 편리하고 실용적이다
오픈소스

SQL, JPQL의 문제점

SQL, JPQL은 문자열이다. Type-check가 불가능하다.
잘 해봐야 애플리케이션 로딩 시점에 알 수 있다. 컴파일 시점에 알 수 있는 방법이 없다. 자바와 문자열의 한계이다.
해당 로직 실행 전까지 작동여부 확인을 할 수 없다.
해당 쿼리 실행 시점에 오류를 발견한다.
```
SELECT * FROM MEMBERRR WHERE MEMBER_ID = '100'
```

QueryDSL 장점

문자가 아닌 코드로 작성하자
컴파일 시점에 문법 오류를 발견하자.
코드 자동완성(IDE 도움)
단순하고 쉽다. 코드 모양이 JPQL과 거의 비슷하다
동적 쿼리

QueryDSL - 동작원리 쿼리타입 생성

위의 장점을 실현하기 위해서 오픈 소스를 만들었다.
Member.java @Entity를 가지고, QMember.java라는 QueryDSL 전용 객체를 만들어 버린다.
세팅이 좀 힘들지만, 세팅을 하고나면 아래와 같이 사용할 수 있다.(gradle, maven 도움을 받아서)
엔티티 매니저를 JPAQueryFactory에 넣고,
QMember 객체를 가지고 아래와 같은 방식으로 쿼리를 코드로 짤 수 있다.

가장 큰 장점은 IDE의 도움을 받을 수 있다는 것과, 컴파일 타임에 오류를 잡아서 뭐리 때문에 실수를 할 일이 없다는 것이다.

//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.gt(18))
         .orderBy(m.name.desc())
         .fetch();

QueryDSL - 조인

JPAQueryFactory query = new JPAQueryFactory(em);
QMember m = QMember.member;
QTeam t = QTeam.team;

List<Member> list = 
    query.selectFrom(m)
         .join(m.team, t)
         .where(t.name.eq("teamA"))
         .fetch();

QueryDSL - 페이징 API

JPAFactoryQuery query = new JPAQueryFactory(em);
QMember m = QMember.member;

List<Member> list = 
    query.selectFrom(m)
         .where(m.age.gt(18))
         .orderBy(m.name.desc())
         .limit(10)                  // 페이징을 위해 limit, offset도 그냥 넣어줄 수 있다.
         .offset(10)
         .fetch();

QueryDSL - 동적 쿼리

사실 QueryDSL을 쓰는 진짜 이유는 동적 쿼리 때문이다.
JPQL은 정적 쿼리이다. 문자열을 더하기 해야하는데, 헬이다.
QueryDSL은 코드를 더하는 것이기 때문에, 그것 보다 수월하게 할 수 있다.
BooleanBuilder에 조건을 쭉쭉 넣고 쿼리를 실행시키면 된다. 더 자세히 공부해보자.
- 조건이 있으면 넣고, 없으면 안넣고 불린빌더만 가지고 동적 쿼리가 생성이 된다!!!

원하는 필드만 뽑아서 DTO로 뽑아내는 기능도 QueryDSL이 다 지원한다.

String name = "member";
int age = 9;

QMember m = QMember.member;

BooleanBuilder builder = new BooleanBuilder();
if(name != null) {
    builder.and(m.name.contains(name));
}
if(age != 0) {
    builder.and(m.age.gt(age));
}

List<Member> list = 
    query.selectFrom(m)
         .where(builder)
         .fetch();

QueryDSL - 이것은 자바다!

객체지향적인 관점에서 이 점이 가장 중요하다.

예를 들어 쿠폰의 상태와 마케팅 뷰 카운트를 체크하는 공통으로 사용되는 서비스 필수 제약 조건이 있다고 가정하자.

return query.selectFrom(coupon)
            .where(
                 coupon.type.eq(typeParam),
                 coupon.status.wq("LIVE"),
                 marketing.viewCount.lt(markting.maxCount)
       )
       .fetch();

자바다!!
그러므로 중복코드를 함수로 extract해서 재사용할 수 있다.

제약조건을 조립할 수가 있다.

extract method를 통해서 가독성과 재사용성을 확보하면서

쿼리를 코드로 리팩토링 할 수 있다.

return query.selectFrom(coupon)
            .where(
                 coupon.type.eq(typeParam),
                 isServiceable()
       )
       .fetch();

private BooleanExpression isServiceable() {
    return coupon.status.wq("LIVE")
        .and(marketing.viewCount.lt(markting.maxCount));
}

실무에서 JPA를 사용한다면, 스프링 데이터 JPA를 꼭 사용하자. QueryDSL도 꼭 사용하자.

실무 경험 공유

강의를 진행해주신 김영한님의 실무 경험 입니다.

수 조 단위의 정산을 하는데, JPA로 다 처리한다.
크리티컬한 결제 같은 시스템도 JPA로 다 처리한다. SpringBoot + JPA + QueryDSL 기본으로 깔고 간다.
JPA로 실무를 하다 보면, 테이블 중심에서 객체 중심으로 개발 패러다임이 변화된다.
유연한 데이터베이스 변경의 장점과 테스트
- Junit 통합 테스트시에 H2 DB 메모리 모드로 돌려서 사용한다.
- 로컬 PC에는 H2 DB 서버 모드로 실행한다.
- 개발 운영은 MySQL, Oracle로 한다.
- 데이터베이스 방언을 설정만 바꾸면 가능한 일이다.
데이터베이스 변경 경험(개발 도중 MySQL -> Oracle로 바뀐적도 있다.)
테스트, 통합 테스트시에 CRUD를 믿고 간다.(내가 짠 쿼리는 그것 마저 테스트를 거쳐 가야 한다.)
- 이런거 테스트 할 시간에 CRUD 믿고, 핵심 비즈니스 테스트 코드를 열심히 짜자.
빠르게 에러를 발견할 수 있다.
- 쿼리 때문에 문제가 발생한적이 한번도 없다.
- 컴파일 시점에 대부분 오류를 발견할 수 있다.
- 늦어도 애플리케이션 로딩 시점에 발견한다.
- 최소한 뭐리 문법 실수나 오류는 거의 발생하지 않는다.
대부분이 비즈니스 로직의 오류이다.

성능

JPA 자체로 인한 성능 저하 이슈는 거의 없다.
성능 이슈 대부분은 JPA를 잘 이해하지 못해서 발생한다.
- 즉시로딩: 쿼리가 튄다. -> 지연 로딩을 변경한다.
  - 어노테이션 수정으로 바로 적용 된다.
- N + 1 문제 -> 대부분 페치 조인으로 문제를 해결한다.
  - 이 부분, 이부분 페치 조인으로 바꾸자. SQL 베이스로 프로젝트를 짰다면 갈아 엎어야 한다.
- 하나의 쿼리에 집중해서 성능을 고민하는게 아니라, JPA를 사용해서 빠르게 개발한 다음에
- 실제 성능 테스트를 진행하고, 병목이 발생하는 구간들을 찾아서 설정을 빠르게 변경하고 다시 반복해서 성능 테스트 할 수 있다.

생산성

단순 코딩 시간이 줄어든다. -> 개발 생산성이 향상 된다. -> 잉여 시간이 발생한다.
비즈니스 로직 작성시 흐름이 끊기지 않는다.
- SQL 중심으로 개발하다 보면, 비즈니스 로직 자바로 짜다가 머리의 컨텍스트가 SQL로 스위칭 된다.
- 다시 자바로 온다, 다시 SQL로 간다. 병목 발생하고 커피마시러 간다. 야근한다.
남는 시간에 더 많은 테스트를 작성하고
- 순수 자바 코드가 많아져서 테스트 코드 만들기에 용이하다.
남는 시간에 기술 공부를 하고
남는 시간에 코드에 금칠을 하고
팀원 대부분은 다시는 과거로 돌아가고 싶어하지 않는다.
이 얘기는 JPA를 잘 공부하고, 잘 알고 프로젝트를 진행 했을 경우 이야기이다. 대부분 잘 모르고 진행하면 JPA를 원망한다.

많이 하는 질문

ORM 프레임워크를 사용하면 SQL과 데이터베이스는 잘 몰라도 되나요?
- 더 잘 알아야 한다. SQL과 DB를 모르고 ORM을 사용하는건 말이 안된다. 객체와 DB를 잘 알고 그것을 더 편하게 사용하려고 ORM을 사용하는 것이다. 결국 둘 다 잘해야 된다.
성능이 느리지 않나요?
- 잘 쓰면 최적화 할 수 있는 포인트가 더 많다.
통계 쿼리처럼 매우 복잡한 SQL은 어떻게 하나요?
- 거의 다 QueryDSL로 처리하고, DTO로 뽑아낸다.
- 정말 안될 경우 네이티브 쿼리 사용한다.
MyBatis와 어떤 차이가 있나요?
- JPA를 사용하면서 같이 써도 된다. 다만, flush 같은 이슈 처리들을 잘 고려 해야 한다.
- MyBatis는 쿼리를 직접 다 짜야 하지 않나.
하이버네이트 프레임워크를 신뢰할 수 있나요?
- 쿠팡, 배민 거래량이 조단위로 들어가는 회사들에서 기본으로 JPA 깔고 간다.
제 주위에는 MyBatis(iBatis, myBatis)만 사용하는데요?
- 주변에 JPA 할 줄 아는 사람이 있어야 같이 적용하지, 사실 쿼리중심으로 개발하는 지금의 SI에서는 힘들다.
학습 곡선이 높다고 하던데요?
- 일주일 공부하고 평생 시간 아끼자.
- 어려운 포인트는 찾아서 딥하게 공부하자.
- 시간이 절약되는 만큼 비즈니스 로직을 고민할 수 있는 시간이 늘어난다.

팀 서버 기술 스택

Java8
Spring Frmework(SpringBoot default)
JPA, Hibername
Spring Data JPA
QueryDSL
Junit, Spock(Test)

Reference

자바 ORM 표준 JPA 프로그래밍
저자 직강 - https://www.youtube.com/watch?v=WfrSN9Z7MiA&list=PL9mhQYIlKEhfpMVndI23RwWTL9-VL-B7U

[JPA] 객체지향 쿼리, JPQL

nroo — Fri, 26 Apr 2019 19:45:16 +0900

JPA 객체지향 쿼리

연관관계 매핑과 영속성 컨텍스트 등 앞의 내용들로 기본기를 다졌고, 지금부터는 활용 단계이다.

JPA와 객체지향 쿼리
QueryDSL

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

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

JPQL 소개

Java Persistence Query Language
가장 단순한 조회 방법
- EntityManager.find()
- 객체 그래프 탐색
  - (a.getB().getC())로 get get get 하면서 계속 찾아다닐 수 없다.
나이가 18살 이상인 회원을 모두 검색하고 싶다면?

JPQL

JPA를 사용하면 엔티티 객체를 중심으로 개발
문제는 검색 쿼리
검색을 할 때도 테이블이 아닌 엔티티 객체를 대상으로 검색을 해야한다.
- DB를 몰라야 한다. 자바 코드에서 멤버 테이블이 있구나 보다, 멤버 객체가 있구나라고 생각을 가지고 개발해야 한다.
근데, 모든 DB 데이터를 객체로 변환해서 검색하는 것은 불가능하다.
애플리케이션이 필요한 데이터만 DB에서 불러오려면 결국 검색 조건이 포함된 SQL이 필요하다.
그래서 JPA는 SQL을 추상화한 JPQL이라는 객체 지향 쿼리 언어를 제공한다.
SQL과 문법이 유사하고, SELECT, FROM, WHERE, GROUP BY, HAVING, JOIN등을 지원한다.
JPQL은 엔티티 객체를 대상으로 쿼리를 질의하고
SQL은 데이터베이스 테이블을 대상으로 쿼리를 질의한다.

ex)

//검색
String jpql= "select m From Member m where m.name like '%hello%'";

List<Member> result = em.createQuery(jpql, Member.class).getResultList();

위의 JPQL에 의해 변환되어(데이터베이스 방언을 참조해서 DB에 맞는 쿼리로) 실행된 SQL

select
    m.id as id,
    m.age as age,
    m.USERNAME as USERNAME,
    m.TEAM_ID as TEAM_ID
from
    Member m
where
    m.age>18

테이블이 아닌 객체를 대상으로 검색하는 객체지향 쿼리라고 이해하면 되며,
SQL을 추상화해서 특정 데이터베이스 SQL에 의존하지 않는다.
JPQL을 한마디로 정의하면 객체 지향 SQL 이다.

JPQL 문법

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

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

몇가지 유의 사항은 존재 한다.
- from절에 들어가는 것은 객체다!
  select m from Member m where m.age > 8
- 엔티티와 속성은 대소문자를 구분
  - 예를 들면, Member 엔티티와 username 필드
- JPQL 키워드는 대소문자 구분 안함
  - SELECT, FROM, where
- 엔티티 이름을 사용한다. 테이블 이름이 아니다
  - 엔티티명 Member
- 별칭은 필수이다.
  - Member의 별칭 m

결과 조회 API

query.getResultList()
- 결과가 하나 이상인 경우, 리스트를 반환한다.
query.getSingleResult()
- 결과가 정확히 하나, 단일 객체를 반환한다.(정확히 하나가 아니면 예외 발생)

파라미터 바인딩

웬만하면 이름으로 바인딩하자.

이름 기준

SELECT m 
FROM Member m
where m.username=:username

query.setParameter("username", usernameParam);

위치 기준

SELECT m
FROM Member m
where m.username=?1

query.setParameter(1, usernameParam);

프로젝션

엔티티 프로젝션(멤버 조회)
- SELECT m FROM Member m ...
엔티티 프로젝션(멤버 안에 있는 팀 조회)
- SELECT m.team FROM Member m ...
단순 값 프로젝션
- hibernate에서 지원을 해서 username, age로 쓸 수 있지만
- 공식적으로는 m.username, m.age로 접근해야 한다.
- SELECT m.username, m.age FROM Member m ...
new 명령어
- 단순 값을 DTO로 바로 조회 한다.
- new 패키지명, DTO를 넣고 생성자처럼 사용해서 DTO로 바로 반환 받을 수 있다.
- SELECT new jpabook.jpql.UserDTO(m.username, m.age) FROM Member m ...
DISTINCT는 중복을 제거 한다.

페이징 API

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

페이징 쿼리 예시)

String jpql = "select m from Member m order by m.name desc";

List<Member> resultList = em.createQuery(jpql, Member.class)
  .setFirstResult(10)
  .setMaxResult(20)
  .getResultList();

모든 데이터 베이스의 방언이 동작한다.

위 쿼리의 MySQL 방언

SELECT
    M.ID AS ID,
    M.AGE AS AGE,
    M.TEAM_ID AS TEAM_ID,
    M.NAME AS NAME
FROM
    MEMBER M
ORDER BY
    M.name DESC LIMIT ?, ?

위 쿼리의 Oracle 방언

SELECT * FROM
    ( SELECT ROW_.*, ROWNUM ROWNUM_
    FROM
        ( SELECT
            M.ID AS ID,
            M.AGE AS AGE,
            M.TEAM_ID AS TEAM_ID,
            M.NAME AS NAME
          FROM MEMBER M
          ORDER BY M.NAME
         ) ROW_
     WHERE ROWNUM <= ?
     )
WHERE ROWNUM_ > ?

집합과 정렬

기본적인 집합 명령어 다 동작 한다.

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

GROUP BY, HAVING
ORDER BY

조인

내부 조인
- 멤버 내부의 팀에 m.team으로 접근
```
SELECT m
FROM Member m
[INNER] JOIN m.team t
```

외부 조인

SELECT m
FROM MEMBER m
LEFT [OUTER] JOIN m.team t

세타 조인
- 일명 막(?) 조인이다. 연관관계 상관 없이 유저명과 팀의이름이 같은 경우 찾아라 라는 쿼리 날릴 수 있다. 이런 조인을 세타 조인이라고 한다.
```
SELECT COUNT(m)
FROM Member m, Team t
WHERE m.username = t.name
```
참고:
- 하이버네이트 5.1부터 세타 조인도 외부 조인이 가능!

페치 조인

현업에서 굉장히 많이 쓰인다. fetchType을 LAZY로 다 세팅 해놓고, 쿼리 튜닝할때 한꺼 번에 조회가 필요한 경우 페치 조인을 사용한다.
엔티티 객체 그래프를 한번에 조회하는 방법이다.
별칭을 사용할 수 없다.
JPQL
- 멤버를 조회할 때, 팀까지 같이 조회한다.
```
select m from Member m join fetch m.team
```

SQL

SELECT M.*, T.*
FROM MEMBER T
INNER JOIN TEAM T ON M.TEAM_ID = T.ID

최근에(jpa2.1)는 페치 조인 말고 엔티티 그래프라는 기능이 있다. 공부해보자.

페치 조인 예시)

String jpql = "select m from Member m join fetch m.team";

List<Member> members = em.createQuery(jpql, Member.class).getResultList();

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

현업에서 많이 쓰이는 이유는, 리스트 쭉 뿌릴때. LAZY로 가게 되면 리스트에서 반복문으로 정보 받아올 때마다 DB에 쿼리가 나간다. 이게 JPA N+1 문제이다. 성능상 좋지 않다.
- 리스트가 10명이다. 10명의 리스트를 가져오는 쿼리 한방 나가는데, 세부 조회를 할 때마다(10번) Lazy 로딩 되므로 쿼리가 총 11번 나가게 된다.
- JPA N+1 문제와 해결방안

기타

서브 쿼리 지원
EXISTS, IN
BETWEEN, LIKE, IS NULL

JPQL 기본 함수

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

CASE 식

기본 CASE 식

select
    case when m.age <= 10 then '학생요금'
         when m.age >= 60 then '경로요금'
         else '일반요금'
    end
from Member m

단순 CASE 식

select
    case t.name
      when '팀A' then '인센티브110%'
      when '팀B' then '인센티브120%'
      else '인센티브105%'
    end
from Team t

사용자 정의 함수 호출

하이버네이트는 사용전 방언에 추가해야 한다.

DB에 커스텀 펑션 만든 후 사용

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

Named 쿼리 - 정적 쿼리

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

어노테이션 예시)

@Entity
@NamedQuery(
    name = "Member.findByUsername",
    query = "select m from Member m where m.username = :username")
public vlass Member {
  ...
}

List<Member> resultList = 
    em.createNamedQuery("Member.findByUsername", Member.class)
        .setParameter("username", "회원1")
        .getResultList();

왜 굳이 엔티티에 네임드 쿼리 쓰나? 그냥 찾을 때 쓰는거랑 똑같지 않을까?
- em.createQuery()안에 넣어서 그냥 사용할 수 있다. 하지만 큰 위험이 따른다.
- 문자열 자체이기 때문에 에러 포인트가 많다. 근데, 사용자 요청 오기 전까지 쿼리가 실행되지 않으니까 모른다. 그제서야 안다.
- 근데 Named쿼리는 애플리케이션 로딩 시점에 쿼리를 파싱한다. 그래서 배포하기 전에 문제를 잡을 수 있다. 아니, 개발하면서 띄워 보기만해도 잡을 수 있다.
- Spring-Data-JPA를 사용할 때 @Query 어노테이션이 이 Named쿼리로 동작하게 된다. 그래서 스프링 애플리케이션 올라갈때 바로 에러를 잡을 수 있다.
- 런타임 에러는 정말 위험하다.
XML에도 정의를 할 수 있다. 필요하면 알아보자.
Named 쿼리 환경에 따른 설정
- XML이 항상 우선권을 가진다.
- 애플리케이션 운영 환경에 따라 다른 XML을 배포할 수 있다.

Reference

자바 ORM 표준 JPA 프로그래밍
저자 직강 - https://www.youtube.com/watch?v=WfrSN9Z7MiA&list=PL9mhQYIlKEhfpMVndI23RwWTL9-VL-B7U

[JPA] 필드와 컬럼 매핑

nroo — Mon, 22 Apr 2019 20:40:14 +0900

JPA 필드와 컬럼 매핑

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

DDL을 애플리케이션 실행 시점에 자동 생성
테이블 중심 -> 객체 중심으로 이동한 것이다.
데이터베이스 방언을 활용해서 데이터베이스에 맞는 적절한 DDL 생성
이렇게 생성된 DDL은 개발 장비에서만 사용
생성된 DDL은 운영서버에서는 사용하지 않거나, 적절히 다듬은 후 사용
hibernate.hbm2ddl.auto
- create
  - 기존 테이블 삭제 후 다시 생성(DROP + CREATE)
- create-drop
  - create와 같으나 종료시점에 테이블 DROP(테스트에서 사용하면 도움됨)
- update
  - 변경분만 반영(운영DB에는 사용하면 안됨)
- validate
  - 엔티티와 테이블이 정상 매핑되었는지만 확인
- none
  - 사용하지 않음
데이터베이스 스키마 자동 생성하기 주의
- 운영 장비에는 절대 create, create-drop, update 사용하면 안된다.
- 개발 초기 단계는 create 또는 update
- 테스트 서버는 update 또는 validate
- 스테이징과 운영 서버는 validate 또는 none
  - 웬만하면 쓰면 안된다.

매핑 어노테이션

데이터베이스에 어떤식으로 매핑할지를 결정하는 철저히 매핑정보에 관련된 어노테이션들이다.

@Entity
public class Member {
  @Id
  private Lond id;
  
  @Column(name = "USERNAME")
  private String name;
  
  private int age;
  
  @Temporal(TemporalType.TIMESTAMP)
  private Date regDate;
  
  @Enumerated(EnumType.STRING)
  private MemberType memberType;
  
  ...
}

@Column
- @Column(name = "USERNAME")
- name
  - 필드와 매핑할 테이블의 컬럼 이름
- insertable, updatable
  - TRUE/FALSE 설정. 읽기 전용
- nullable
  - null 허용여부 결정, DDL 생성시 사용(not null 추가)
- unique
  - 유니크 제약 조건, DDL 생성시 사용
- columnDefinition, length, precision, scale(DDL)
@Temporal
- @Temporal(TemporalType.TIMESTAMP)
- 시간과 관련된 매핑
- Date 뿐만아니라 자바8에서 지원하는 LocalDatetime도 지원한다.
@Enumerates
- @Enumerated(EnumType.STRING)
- 자바의 Enum 타입 매핑을 지원한다.
- 현업에서는 EnumType을 무조건 STRING으로 지정 해야한다.
- 기본 값인 ORDINAL로 설정하면 Enum 순서로 숫자가 매핑되는데, Enum 중간에 필드가 하나 추가 되면 다 꼬이게 된다.
@Lob
- 컨텐츠의 길이가 너무 길 경우 바이너리 파일로 DB에 바로 밀어 넣어야 하는데, 보통 이런 경우에 사용한다.
- 공통적으로 @Lob으로 사용하면 된다.
- CLOB, BLOB 매핑
- CLOB : String, char[], java.sql.CLOB
- BLOB : byte[], java.sql.BLOB
@Transient
- 이 필드는 매핑하지 않는다.
- 애플리케이션에서 DB에 저장하지 않는 필드
- 웬만하면 쓰지 않는 것이...

식별자 매핑 어노테이션

식별자 매핑 방법
- @Id(직접 매핑)
- @GeneratedValue(strategy = GenerationType.[타입])
  - 타입 설정
  - IDENTITY
    - 데이터베이스에 위임, MYSQL
  - SEQUENCE
    - 데이터베이스 시퀀스 오브젝트 사용, ORACLE
    - @SequenceGenerator 필요
  - TABLE
    - 키 생성용 테이블 사용, 모든 DB에서 사용
    - @TableGenerator 필요
  - AUTO
    - 방언에 따라 자동 지정, 기본값

권장하는 식별자 전략

기본 키 제약 조건
- null 아님, 유일, 변하면 안된다.
미래까지 이 조건을 만족하는 자연키는 찾기 어렵다. 대리키(대체키)를 사용하자.
예를 들어 주민등록번호도 기본 키로 적절하지 않다.
- 주민번호를 PK로 설정하고 다른 테이블과 FK 참조시 그대로 주민번호가 넘어간다. 갑자기 나라에서 개인정보 목적으로 "DB에 주민번호 저장하지 마라"라고 한다. 헬게이트 오픈
권장
- Long + 대체키 + 키 생성전략 사용
- 대체키는 전혀 비즈니스랑 관계없는 키.
- AUTO_INCREMENT로 숫자로 PK를 사용하면, int쓰면 안된다. 생각보다 금방 끝난다..
- Long 타입으로.

Reference

자바 ORM 표준 JPA 프로그래밍
저자 직강 - https://www.youtube.com/watch?v=WfrSN9Z7MiA&list=PL9mhQYIlKEhfpMVndI23RwWTL9-VL-B7U

[JPA] 기초와 매핑

nroo — Mon, 22 Apr 2019 20:39:20 +0900

JPA 기초와 매핑

Hello JPA

JPA에서는 크게 중요한게 두가지가 있다. 첫번째는 객체와 관계형 데이터베이스를 중간에서 매핑하는 과정, 즉 설계 과정이 있고, 두번째는 JPA가 어떤 방식으로 동작하는지(영속성 컨텍스트)이며 이 두가지에 대해 이해 하는 것이 중요하다.

H2

http://www.h2database.com
최고의 실습용 DB, 가볍다(1.5MB)
웹용 쿼리툴 제공
MySQL, Oracle 데이터베이스 시뮬레이션 기능
Sequence, AUTO INCREMENT 기능 지원

객체 매핑하기

@Entity
- JPA가 관리할 객체, 엔티티라고 한다.
@Id
- DB PK와 매핑할 필드

persistence.xml

jpa 설정 파일
/META-INF/persistence.xml 위치
javax.persistence로 시작 : JPA 표준 속성
hibername로 시작 : 하이버 네이트 전용 속성

<?xml version="1.0" encoding="UTF-8"?>
<persistence xmlns="http://xmlns.jcp.org/xml/ns/persistence" version="2.2">
  <persistence-unit name="hello">
    <properties>
      
      <!-- 필수 속성-->
      <property name="javax.persistence.jdbc.driver" value="org.h2.driver"/>
      <property name="javax.persistence.jdbc.user" value="sa"/>
      <property name="javax.persistence.jdbc.password" value=""/>
      <property name="javax.persistence.jdbc.url" value="jdbc:h2:tcp://localhost/~/test"/>
      <property name="hibernate.dialect" value="org.hibernate.dialect.H2Dialect"/>

      <!-- 옵션 -->
      <property name="hibernate.show_sql" value="true"/>
      <property name="hibernate.format_sql" value="true"/>
      <property name="hibernate.use_sql_comments" value="true"/>
      <property name="hibernate.id.new_generator_mappings" value="true"/>
      
    </properties>
  </persistence-unit>
</persistence>

dialect는 데이터베이스 방언이라는 뜻인데,

데이터베이스 방언

JPA는 특정 데이터베이스에 종속적이지 않은 기술
각각의 데이터베이스가 제공하는 SQL 문법과 함수는 조금씩 다르다
- 가변 문자 : MySQL은 VARCHAR, Oracle은 VARCHAR2
- 문자열을 자르는 함수 : SQL 표준은 SUBSTRING(), Oracle은 SUBSTR()
- 페이징 : MySQL은 LIMIT, Oracle은 ROWNUM
방언 : SQL 표준을 지키지 않거나 특정 데이터베이스 만의 고유한 기능
Dialect를 사용하면 각 DB에 맞는 SQL을 생성해 준다.
hibernate.dialect 속성에 지정
- H2 : org.hibernate.dialect.H2Dialect
- Oracle 10g : org.hibernate.dialect.Oracle10gDialect
- MySQL : org.hibernate.dialect.MySQL5InnoDBDialect
하이버네이트는 45가지 방언을 지원

애플리케이션 개발

엔티티 매니저 팩토리 설정
- Persistence를 통해서 xml설정을 읽고, EntityManagerFactory를 만들어야 한다.
- 트랜잭션 단위로 기능을 만들때 항상 엔티티 매니저를 새로 만들어야 한다. EntityManagerFactory를 통해서 만든다.

엔티티 매니저 설정
트랜잭션
비즈니스 로직(CRUD)
주의할 점
- 엔티티 매니저 팩토리는 하나만 생성해서 애플리케이션 전체에서 공유
- 엔티티 매니저는 쓰레드간에 공유하면 안된다(사용하고 버려야 한다.)
- JPA의 모든 데이터 변경은 트랜잭션 안에서 실행

package basic;

import basic.entity.Member;
import javax.persistence.EntityManager;
import javax.persistence.EntityManagerFactory;
import javax.persistence.EntityTransaction;
import javax.persistence.Persistence;

public class Main {
    public static void main(String[] args) {
        EntityManagerFactory entityManagerFactory =
            Persistence.createEntityManagerFactory("hello");
        EntityManager em = entityManagerFactory.createEntityManager();
        EntityTransaction tx = em.getTransaction();
        tx.begin();

        try {
            Member member = new Member();
            member.setId(100L);
            member.setName("name");

            em.persist(member);

            tx.commit();

        } catch (Exception e) {
            tx.rollback();
        } finally {
            em.close();
        }
        
        entityManagerFactory.close();
    }
}

Reference

자바 ORM 표준 JPA 프로그래밍
저자 직강 - https://www.youtube.com/watch?v=WfrSN9Z7MiA&list=PL9mhQYIlKEhfpMVndI23RwWTL9-VL-B7U

[JPA] ORM과 JPA 소개, SQL 중심적인 개발의 문제점

nroo — Mon, 22 Apr 2019 20:35:09 +0900

JPA Intro

SQL 중심적인 개발의 문제점
JPA 소개

1. SQL 중심적인 개발의 문제점

현재 데이터베이스 세계의 헤게모니를 관계형 DB가 가지고 있다(Oracle, MySQL, ...). 객체를 관계형 DB에 관리하고 있다는 이야기이다. 관계형 DB를 사용하려면 SQL을 짜야한다. 계속. SQL 중심적인 개발을 하게되면 아래와 같은 문제점이 있다.

무한 반복, 지루한 코드

객체 CRUD(insert, update, select, delete)

public class Member {
  private String memberId;
  private String name;
  ...
}

INSERT INTO MEMBER(MEMBER_ID, NAME) VALUES ...
SELECT MEMBER_ID, NAME FROM MEMBER M
UPDATE MEMBER SET ...

기획자가 tel 정보를 추가하자고 한다. 그렇다면 전개는?

Member 객체에 필드를 하나 추가하게되고, 모든 쿼리에 tel 정보를 추가해야 된다. 모든! 쿼리에..

public class Member {
  private String memberId;
  private String name;
  private String tel;
  ...
}

INSERT INTO MEMBER(MEMBER_ID, NAME, TEL) VALUES ...
SELECT MEMBER_ID, NAME, TEL FROM MEMBER M
UPDATE MEMBER SET ... TEL =?

엔티티 신뢰 문제

코드를 객체 지향적으로 짰다고 가정하고, MemberDAO에서 member를 하나 꺼내왔다고 하자.
해당 멤버의 팀과 주문정보, 그 주문정보의 배송지 정보를 getter로 가져오려고 하는 건 자연스러운 생각이다.
하지만, 해당 member가 팀과 주문과 배송지 정보를 가지고 있다고 보장되지 않는 이상 이렇게 코드를 짤 수 없다.
DAO의 코드를 까서 팀과 주문정보 주문에 대한 배송지 정보들을 쿼리로 정말 가져오는지 눈으로 확인해봐야 한다.
계층형 아키텍처(controller, domain, service등의 계층형 구조)의 진정한 의미의 계층 분할이 어렵다는 이야기이다. 즉, 물리적으로는 분리되어 있지만 논리적으로는 전혀 분할되어 있지 않다는 이야기 이다.
결과적으로 어떤 쿼리를 짜느냐에 따라 비즈니스 로직에 영향을 주기 때문에 SQL 의존적인 개발을 피하기 어렵다.

class memberService {
  ...
  public void process(String id) {
    Member member = memberDAO.find(id);
    member.getTeam();                 //???
    member.getOrder().getDelevery();  //???
  }
}

패러다임의 불일치

객체 vs 관계형 데이터베이스
- 관계형 데이터베이스는 철저히 '데이터를 어떤식으로 잘 저장할까'에 포커스가 맞춰져있다.
- 객체는 데이터 저장이 아니라 '어떻게 더 추상화하고 관리를 잘 할까'가 더 중요하다.
- 우리는 포커스가 다른 두 가지를 억지로 맵핑해서 일을 처리해야하기 때문에 그 사이에서 많은 시간을 보내고 있다.
객체를 영구 보관하는 다양한 저장소
- Object -> RDB, NoSQL, File 등 객체를 저장할 수 있는 방법이 많이 있지만,
- 현실적인 대안은 관계형 데이터베이스이다.
객체를 관계형 DB에 저장하려면 객체를 SQL로 바꾼다. (개발자가, 한땀한땀)
- 개발자가 SQL 매퍼의 일을 너무 많이 하고 있다.

객체와 관계형 데이터베이스의 차이

상속
- 객체의 상속 관계
- Table 슈퍼타입 서브타입 관계
연관관계
- 객체는 참조를 사용
  - member.getTeam()
  - 객체의 연관관계에는 방향성이 있다. 멤버에서 팀을 조회할 수 있지만, 팀에서 멤버조회는 불가하다.
    - Member의 필드는 id, Team, username
    - Team의 필드는 id, name 이라고 가정.
- 테이블은 외래 키를 사용
  - JOIN ON M.TEAM_ID = T.TEAM_ID
    - MEMBER 테이블
      - MEMBER_ID(PK)
      - TEAM_ID(FK)
      - USERNAME
    - TEAM 테이블
      - TEAM_ID(PK)
      - NAME
    - MAEMBER와 TEAM은 N:1 관계
  - 테이블의 외래키에는 방향성이 없다. 멤버랑 팀 조인가능, 팀과 멤버 조인가능.
- 이 때, 위의 테이블 설계에 맞추어 객체를 모델링하게 되면 아래와 같이 FK를 그대로 필드로 포함하게 된다. 하지만, Member클래스에 Team 객체가 존재하는 것이 더 객체지향적이다 라고 할 수 있다. FK의 값을 넣는것 보단.
```
class Member {
  String id;        //MEMBER_ID 컬럼
  Long teamId;      //TEAM_ID FK 컬럼
  String username;  //USERNAME 컬럼
}
```
```
class Team {
  Long id;
  String name;
}
```
  - 이렇게 설계된 객체를 테이블에 저장 한다.
    - 테이블 설계에 맞추어 객체를 모델링해서 INSERT 쿼리를 짠다.
```
INSERT INTO MEMBER(MEMBER_ID, TEAM_ID, USERNAME) VALUES ...
```
- 그러나, 객체다운 모델링에서는 아래와 같이 Team이라는 객체 자체를 포함하고 있어서 Member객체에서 Team을 바로 접근할 수 있다.
```
class Member {
  String id;
  Team team;        //참조로 연관관계를 맺는다
  String username;
}
```
```
class Team {
  Long id;        // TEAM_ID PK 사용
  String name;    // NAME 컬럼 사용
}
```
  - 테이블에 저장할 때에는 member.getTeam().getId()로 Id를 조회해서 넣었다.
```
INSERT INTO MEMBER(MEMBER_ID, TEAM_ID, USERNAME) VALUES ...
```
  - 그러나, 조회를 하려고 하면…. 헬게이트 오픈이다. 먼저 멤버와 팀을 조인해 놓고 팀을 조회할 준비를 한다.
```
SELECT M.*, T.*
  FROM MEMBER M
  JOIN TEAM T ON M.TEAM_ID = T.TEAM_ID
```
  - DB에서 조회해서 객체에 넣으려면..
```
public Member find(Strubg memberId) {
  // SQL 실행하고
  Member member = new Member();
  // DB에서 조회한 회원 관련 정보를 모두 입력하고
  Team team = new Team();
  // DB에서 조회한 팀 관련 정보를 모두 넣고,
  
  // 회원과 팀 관계 설정
  member.setTeam(team);
  return member;
}
```
  - 하지만…. 선배들은 member와 team의 정보를 모두 가지고 있는 member_team DTO를 가지고, 위와같이 복잡하게 연관관계 매핑을 하지않고 한방 쿼리를 날리면서 작업을 한다...
객체 그래프 탐색
- 객체는 자유롭게 객체 그래프를 탐색할 수 있어야 한다.
  - 예를 들면, member.getTeam(), member.getOrder(), member.getOrder().getOderItem() 할 수 있어야 된다.
- DB에서는 멤버와 팀 멤버와 오더 서로 조회를 할 수 있다. 하지만, 서비스 로직에서는 못한다. 왜? 처음에 쿼리에 넣어놓지 않아서 가져오지 않았기 때문에.
- 핵심은 처음 실행하는 SQL에 따라 탐색 범위가 결정된다는 것이다.
```
SELECT M.*, T.*
  FROM MEMBER M
  JOIN TEAM T ON M.TEAM_ID = T.TEAM_ID
```
```
member.getTeam(); //OK

member.getOrder(); //NULL
```
- 아래와 같은 서비스 로직을 짤 때, 내가 DAO를 작성하지 않았다고 생각하면 헬게이트 오픈. memberDAO가 member를 어떻게 가져오느냐 눈으로 확인해야된다. NPE 여지가 다분하다.
```
class MemeberService {
  ...
  public void process() {
    Member member = memberDAO.find(memberId);
    member.getTeam();  //???
    member.getOrder().getDelivery();   //???
  }
}
```
- 이런식의 해결법도 있긴 하다.
  - 경우의 수를 다 파악해서 DAO에 메소드를 다 만들어 놓는다.
  - Member만 조회, Member와 Team 조회, Order까지 조회 등
  - 이게 맞을까?

비교하기

DB에서 조회해오면 JDBC 접근로직 타고 new로 생성하니까 당연히 다르다.

String memberId = "100";
Member member1 = memberDAO.getMember(memberId);
Member member2 = memberDAO.getMember(memberId);

member1 == member2; //다르다

class MemberDAO {
  public Member getMember(String memberId) {
    String sql = "SELECT * FROM MEMBER WHERE MEMBER_ID = ?";
    ...
    // JDBC API, SQL 실행
    return new Member(...);
  }
}

비교하기 - 자바 컬렉션에서 조회
- 그런데, 자바 컬렉션에서 조회한다고 가정해보면 두 멤버는 같은 멤버이다.
```
String memberId = "100";
Member member1 = list.get(memberId);
Member member2 = list.get(memberId);

member1 == member2; //같다.
```
위의 비교를 통해 둘간의 패러다임 차이를 느낄 수 있다.
결론적으로 객체답게 모델링 할수록 매핑 작업만 늘어나게 된다.
객체를 자바 컬렉션에 저장하듯이 DB에 저장할 수는 없을까?
이에 대한 고민에 의해 자바진영에는 JPA라는 것이 있다.

2. JPA?

Java Persistence API
자바 진영의 ORM 기술 표준

ORM

Object-relational mapping(객체 관계 매핑)
- 객체와 RDB를 어떻게 매핑할까?
객체는 객체대로 설계
관계형 데이터베이스는 관계형 데이터베이스대로 설계
ORM 프레임워크가 중간에서 매핑
대중적인 언어에는 대부분 ORM 기술이 존재

JPA의 동작 지점

JPA는 애플리케이션과 JDBC 사이에서 동작한다. JDBC API 와 DB 사이에 있기 때문에 가운데서 대신 무언가를 해준다.
저장
- 위의 상속관계에서 Album 객체를 저장한다고 생각해보자.
- INSERT 쿼리가 두번 만들어져서 날라간다.
  - INSERT INTO ITEM ...
  - INSERT INTO ALBUM ...
- JPA persistant 객체에 Album 객체 저장하면. 알아서 INSERT 쿼리 두개 만들어서 넣는다.
- 단순하게 INSERT 쿼리 두벌 만들어서 DB에 넣는게 아니라 패러다임의 불일치 자체를 해결한다.
- 알아서 두개 클래스에 다 넣어준다.
- 예)
조회
- JPA를 통해서 Album 객체를 조회하게 되면, Item과 Album객체를 이쁘게 조인 쿼리를 날려서 가져오고, Album 객체를 반환한다.
- 예)

JPA 소개

예전에 상용 WAS를 사용하던 시절 WAS 1대당 수천만원을 호가했고, 두대정도 깔고 클러스터링 하면 5-6천만원씩 주고 서버를 구성했다. 거기에 EJB라는 기능이 들어있었는데, EJB의 엔티티 빈(자바 표준)이라는 JPA의 초창기 버전이 있었다.
이 엔티티 빈의 문제가 너무 많았다. 너무 코드가 지저분하고, API도 너무 복잡하고, 성능도 나빴다. EJB가 너무 문제가 많아서 개빈 킹이 오픈소스 ORM 프레임워크 하이버네이트를 출시했고
EJB 엔티티 빈의 사용자들이 다 넘어가면서 하이버네이트가 득세를 한다.
그 후에 자바진영에서 자바 표준 JPA를 만들었는데, 개빈 킹을 데려와서 만들었다.
JPA는 사실상 인터페이스만 있다. 구현은 각 기업이 하는거고, 그 중에서 오픈소스인 하이버네이트 같은 구현체들이 존재하는 것이다.
JPA가 표준화를 거치면서 수 많은 커뮤니티의 용어 등 애매한 것들을 정리하면서 표준을 만들었다.
JPA는 표준 명세이며
- 인터페이스의 모음이다
- JPA 2.1 표준 명세를 구현한 3가지 구현체
  - 하이버네이트, EclipseLink, DataNubleus
이 시기에 EJB에 대한 회의감을 느낀 사람이 한명 더 있었는데, Spring 프레임워크를 만든 로드 존슨이다. Spring과 하이버네이트가 득세를 하면서 해외에서는 거의 두가지가 기술 표준이 된다.
국내에서는 아쉽게도 Spring을 쓰면서 iBatis/myBatis가 득세를 하게 된다. 5-6년전에 국내에만 90% 사용률을 보였고, 해외해서는 JPA 사용률이 90%였다.

JPA를 왜 사용해야 하는가?

SQL 중심적인 개발에서 객체 중심으로 개발
생산성
- JPA와 CRUD
  - 저장
    - jpa.persist(member)
  - 조회
    - Member member = jpa.find(memberId)
  - 수정
    - member.setName("변경할 이름")
    - 트랜잭션이 끝나는 시점에 변경된 내용 찾아서 DB에 넣어준다. 뒤에서 보자.
  - 삭제
    - jpa.remove(member)
유지보수
- 기존에는 필드 변경시 모든 SQL을 수정한다. insert, select, update에 모두
- 하지만, JPA는 필드만 추가하면 된다. SQL은 JPA가 처리한다.
패러다임의 불일치 해결
- JPA와 상속
  - 저장
    - 개발자가 할 일
      - jpa.persist(album);
    - 나머진 JPA가 처리
      - INSERT INTO ITEM ...
      - INSERT INTO ALBUM ...
  - 조회
    - 개발자가 할 일
      - Album album = jpa.find(Album.class, albumId);
    - 나머진 JPA가 처리
```
SELECT I.*, A.*
  FROM ITEM I
  JOIN ALBUM A ON I.ITEM_ID = A.ITEM_ID
```
- JPA와 연관관계
  - 연관관계 저장
```
member.setTeam(team);
jpa.persist(member);
```
- JPA와 객체 그래프 탐색
```
Member member = jpa.find(Member.class, memberId);
Team team = member.getTeam();
```
  - 뭔가 이상하지 않은가?
  - member만 가져왔는데 어떻게 team이 조회가 되지? NPE 날 것 같은데?
  - 이렇게 예측할 수 있다. JPA가 멤버랑 팀이랑 한방쿼리로 조인해서 가져오나보다.
  - 근데 테이블 50개 연관되어있다. 50개 다 조인해서 가져올까?
  - 그렇지 않다. 아주 우아한 방법으로 동작을 한다.
  - 먼저 답을 말하면 getTeam()은 가능하다. 가져올 수 있다.
  - 방법은 이렇다. member.getTeam()할 때, 정확히 말하면 가져온 team을 사용하는 시점에 team이 가져와져 있지 않으면 그때 가져온다. 팀만 조회하는 쿼리를 날려서. 이것을 LazyLoding 이라고 표현한다.
  - 쿼리 두번 나가잖아요! 라고 할 수 있는데, 이게 싫다면 설정을 통해서 한번에 가져오는 쿼리를 날릴 수도 있다.
  - 이렇기 때문에 신뢰할 수 있는 엔티티 계층이 생기게 된다. member.getTeam(), member.getOrder().getDelevery()를 이용해 자유롭게 객체 그래프를 탐색할 수 있다.
- JPA와 비교하기
  - JPA는 동일 트랜잭션에서 조회한 엔티티는 같음을 보장한다.
```
String memberId = "100";
Member member1 = jpa.find(memberId);
Member member2 = jpa.find(memberId);

member1 == member2; //같다.
```
- JPA를 사용하는 코드를 보면 자바 컬렉션을 사용하는 느낌을 받을 수 있는데, 그게 JPA의 컨셉이다. 나머지는 JPA가 해주겠다는 의미이다.
JPA의 성능 최적화 기능
- JPA가 JDBC API와 DB사이에 존재하므로 가운데에 계층이 추가되서 느리지 않을까? 라고 생각할 수 있지만, 반대로 중간에 있으면 할 수 있는게 많다.
  - 1차 캐시와 동일성(identity) 보장
    - JPA와 비교하기의 코드에서 jpa.find()가 두번 일어나는데, JPA는 같은 트랜잭션에서 두번째 find는 1차 캐시에서 가져온다.
  - 트랜잭션을 지원하는 쓰기 지연(transactional write-behind)
    - 트랜잭션을 커밋할 때까지 INSERT SQL을 모음
    - JDBC BATCH SQL 기능을 사용해서 한번에 SQL 전송
      - 모으지 않으면 네트워크 3번 타고, 쿼리를 3번 날린다.
```
transcation.begin(); //트랜잭션 시작

em.persist(memberA);
em.persist(memberA);
em.persist(memberA);
//여기까지 insert SQL을 DB에 보내지 않는다.

//커밋하는 순간 DB에 SQL 모아서 보낸다.
transction.commit();
```
  - 지연 로딩(Lazy Loading)
    - 지연로딩 : 객체가 실제 사용될 때 로딩
```
Member member = memberDAO.find(memberId);  // SELECT * FROM MEMBER
Team team = member.getTeam();
String teamName = team.getName();  //SELECT * FROM TEAM
```
    - 즉시로딩: JOIN SQL로 한번에 연관된 객체까지 미리 조회
```
Member member = memberDAO.find(memberId);  // SELECT ... FROM MEMBER JOIN TEAM ...
Team team = member.getTeam();
String teamName = team.getName();
```
ORM은 객체와 RDM 두 기둥위에 있는 기술이다
- 객체도 잘 다뤄야 하고, RDB도 정말 잘 다뤄야 한다. 실제 현업에서 90% 이상 장애는 DB에서 난다.
- JPA로 개발하더라도 쿼리가 눈에 다 보여야 한다. 실제로 JPA는 정말 복잡한 쿼리가 아닌 심플한 쿼리들이 나간다.

Reference

자바 ORM 표준 JPA 프로그래밍
저자 직강 - https://www.youtube.com/watch?v=WfrSN9Z7MiA&list=PL9mhQYIlKEhfpMVndI23RwWTL9-VL-B7U