728x90
반응형
SMALL

Kafka Broker

  • Topic과 Partition을 유지 및 관리
  • Partition에 대한 Read 및 Write를 관리하는 소프트웨어
  • Kafka Server라고 부르기도 함
  • Topic 내 Partition 들을 분산, 유지 및 관리
  • 각각의 Broker들은 ID로 식별됨 (단, ID는 숫자)
  • Topic의 일부 Partition들을 포함, Topic 데이터의 일부분(Partition)을 갖을 뿐, 데이터 전체를 가지고 있는게 아님
  • Kafka Cluster: 여러 개의 Broker들로 구성
  • Client는 특정 Broker에 연결하면 전체 클러스터에 연결됨
  • 최소 3대 이상의 Broker를 하나의 Cluster로 구성해야 한다. 4대 이상을 권장한다.

 

 

Kafka Broker ID와 Partition ID의 관계

아무런 관계도 없다.

 

Bootstrap Servers

  • Broker Servers를 의미한다. 
  • 모든 Kafka Broker는 Bootstrap Server라고 부른다.
  • 하나의 Broker에만 연결하면, Cluster 전체에 연결된다. 하지만, 특정 Broker 장애를 대비하여 전체 Broker List(IP, Port)를 파라미터로 입력하는 걸 권장한다.
  • 각각의 Broker는 모든 Broker, Topic, Partition에 대해 알고 있다.

 

728x90
반응형
LIST

'Apache Kafka' 카테고리의 다른 글

p6. Replication  (0) 2025.03.15
p5. Consumer  (0) 2025.03.15
p4. Producer  (0) 2025.03.15
p2. Topic, Partition, Segment  (0) 2025.03.15
p1. Apache Kafka란  (0) 2025.03.15
728x90
반응형
SMALL

Apache Kafka의 주요 요소

- Topic, Producer, Consumer

  • Producer: 메시지를 생산해서 Kafka의 Topic으로 메시지를 보내는 애플리케이션
  • Consumer: Topic의 메시지를 가져와서 소비하는 애플리케이션
  • Consumer Group: Topic의 메시지를 사용하기 위해 협력하는 Consumer들의 집합
  • 하나의 Consumer는 하나의 Consumer Group에 포함되며, Consumer Group내의 Consumer들은 협력하여 Topic의 메시지를 분산 병렬 처리한다.

 

ProducerConsumer의 기본 동작 방식

  • Producer와 Consumer는 서로 알지 못하며, Producer와 Consumer는 각각 고유의 속도로 Commit Log에 Write, Read를 수행
  • 다른 Consumer Group에 속한 Consumer들은 서로 관련이 없으며, Commit Log에 있는 Event를 동시에 다른 위치에서 Read할 수 있다.

 

Kafka Commit Log

  • Commit Log: 추가만 가능하고 변경 불가능한 데이터 스트럭처, 데이터(Event)는 항상 로그 끝에 추가되고 변경되지 않는다.
  • Offset: Commit Log에서 Event의 위치, 아래 그림에서는 0부터 10까지의 Offset을 볼 수 있다.

 

Producer가 Write하는 LOG-END-OFFSET과 Consumer Group의 Consumer가 Read하고 처리한 후에 Commit한 CURRENT-OFFSET과의 차이(Consumer Lag)가 발생할 수 있다.

 

 

Topic, Partition, Segment

  • Topic: Kafka안에서 메시지가 저장되는 장소. 논리적인 공간
  • Partition: Commit Log. 하나의 Topic은 하나 이상의 Partition으로 구성. 보통은 병렬 처리를 위해 다수의 Partition 사용.
  • Segment: 메시지(데이터)가 저장되는 실제 물리 File. Segment File이 지정된 크기보다 크거나 지정된 기간보다 오래되면 새 파일이 열리고 메시지는 새 파일에 추가된다.

 

 

조금 더 구체적으로 들여다보면, 

  • Topic 생성 시 Partition의 개수를 지정하고, 각 Partition은 Broker들에 분산되며 Segment File들로 구성된다.
  • Rolling Strategy: log.segment.bytes(default 1GB), log.roll.hours(default 168 hours)

Active Segment

Partition당 하나의 Active Segment가 존재하는데, 이게 무슨 말이냐면,

  • 특정 Partition에는 Segment가 있고, 이 파일이 실제 데이터가 저장되는 파일인데 크기 또는 시간이 지정한 값보다 더 커지면 새로운 파일을 만들어 그 파일에 저장한다고 했다. 그리고 현재 저장되는 파일을 Active Segment 파일이라고 부른다.
  • Partition당 오직 하나의 Segment가 활성화(Active)되어 있다. 
  • Active된 Segment가 아닌 파일에는 변경이 불가능하다.

 

정리를 하자면

  • Topic 생성 시, Partition 개수를 지정한다. 개수 변경은 이후에도 가능하나 운영시에는 변경 권장하지 않는다. 그 이유는 이후에 설명한다.
  • Partition의 번호는 0부터 시작하고 오름차순
  • Topic 내 Partition 들은 서로 독립적
  • Event(Message)의 위치를 나타내는 Offset이 존재
  • Offset은 하나의 Partition에서만 의미를 가진다. 즉, Partition 0번의 Offset 1 은 Partition 1의 Offset 1과 아무런 관련이 없다.
  • Offset 값은 계속 증가하고 0으로 돌아가지 않는다.
  • Event(Message)의 순서는 동일한 Partition 내에서만 보장
  • Partition에 저장된 데이터(Message)는 변경이 불가능(Immutable)
  • Partition에 Write되는 데이터는 맨 끝에 추가되어 저장
  • Partition은 Segment File들로 구성되고, Rolling 정책은 log.segment.bytes(default 1GB), log.roll.hours(default 168 hours)

 

728x90
반응형
LIST

'Apache Kafka' 카테고리의 다른 글

p6. Replication  (0) 2025.03.15
p5. Consumer  (0) 2025.03.15
p4. Producer  (0) 2025.03.15
p3. Broker  (0) 2025.03.15
p1. Apache Kafka란  (0) 2025.03.15
728x90
반응형
SMALL

Kafka란 이벤트 스트리밍 플랫폼이다.

 

Event란?

이벤트는 비즈니스에서 일어나는 모든 일(데이터)을 의미한다.

  • 웹 사이트에서 무언가를 클릭하는 것
  • 청구서 발행
  • 송금
  • 배송 물건의 위치 정보
  • 택시의 GPS 좌표
  • 센서의 온도/압력 데이터

 

Event Stream은 그러니까 곧 = 연속적인 많은 이벤트들의 흐름.

 

Apache Kafka의 탄생

LinkedIn에서 개발된 이벤트 스트림 처리 플랫폼이고, 하루 4.5조 개 이상의 이벤트 스트림을 처리하기 위해 개발했다고 한다. 2011년에 Apache Software Foundation에 기부되어 오픈소스화됐다. 2012년 Apache Incubator 과정을 벗어나 최상위 프로젝트가 되고 현재는 Fortune 100 기업 중 80%이상이 사용중인 어마어마한 프로젝트.

 

Kafka 창시자인 Jay Kreps가 세운 Confluent 라는 회사도 2014년에 설립

 

Apache Kafka의 특징

 

Apache Kafka 사용 사례

이벤트가 사용되는 모든 곳에서 사용된다.

  • Messaging System
  • IOT 디바이스로부터 데이터 수집
  • 애플리케이션에서 발생하는 로그 수집
  • Realtime Event Stream Processing
  • DB 동기화 (MSA 기반의 분리된 DB간 동기화)
  • 실시간 ETL
  • Spark, Flink, Storm, Hadoop과 같은 빅데이터 기술과 같이 사용

산업 분야 별 Apache Kafka 사용 사례

교통 금융 오락 온라인 마켓
운전자 - 탑승자 매치 (탑승좌석) 사기 감지, 중복 거래 감지 실시간 추천 실시간 재고 정보
도착예상시간(ETA) 업데이트 거래, 위험 시스템 사기 감지 대용량 주문의 안전한 처리
실시간 차량 진단 모바일 애플리케이션 고객 경험 In-App 구매  

 

 

728x90
반응형
LIST

'Apache Kafka' 카테고리의 다른 글

p6. Replication  (0) 2025.03.15
p5. Consumer  (0) 2025.03.15
p4. Producer  (0) 2025.03.15
p3. Broker  (0) 2025.03.15
p2. Topic, Partition, Segment  (0) 2025.03.15
728x90
반응형
SMALL

참고자료

 

스프링 핵심 원리 - 고급편 강의 | 김영한 - 인프런

김영한 | 스프링의 핵심 원리와 고급 기술들을 깊이있게 학습하고, 스프링을 자신있게 사용할 수 있습니다., 핵심 디자인 패턴, 쓰레드 로컬, 스프링 AOP스프링의 3가지 핵심 고급 개념 이해하기

www.inflearn.com

 

프록시와 내부 호출 - 문제

스프링은 프록시 방식의 AOP를 사용한다. 따라서 AOP를 적용하려면 항상 프록시를 통해서 대상 객체를 호출해야 한다. 이렇게 해야 프록시에서 어드바이스를 호출하고, 이후에 대상 객체를 호출한다. 만약, 프록시를 거치지 않고 대상 객체를 직접 호출하게 되면 AOP가 적용되지 않고, 어드바이스도 호출되지 않는다.

 

AOP를 적용하면 스프링은 대상 객체 대신에 프록시를 스프링 빈으로 등록한다. 따라서 스프링은 의존관계 주입시에 항상 프록시 객체를 주입한다. 프록시 객체가 주입되기 때문에 대상 객체를 직접 호출하는 문제는 일반적으로 발생하지 않는다. 하지만 대상 객체의 내부에서 메서드 호출이 발생하면 프록시를 거치지 않고 대상 객체를 직접 호출하는 문제가 발생한다. 실무에서 반드시 한번은 만나서 고생하는 문제이기 때문에 꼭 이해하고 넘어가자.

 

예제를 통해서 내부 호출이 발생할 때 어떤 문제가 발생하는지 알아보자. 

 

CallServiceV0

package cwchoiit.springadvanced.aop.internalcall;

import lombok.extern.slf4j.Slf4j;
import org.springframework.stereotype.Component;

@Slf4j
@Component
public class CallServiceV0 {

    public void external() {
        log.info("external");
        internal();
    }

    public void internal() {
        log.info("internal");
    }
}
  • CallServiceV0.external()을 호출하면 내부에서 internal() 이라는 자기 자신의 메서드를 호출한다. 자바 언어에서 메서드를 호출할 때 대상을 지정하지 않으면 앞에 자기 자신의 인스턴스를 뜻하는 this가 붙게 된다. 그러니까 여기서는 this.internal() 이라고 이해하면 된다.

InternalAspect

package cwchoiit.springadvanced.aop.internalcall.aop;

import lombok.extern.slf4j.Slf4j;
import org.aspectj.lang.JoinPoint;
import org.aspectj.lang.annotation.Aspect;
import org.aspectj.lang.annotation.Before;

@Slf4j
@Aspect
public class InternalAspect {

    @Before("execution(* cwchoiit.springadvanced.aop.internalcall..*.*(..))")
    public void before(JoinPoint joinPoint) {
        log.info("[Before] {}", joinPoint.getSignature());
    }
}
  • CallServiceV0에 AOP를 적용하기 위해서 간단한 @Aspect를 하나 만들자.
  • 이렇게 하면, CallServiceV0external(), internal() 모두 AOP 적용 대상이 된다.

CallServiceV0Test

package cwchoiit.springadvanced.aop.internalcall;

import cwchoiit.springadvanced.aop.internalcall.aop.InternalAspect;
import lombok.extern.slf4j.Slf4j;
import org.junit.jupiter.api.Test;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.test.context.SpringBootTest;
import org.springframework.context.annotation.Import;

import static org.junit.jupiter.api.Assertions.*;

@Slf4j
@Import(InternalAspect.class)
@SpringBootTest
class CallServiceV0Test {

    @Autowired
    CallServiceV0 callServiceV0;

    @Test
    void external() {
        log.info("target = {}", callServiceV0.getClass());
        callServiceV0.external();
    }

    @Test
    void internal() {
        log.info("target = {}", callServiceV0.getClass());
        callServiceV0.internal();
    }
}
  • 이제 앞서 만든 CallServiceV0을 실행할 수 있는 테스트 코드를 만들자.
  • @Import(InternalAspect.class)를 사용해서 앞서 만든 @Aspect를 스프링 빈으로 등록한다. 이렇게 해서 CallServiceV0에 AOP 프록시를 적용한다.

먼저, callServiceV0.external()을 실행해보자. 이 부분이 중요하다.

실행 결과 - external()

target = class cwchoiit.springadvanced.aop.internalcall.CallServiceV0$$SpringCGLIB$$0
[Before] void cwchoiit.springadvanced.aop.internalcall.CallServiceV0.external()
external
internal
  • 실행 결과를 보면, callServiceV0.external()을 실행할 때는 프록시를 호출한다. 따라서 InternalAspect 어드바이스가 호출된 것을 확인할 수 있다.
  • 그리고 AOP Proxy는 target.external()을 호출한다.
  • 그런데 여기서 문제는, callServiceV0.external() 안에서 internal()을 호출할 때 발생한다. 이때는 실행 결과를 보면 알 수 있듯 어드바이스가 호출되지 않는다!

자바 언어에서 메서드 앞에 별도의 참조가 없으면 this 라는 뜻으로 자기 자신의 인스턴스를 가리킨다. 결과적으로 자기 자신의 내부 메서드를 호출하는 this.internal()이 되는데, 여기서 this는 실제 대상 객체(target)의 인스턴스를 뜻한다. 결과적으로 이러한 내부 호출은 프록시를 거치지 않는다. 따라서 어드바이스도 적용할 수 없다. 아래 그림을 보면 좀 더 이해가 될 것이다.

 

이번에는 외부에서 internal()을 호출하는 테스트를 실행해보자.

실행 결과 - internal()

target = class cwchoiit.springadvanced.aop.internalcall.CallServiceV0$$SpringCGLIB$$0
[Before] void cwchoiit.springadvanced.aop.internalcall.CallServiceV0.internal()
internal

  • 외부에서 호출하는 경우, 프록시를 거치기 때문에 internal()InternalAspect 어드바이스가 적용된 것을 확인할 수 있다.

 

이런 문제를 프록시 내부 호출 문제라고 한다. 일단 이 문제가 왜 발생하는지 이해하는 게 가장 중요하다. 

참고로, 실제 코드에 AOP를 직접 적용하는 AspectJ를 사용하면 이런 문제가 발생하지 않는다. 프록시를 통하는 것이 아니라 해당 코드에 직접 AOP 적용 코드를 바이트 조작으로 코드를 직접 아예 붙여버리기 때문에 내부 호출과 무관하게 AOP를 적용할 수 있다. 그러나 이 방법은 매우 복잡하고 JVM 옵션을 주어야 하는 부담이 있기 때문에 사용하지 않고 이 문제를 해결할 대안이 여럿 있기 때문에 그 대안을 알아보자.

 

프록시와 내부 호출 - 대안1 (자기 자신 주입)

결론부터 말하면 이 대안은 좋은 대안은 아니다. 그러나 방법 중 하나이긴 하다. 우선, 스프링 부트 2.6 이상부터는 순환 참조를 기본적으로 금지하도록 정책이 변경되었기 때문에 이 자기 자신을 주입하려면 다음과 같이 application.yaml 파일에 이 옵션을 추가해줘야 한다.

spring:
  main:
    allow-circular-references: true

 

CallServiceV1

package cwchoiit.springadvanced.aop.internalcall;

import lombok.extern.slf4j.Slf4j;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Component;

@Slf4j
@Component
public class CallServiceV1 {

    private CallServiceV1 callServiceV1;

    @Autowired
    public void setCallServiceV1(CallServiceV1 callServiceV1) {
        this.callServiceV1 = callServiceV1;
    }

    public void external() {
        log.info("external");
        callServiceV1.internal();
    }

    public void internal() {
        log.info("internal");
    }
}
  • 이 방법은 생성자 주입이 아니다. 생성자 주입은 아예 불가능하다. 왜냐하면? 내가 빈으로 만들어져야 생성자에 주입을 할텐데 나를 만들기 전에 생성자에 나를 주입한다? 닭이 먼저냐 달걀이 먼저냐의 문제가 되는 것이다.
  • 그래서, 세터 주입을 사용하는데 세터 주입은 스프링이 띄워지고 빈으로 등록된 후에 주입이 가능하기 때문에 오류가 발생하지 않는다. 
  • 세터에 자기 자신을 주입하고 있는 모습을 확인할 수 있다. 여기서 주입 받는 것은 '프록시'다. external() 안에서 자기 자신을 호출하는 게 아니라 또 프록시의 internal()을 호출하기 때문에 문제를 해결할 수 있다.

CallServiceV1Test

package cwchoiit.springadvanced.aop.internalcall;

import cwchoiit.springadvanced.aop.internalcall.aop.InternalAspect;
import lombok.extern.slf4j.Slf4j;
import org.junit.jupiter.api.Test;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.test.context.SpringBootTest;
import org.springframework.context.annotation.Import;

@Slf4j
@Import(InternalAspect.class)
@SpringBootTest
class CallServiceV1Test {

    @Autowired
    CallServiceV1 callServiceV1;

    @Test
    void external() {
        log.info("target = {}", callServiceV1.getClass());
        callServiceV1.external();
    }

    @Test
    void internal() {
        log.info("target = {}", callServiceV1.getClass());
        callServiceV1.internal();
    }
}

실행 결과

target = class cwchoiit.springadvanced.aop.internalcall.CallServiceV1$$SpringCGLIB$$0
[Before] void cwchoiit.springadvanced.aop.internalcall.CallServiceV1.external()
external
[Before] void cwchoiit.springadvanced.aop.internalcall.CallServiceV1.internal()
internal

  • 실행 결과를 보면, 이제는 internal()을 호출할 때 자기 자신의 인스턴스를 호출하는 것이 아니라 프록시 인스턴스를 통해서 호출하는 것을 확인할 수 있다. 당연히 AOP도 잘 적용된다.

 

프록시와 내부 호출 - 대안2 (지연 조회)

CallServiceV2

package cwchoiit.springadvanced.aop.internalcall;

import lombok.RequiredArgsConstructor;
import lombok.extern.slf4j.Slf4j;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.context.ApplicationContext;
import org.springframework.stereotype.Component;

@Slf4j
@Component
@RequiredArgsConstructor
public class CallServiceV2 {

    private final ApplicationContext applicationContext;

    public void external() {
        log.info("external");
        CallServiceV2 callServiceV2 = applicationContext.getBean(CallServiceV2.class);
        callServiceV2.internal();
    }

    public void internal() {
        log.info("internal");
    }
}
  • ApplicationContext를 직접 주입받고, 여기서 자기 자신의 빈을 꺼내는 것이다. 그럼 똑같이 프록시가 꺼내질 것이고 문제가 해결된다. 그런데 ApplicationContext이건 너무 거대하다. 그냥 스프링 하나가 있다고 보면 되는데 우리는 굳이 이렇게 큰 것을 가져올 필요가 없다.
  • 그래서 다음과 같이 ObjectProvider를 사용해보자.

CallServiceV2 

package cwchoiit.springadvanced.aop.internalcall;

import lombok.RequiredArgsConstructor;
import lombok.extern.slf4j.Slf4j;
import org.springframework.beans.factory.ObjectProvider;
import org.springframework.stereotype.Component;

@Slf4j
@Component
@RequiredArgsConstructor
public class CallServiceV2 {

    private final ObjectProvider<CallServiceV2> callServiceV2Provider;

    public void external() {
        log.info("external");
        CallServiceV2 callServiceV2 = callServiceV2Provider.getObject();
        callServiceV2.internal();
    }

    public void internal() {
        log.info("internal");
    }
}
  • 이렇게 ObjectProvider를 사용하면 된다. 딱 원하는 빈 하나만을 가져올 수 있도록 말이다.
  • 이렇게 딱 필요한 시점에 필요한 빈을 가져오니까 조회를 늦게 한다고 해서 지연 조회라고 한다.

 

프록시와 내부 호출 - 대안3 (구조 변경) ⭐️

앞선 방법들은 자기 자신을 호출하거나 또는 Provider를 사용해야 하는것처럼 조금 어색한 모습을 만들었다. 가장 나은 대안은 내부 호출이 발생하지 않도록 구조를 변경하는 것이다. 실제 이 방법을 가장 권장한다.

 

CallServiceV3

package cwchoiit.springadvanced.aop.internalcall;

import lombok.RequiredArgsConstructor;
import lombok.extern.slf4j.Slf4j;
import org.springframework.beans.factory.ObjectProvider;
import org.springframework.stereotype.Component;

@Slf4j
@Component
@RequiredArgsConstructor
public class CallServiceV3 {

    private final CallServiceInternal internalCallService;

    public void external() {
        log.info("external");
        internalCallService.internal();
    }
}

CallServiceInternal

package cwchoiit.springadvanced.aop.internalcall;

import lombok.extern.slf4j.Slf4j;
import org.springframework.stereotype.Component;

@Slf4j
@Component
public class CallServiceInternal {

    public void internal() {
        log.info("internal");
    }
}
  • 구조를 변경한다는 게 별게 아니라 그냥 internal() 메서드를 따로 빼버리고 별도의 클래스로 만들고 이 클래스를 주입받아 사용하면 된다. 
  • 결국 자기 자신을 호출하지만 않으면 되는 것이다.

CallServiceV3Test

package cwchoiit.springadvanced.aop.internalcall;

import cwchoiit.springadvanced.aop.internalcall.aop.InternalAspect;
import lombok.extern.slf4j.Slf4j;
import org.junit.jupiter.api.Test;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.test.context.SpringBootTest;
import org.springframework.context.annotation.Import;

@Slf4j
@Import(InternalAspect.class)
@SpringBootTest
class CallServiceV3Test {

    @Autowired
    CallServiceV3 callServiceV3;

    @Test
    void external() {
        log.info("target = {}", callServiceV3.getClass());
        callServiceV3.external();
    }
}

실행 결과

target = class cwchoiit.springadvanced.aop.internalcall.CallServiceV3$$SpringCGLIB$$0
[Before] void cwchoiit.springadvanced.aop.internalcall.CallServiceV3.external()
external
[Before] void cwchoiit.springadvanced.aop.internalcall.CallServiceInternal.internal()
internal

  • 내부 호출 자체가 사라지고, callService → internalService를 호출하는 구조로 변경되었다. 덕분에 자연스럽게 AOP가 적용된다.

 

참고로, AOP는 주로 트랜잭션 적용이나 주요 컴포넌트의 로그 출력 기능에 사용된다. 쉽게 이야기해서 인터페이스에 메서드가 나올 정도의 규모에 AOP를 적용하는 것이 적당하다. 더 풀어서 이야기하면, AOP는 public 메서드에만 적용한다. private 메서드처럼 작은 단위에는 적용하지 않는다. 적용할 수도 없다. AOP 적용을 위해 private 메서드를 외부 클래스로 변경하고 public으로 변경하는 일은 거의 없다. 그러나 위 예제와 같이 public 메서드에서 public 메서드를 내부 호출하는 경우에는 문제가 발생한다. AOP가 잘 적용되지 않으면 내부 호출을 의심해보자.

 

프록시 기술과 한계 - 타입 캐스팅

JDK 동적 프록시와 CGLIB를 사용해서 AOP 프록시를 만드는 방법에는 각각 장단점이 있다. JDK 동적 프록시는 인터페이스가 필수이고, 인터페이스를 기반으로 프록시를 생성한다. CGLIB는 구체 클래스를 기반으로 프록시를 생성한다.

 

물론, 인터페이스가 없고 구체 클래스만 있는 경우에는 CGLIB를 사용해야 한다. 그런데 인터페이스가 있는 경우에는 둘 중 하나를 선택해서 프록시를 만들 수 있다.

 

  • proxyTargetClass=false → JDK 동적 프록시를 사용해서 인터페이스 기반 프록시 생성
  • proxyTargetClass=trueCGLIB를 사용해서 구체 클래스 기반 프록시 생성
  • 참고로, 옵션과 무관하게 인터페이스가 없으면 무조건 CGLIB를 사용한다.

JDK 동적 프록시 한계

인터페이스를 기반으로 프록시를 생성하는 JDK 동적 프록시는 구체 클래스로 타입 캐스팅이 불가능한 한계가 있다. 사실 생각해보면 당연하다.

ProxyCastingTest

package cwchoiit.springadvanced.aop.proxyvs;

import cwchoiit.springadvanced.aop.member.MemberService;
import cwchoiit.springadvanced.aop.member.MemberServiceImpl;
import lombok.extern.slf4j.Slf4j;
import org.junit.jupiter.api.Test;
import org.springframework.aop.framework.ProxyFactory;

import static org.assertj.core.api.Assertions.assertThatThrownBy;

@Slf4j
public class ProxyCastingTest {

    @Test
    void jdkProxy() {
        MemberService target = new MemberServiceImpl();
        ProxyFactory proxyFactory = new ProxyFactory(target);
        proxyFactory.setProxyTargetClass(false);

        MemberService proxy = (MemberService) proxyFactory.getProxy();

        assertThatThrownBy(() -> {
            MemberServiceImpl castingProxy = (MemberServiceImpl) proxy;
        }).isInstanceOf(ClassCastException.class); // 에러 발생 (구체 타입으로 캐스팅 불가)
    }
}
  • 테스트 코드를 보면, 인터페이스로는 캐스팅이 가능하고 구체 클래스로 캐스팅을 할 때 ClassCastException이 발생할 것으로 예측하고 있다.
  • 실행 결과는 참이다.

  • JDK 동적 프록시는 인터페이스를 기반으로 프록시를 생성한다. 그래서 당연히 인터페이스로는 캐스팅이 가능하다. 그런데 인터페이스는 자기를 구현한 구현체에 대한 정보를 아무것도 모른다. 당연하다. 그러면 프록시가 구체 클래스로 캐스팅 할 수 있을까? 없다. 아무것도 모르는데 어떻게 캐스팅을 하겠는가? 따라서 당연히 캐스팅 에러가 발생한다.
  • 위 그림만 봐도 바로 이해가 될 것이다. JDK 동적 프록시는 인터페이스만 알고 있다. 인터페이스 만으로는 구현 클래스에 대한 정보를 알 수 없다.

 

이번엔 CGLIB를 사용해보자.

@Test
void cglibProxy() {
    MemberService target = new MemberServiceImpl();
    ProxyFactory proxyFactory = new ProxyFactory(target);
    proxyFactory.setProxyTargetClass(true);

    MemberService proxy = (MemberService) proxyFactory.getProxy();
    MemberServiceImpl castingProxy = (MemberServiceImpl) proxy;
}
  • CGLIB는 인터페이스로 캐스팅하든, 구현체로 캐스팅하든 모두 성공한다.

  • 사실 이것도 너무 당연한게 CGLIB는 구현체를 상속받아서 프록시를 만든다. 구현체는 MemberServiceImpl이다. 그리고 이 MemberServiceImpl은 자기의 부모인 인터페이스(MemberService)를 알고 있다. 
  • 그럼 프록시 입장에서는 둘 다 알고 있으니 둘 다 캐스팅이 가능한 것이다.

 

정리를 하자면

JDK 동적 프록시는 구현체로 캐스팅 할 수 없다.

CGLIB 프록시는 구현체로 캐스팅 할 수 있다. 

 

근데, 이 문제가 뭐 어떻다는 건가? 진짜 문제는 의존관계 주입시에 발생한다.

 

프록시 기술과 한계 - 캐스팅 문제로 인한 의존관계 주입

JDK 동적 프록시를 사용하면서 의존관계 주입을 할 때 어떤 문제가 발생하는지 코드로 알아보자.

ProxyDIAspect

package cwchoiit.springadvanced.aop.proxyvs.code;

import lombok.extern.slf4j.Slf4j;
import org.aspectj.lang.JoinPoint;
import org.aspectj.lang.annotation.Aspect;
import org.aspectj.lang.annotation.Before;

@Slf4j
@Aspect
public class ProxyDIAspect {

    @Before("execution(* cwchoiit.springadvanced.aop..*.*(..))")
    public void beforeAdvice(JoinPoint joinPoint) {
        log.info("[before] {}", joinPoint.getSignature());
    }
}
  • 우선 AOP 프록시 생성을 위해 간단한 @Aspect를 만들자.

ProxyDITest

package cwchoiit.springadvanced.aop.proxyvs;

import cwchoiit.springadvanced.aop.member.MemberService;
import cwchoiit.springadvanced.aop.member.MemberServiceImpl;
import cwchoiit.springadvanced.aop.proxyvs.code.ProxyDIAspect;
import lombok.extern.slf4j.Slf4j;
import org.junit.jupiter.api.Test;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.test.context.SpringBootTest;
import org.springframework.context.annotation.Import;

@Slf4j
@SpringBootTest
@Import(ProxyDIAspect.class)
public class ProxyDITest {

    @Autowired
    MemberService memberService;

    @Autowired
    MemberServiceImpl memberServiceImpl;

    @Test
    void go() {
        log.info("memberService class = {}", memberService.getClass());
        log.info("memberServiceImpl class = {}", memberServiceImpl.getClass());

        memberServiceImpl.hello("hello");
    }
}
  • @Import(ProxyDIAspect.class)@Aspect를 스프링 빈으로 등록한다.
  • 그리고 인터페이스와 구체클래스 둘 다 주입받아보자. (이럴 일은 거의 없고 인터페이스를 주입받아야 좋은 설계가 맞지만 일단 테스트를 위해 이렇게 해보자)

application.yaml

spring:
  aop:
    proxy-target-class: false
  • JDK 동적 프록시로 프록시를 생성하도록 옵션을 적용하자.

실행 결과

org.springframework.beans.factory.BeanNotOfRequiredTypeException: 
Bean named 'memberServiceImpl' is expected to be of type 'cwchoiit.springadvanced.aop.member.MemberServiceImpl' 
but was actually of type 'jdk.proxy3.$Proxy65'
  • 이러한 타입 관련 에러가 발생한다. 왜냐? 위에서 설명한대로 JDK 동적 프록시는 구체 클래스에 대해 전혀 알 길이 없기 때문에 구체 클래스로 캐스팅이 불가능하기 때문이다.

 

반면, CGLIB로 프록시를 만들도록 옵션을 수정하고 실행해보자.

application.yaml

spring:
  aop:
    proxy-target-class: true
  • 실행해보면 정상 동작하는 것을 알 수 있다. 마찬가지 이유로 CGLIB는 구체 클래스를 기반으로 프록시를 만들고 구체 클래스는 당연히 구체 클래스도 알고 있고 그 상위인 인터페이스도 알고 있기 때문에 어떤 것으로도 캐스팅이 가능하기 때문이다.

 

정리를 하자면

지금까지 JDK 동적 프록시가 가지는 한계점을 알아보았다. 실제로 개발할 때는 인터페이스가 있으면 인터페이스를 기반으로 의존관계 주입을 하는 게 맞다. DI 장점이 무엇인가? DI를 받는 클라이언트 코드의 변경 없이 구현 클래스를 변경할 수 있다는 것이다. 이렇게 하려면 인터페이스를 기반으로 의존관계 주입을 받아야 한다. MemberServiceImpl 타입으로 의존관계 주입을 받는것처럼 구현 클래스에 의존관계를 주입하면 향후 구현 클래스를 변경할 때 의존관계 주입을 받는 클라이언트 코드도 함께 변경해야 한다. 따라서 올바르게 잘 설계된 애플리케이션이라면 이런 문제가 자주 발생하지는 않는다. 그럼에도 불구하고 테스트, 또는 여러가지 이유로 AOP 프록시가 적용된 구체 클래스를 직접 의존관계 주입 받아야 하는 경우가 있을 수 있다. 이때는 CGLIB를 통해 구체 클래스 기반으로 AOP 프록시를 적용하면 된다.

 

여기까지 듣고보면 CGLIB를 사용하는 것이 좋아보인다. CGLIB를 사용하면 이런 고민 자체를 하지 않아도 되니까 말이다. 

이번엔 CGLIB의 단점을 알아보자.

 

프록시 기술과 한계 - CGLIB

스프링에서 CGLIB는 구체 클래스를 상속 받아서 AOP 프록시를 생성한다. CGLIB는 구체 클래스를 상속받기 때문에 다음과 같은 문제가 있다.

 

CGLIB 구체 클래스 기반 프록시 문제점

  • 대상 클래스에 기본 생성자 필수
  • 생성자 2번 호출 문제
  • final 키워드 클래스, 메서드 사용 불가

대상 클래스에 기본 생성자 필수

CGLIB는 구체 클래스를 상속 받는다. 자바 언어에서 상속을 받으면 자식 클래스의 생성자를 호출할 때 자식 클래스의 생성자에서 부모 클래스의 생성자도 호출해야 한다. (이 부분이 생략되어 있다면 자식 클래스의 생성자 첫 줄에 부모 클래스의 기본 생성자를 호출하는 super()가 자동으로 들어간다) 이 부분은 자바 문법 규약이다. CGLIB를 사용할 때 CGLIB가 만드는 프록시의 생성자는 우리가 호출하는 것이 아니다. CGLIB 프록시는 대상 클래스를 상속 받고, 생성자에서 대상 클래스의 기본 생성자를 호출한다. 따라서 대상 클래스에 기본 생성자가 필수이다. 

 

생성자 2번 호출 문제

CGLIB는 구체 클래스를 상속받는다. 자바 언어에서 상속을 받으면 자식 클래스의 생성자를 호출할 때 부모 클래스의 생성자도 호출해야 한다. 그런데 왜 2번일까?

  • 실제 target 객체를 생성할 때
  • 프록시 객체를 생성할 때 부모 클래스의 생성자 호출

  • 그러니까, 프록시는 실제 객체가 반드시 있어야 한다. 그러러면 실제 객체를 만들어야 한다. 그때 생성자를 한번 호출한다.
  • 프록시 객체를 생성할 때 CGLIB는 실제 객체를 상속받는다. 상속을 받을 때 부모 클래스의 생성자를 호출하는데 부모 클래스가 곧 실제 객체이므로 또 생성자를 호출한다.

final 키워드 클래스, 메서드 사용 불가

final 키워드가 클래스에 있으면 상속이 불가능하고, 메서드에 있으면 오버라이딩이 불가능하다. CGLIB는 상속을 기반으로 하기 때문에 두 경우 프록시가 생성되지 않거나 정상 동작하지 않는다. 그런데, 사실 이 부분은 크게 문제가 되지는 않는다. 거의 대부분 애플리케이션을 개발할 때 final 키워드를 붙인 클래스를 만들지 않기 때문에. 

 

정리를 하자면

JDK 동적 프록시는 대상 클래스 타입으로 주입할 때 문제가 있고, CGLIB는 대상 클래스에 기본 생성자 필수, 생성자 2번 호출 문제가 있다. 그렇다면 스프링은 어떤 방법을 권장할까?

 

프록시 기술과 한계 - 스프링의 해결책

스프링은 AOP 프록시 생성을 편리하게 제공하기 위해 오랜 시간 고민하고 문제들을 해결해왔다.

 

스프링의 기술 선택 변화, 스프링 3.2, CGLIB를 스프링 내부에 함께 패키징

 CGLIB를 사용하려면 CGLIB 라이브러리가 별도로 필요했다. 스프링은 CGLIB 라이브러리를 스프링 내부에 함께 패키징해서 별도의 라이브러리 추가 없이 CGLIB를 사용할 수 있게 되었다.

 

CGLIB 기본 생성자 필수 문제 해결

스프링 4.0부터 CGLIB의 기본 생성자가 필수인 문제가 해결되었다. objenesis 라는 특별한 라이브러리를 사용해서 기본 생성자 없이 객체 생성이 가능하다. 참고로 이 라이브러리는 생성자 호출 없이 객체를 생성할 수 있게 해준다.

 

생성자 2번 호출 문제 해결

스프링 4.0부터 CGLIB의 생성자 2번 호출 문제가 해결되었다. 이것도 역시 objenesis 라는 특별한 라이브러리 덕분에 가능해졌다. 이제 생성자가 1번만 호출된다.

 

스프링 부트 2.0 - CGLIB 기본 사용

스프링 부트 2.0 버전부터 CGLIB를 기본으로 사용하도록 했다. 이렇게 해서 구체 클래스 타입으로 의존관계를 주입하는 문제를 해결했다. 스프링 부트는 별도의 설정이 없다면 AOP를 적용할 때 기본적으로 proxyTargetClass=true로 설정해서 사용한다. 따라서 인터페이스가 있어도 JDK 동적 프록시를 사용하는 것이 아니라 항상 CGLIB를 사용해서 구체 클래스를 기반으로 프록시를 생성한다. 물론 스프링은 우리에게 선택권을 열어주기 때문에 다음과 같이 설정하면 JDK 동적 프록시도 사용할 수 있다.

spring:
  aop:
    proxy-target-class: false

 

728x90
반응형
LIST
728x90
반응형
SMALL

스프링 데이터 JPA에서 Querydsl을 지원하는 QuerydslRepositorySupport 라는 추상 클래스가 있다. 어떤걸 도와주냐면 우리가 이전에 사용했던 Querydsl 용 리포지토리를 아래와 같이 변경해보자.

public class MemberRepositoryImpl extends QuerydslRepositorySupport implements MemberRepositoryQueryDsl {

    // private final JPAQueryFactory queryFactory;

    public MemberRepositoryImpl(Class<?> domainClass) {
        super(Member.class);
    }
    
    ...
    
}
  • 기존에는, extends QuerydslRepositorySupport 가 없었는데 이 부분을 추가했다.
  • 그리고, JPAQueryFactory를 주입 받아야 하는 부분도 제거했다. 대신 저 QuerydslRepositorySupport를 상속받으면 반드시 생성자를 만들어 줘야 하는데 그 부분이 바로 이 부분이다.
public MemberRepositoryImpl(Class<?> domainClass) {
    super(Member.class);
}

 

이렇게 해주면 아래와 같은 장점이 있다.

  • JPAQueryFactory를 주입받지 않아도 된다.
  • from()으로 시작하는 쿼리를 작성할 수 있다. (이게 장점인지는 모르겠다)
  • getQuerydsl().applyPagination() 이라는 스프링 데이터가 제공하는 페이징을 Querydsl로 편리하게 반환이 가능한데 사실 이것도 편리한지는 잘 모르겠다. 심지어 Sort도 제대로 동작안한다.
@Override
public List<MemberTeamDto> search(MemberSearchCondition condition) {
    return from(member)
            .leftJoin(member.team, team)
            .where(usernameEq(condition.getUsername()),
                    teamNameEq(condition.getTeamName()),
                    ageGoe(condition.getAgeGoe()),
                    ageLoe(condition.getAgeLoe())
            ).select(new QMemberTeamDto(
                    member.id.as("memberId"),
                    member.username,
                    member.age,
                    team.id.as("teamId"),
                    team.name.as("teamName")))
            .fetch();

    /*return queryFactory
            .select(new QMemberTeamDto(
                    member.id.as("memberId"),
                    member.username,
                    member.age,
                    team.id.as("teamId"),
                    team.name.as("teamName")))
            .from(member)
            .leftJoin(member.team, team)
            .where(usernameEq(condition.getUsername()),
                    teamNameEq(condition.getTeamName()),
                    ageGoe(condition.getAgeGoe()),
                    ageLoe(condition.getAgeLoe())
            ).fetch();*/
}
  • 주석 처리한 부분이 기존에 작성했던 코드이다.
  • 보면, from()으로 시작하는데, select()가 뒤에 있고 뭔가 좀 어색하고 쿼리를 한번에 읽기엔 명시적이지 않다. 난 이걸 장점으로 생각하지는 않는다. 
@Override
    public Page<MemberTeamDto> searchPaging(MemberSearchCondition condition, Pageable pageable) {

        JPQLQuery<MemberTeamDto> jpaQuery = from(member)
                .leftJoin(member.team, team)
                .where(usernameEq(condition.getUsername()),
                        teamNameEq(condition.getTeamName()),
                        ageGoe(condition.getAgeGoe()),
                        ageLoe(condition.getAgeLoe())
                ).select(new QMemberTeamDto(
                        member.id.as("memberId"),
                        member.username,
                        member.age,
                        team.id.as("teamId"),
                        team.name.as("teamName")));

        JPQLQuery<MemberTeamDto> query = getQuerydsl().applyPagination(pageable, jpaQuery);
        query.fetch();

        /*List<MemberTeamDto> result = queryFactory
                .select(new QMemberTeamDto(
                        member.id.as("memberId"),
                        member.username,
                        member.age,
                        team.id.as("teamId"),
                        team.name.as("teamName")))
                .from(member)
                .leftJoin(member.team, team)
                .where(usernameEq(condition.getUsername()),
                        teamNameEq(condition.getTeamName()),
                        ageGoe(condition.getAgeGoe()),
                        ageLoe(condition.getAgeLoe())
                )
                .offset(pageable.getOffset())
                .limit(pageable.getPageSize())
                .fetch();

        JPAQuery<Member> countQuery = queryFactory
                .select(member)
                .from(member)
                .leftJoin(member.team, team)
                .where(usernameEq(condition.getUsername()),
                        teamNameEq(condition.getTeamName()),
                        ageGoe(condition.getAgeGoe()),
                        ageLoe(condition.getAgeLoe())); */

        return PageableExecutionUtils.getPage(result, pageable, () -> countQuery.stream().count());
    }
  • 이게 이제 페이징을 좀 편리하게 해준다는 getQuerydsl().applyPagination()을 사용한 방법인데, 기존에 작성했던 코드랑 차이점은 쿼리에 offset(), limit()을 작성하지 않는다는 점이다. 
  • 근데, 이거 하나 줄이겠다고 저렇게 from()부터 시작하는 게 영 맘에 들지는 않는다.
728x90
반응형
LIST

'Querydsl' 카테고리의 다른 글

JPA 레포지토리와 Querydsl  (2) 2024.12.26
Querydsl 중급 문법  (0) 2024.12.22
Querydsl 기본 문법  (0) 2024.12.21
[Renewal] QueryDsl  (0) 2024.12.07
Spring Boot 3.1.5에서 QueryDSL 설치하기  (0) 2023.11.26
728x90
반응형
SMALL

컨텐츠 관리 데이터베이스에 웹 사이트에 공개할 기사를 저장했다. 기사 테이블과 태그 테이블 사이의 다대다 관계를 위해 교차 테이블을 사용했다.

CREATE TABLE ArticleTags
(
    id         BIGINT PRIMARY KEY,
    article_id BIGINT NOT NULL,
    tag_id     BIGINT NOT NULL,
    FOREIGN KEY (article_id) REFERENCES Articles (id),
    FOREIGN KEY (tag_id) REFERENCES Tags (id)
)

 

그러나, 특정 태그가 다린 기사 수를 세는 쿼리에서 잘못된 결과가 나오고 있었다. "경제" 태그가 달린 가사가 다섯 개라는 것을 알고 있었지만, 쿼리를 실행하면 일곱 개로 나왔다.

SELECT tag_id, COUNT(*) AS articles_per_tag
FROM ArticleTags
WHERE tag_id = 327;

 

tag_id와 같은 모든 행을 조회해봤더니, 태그가 하나의 기사와 중복해 연관되어 있었다. 세 개의 행은 id 값만 달랐지 동일한 연관을 나타내는 것이었다. 

id tag_id article_id
22 327 1234
23 327 1234
24 327 1234

 

이 테이블은 PK를 가지고 있었지만, PK가 중요 칼럼의 중복을 막지 못했다. 나머지 두 칼럼에 대해 UNIQUE 제약 조건을 생성하면 해결되겠지만, 그렇다면 id 칼럼은 왜 필요한 것일까?

 

목표: PK 관례 확립

데이터베이스 설계를 접했던 사람이라면, 모두 PK가 중요하고 꼭 필요한 테이블의 일부라는 사실을 알 것이다. PK는 좋은 데이터베이스 설계에 정말 중요하다. PK는 테이블 내의 모든 행이 유일함을 보장하기 때문에, 각 행에 접근하는 논리적 메커니즘이 되고 중복 행이 저장되는 것을 방지한다. 또한 PK는 관계를 생성할 때 FK로부터 참조되기도 한다. 까다로운 부분은 PK로 사용할 칼럼을 선정하는 일이다. 대부분의 테이블에서 어느 속성의 값이든 하나 이상의 행에서 나타날 잠재적 가능성이 있다. 교과서적인 예제로 자주 나오는 이름도 분명 중복될 수 있다. 심지어 이메일 주소도 마찬가지다.

 

이런 테이블에는 테이블로 모델링한 영역에서는 아무런 의미도 가지지 않는 인위적인 값을 저장할 새로운 칼럼이 필요하다. 이 칼럼을 PK로 사용하면 다른 속성 칼럼에는 중복 값이 들어가는 것을 허용하는 반면, 특정 행에 유일하게 접근할 수 있게 된다. 이런 형태의 PK를 가상키 또는 대체키라고 한다. 

 

안티패턴: 만능키

책이나 기사, 프로그래밍 프레임워크는 데이터베이스 내 모든 테이블이 다음과 같은 특성을 가지는 PK 칼럼을 가지도록 하는 문화적 관례를 만들었다. 

  • PK 칼럼의 이름은 id다.
  • PK 칼럼의 데이터 타입은 32비트 또는 64비트 정수다.
  • 유일한 값은 자동 생성된다.

모든 테이블에 id란 이름의 칼럼이 있는 것은 너무도 흔해져 이게 PK와 동의어가 되어 버렸다. SQL을 배우는 프로그래머들은 PK가 항상 다음과 같은 식으로 정의되는 칼럼이라는 잘못된 생각을 갖게 된다.

CREATE TABLE Bugs (
    id          BIGINT PRIMARY KEY,
    description VARCHAR(1000),
    ...
)

 

모든 테이블에 id 칼럼을 추가하는 것은, 그 사용을 이상하게 만드는 몇가지 효과를 초래한다.

 

문제1 - 중복 키 생성

테이블 안의 다른 칼럼이 자연키로 사용될 수 있는 상황에서조차 단지 통념에 따라 id 칼럼을 PK로 정의한 것을 봤을 것이다. 그 다른 칼럼에 UNIQUE 제약조건이 설정되어 있는 경우도 있다. 예를 들어, Bugs 테이블에서는 프로젝트 코드를 앞에 붙여 bug_id를 만들 수 있을 것이다.

CREATE TABLE Bugs (
    id          BIGINT PRIMARY KEY,
    bug_id      VARCHAR(10) UNIQUE,
    description VARCHAR(1000),
    ...
)
INSERT INTO Bugs (bug_id, description, ...)
VALUES ('VIS-018', 'crashes on save', ...)

 

이 예에서 bug_id 칼럼은 각 행을 유일하게 식별할 수 있도록 해준다는 면에서 id와 사용 목적이 동일하다. 그럼 굳이 id가 왜 필요할까?

 

문제2 - 중복 행 허용

복합키는 여러 칼럼을 포함한다. 복합키가 사용되는 전형적인 예는 BugsProducts와 같은 교차 테이블 안에서다. PK는 특정한 bug_idproduct_id 값의 조합이 테이블 안에서 한 번만 나타난다는 것을 보장해야 한다. 각 값이 다른 쌍으로 여러 번 나타날 수 있을지라도 말이다. 그러나, id 칼럼을 PK로 사용하는 경우에는 유일해야 하는 두 칼럼에 제약조건이 적용되지 않는다.

CREATE TABLE BugsProducts
(
    id         BIGINT PRIMARY KEY,
    bug_id     BIGINT NOT NULL,
    product_id BIGINT NOT NULL,
    FOREIGN KEY (bug_id) REFERENCES Bugs (bug_id),
    FOREIGN KEY (product_id) REFERENCES Products (product_id)
)
INSERT INTO BugsProducts (bug_id, product_id)
VALUES (1234, 1), (1234, 1), (1234, 1); -- 중복이 허용됨

BugsProducts를 연결하기 위해 이 교차 테이블을 사용할 때, 중복 때문에 의도하지 않은 결과가 발생한다. 중복을 방지하기 위해서는 id뿐 아니라 다른 두 칼럼에 UNIQUE 제약 조건을 걸어줘야 한다.

CREATE TABLE BugsProducts
(
    id         BIGINT PRIMARY KEY,
    bug_id     BIGINT NOT NULL,
    product_id BIGINT NOT NULL,
    UNIQUE KEY (bug_id, product_id),
    FOREIGN KEY (bug_id) REFERENCES Bugs (bug_id),
    FOREIGN KEY (product_id) REFERENCES Products (product_id)
)

그러나 이 두칼럼에 UNIQUE 제약조건을 걸어야 한다면, id 칼럼은 불필요한 것이다.

 

안티패턴 인식 방법

이 안티패턴의 징후는 쉽게 인식할 수 있다. 테이블에서 PK 칼럼 이름으로 id가 사용되고 있으면 이 안티패턴의 징후로 볼 수 있다. 좀 더 의미 있는 이름 대신 id를 선호해야 할 이유는 없다. 다음과 같은 말 또한 이 안티패턴의 증거가 될 수 있다.

  • "이 테이블에는 PK가 없어도 될 것 같은데." → 이런 말을 하는 개발자는 PK와 가상키 용어의 의미를 혼동하는 것이다. 모든 테이블은 중복 행을 방지하고 각 행을 유일하게 식별하기 위해 PK 제약조건을 가져야 한다. 아마 자연키나 복합키 사용이 필요할 것이다.
  • "다대다 연결에서 왜 중복이 발생했지?" → 다대다 관계를 위한 교차 테이블에는 FK 칼럼을 묶어 PK 제약조건을 걸거나 최소한 UNIQUE 제약조건이라도 걸어줘야 한다.
  • "나는 데이터베이스 이론에서 값은 색인 테이블로 옮기고 ID로 참조해야 한다고 하는 걸 읽었어. 그러나 그렇게 하고 싶지 않아. 내가 원하는 실제 값을 얻기 위해 매번 조인을 해야 하기 때문이지." → 이는 데이터베이스 설계 이론에서 말하는 정규화에 대한 흔한 오해다. 정규화는 가상키와 아무런 상관이 없다.

 

안티패턴 사용이 합당한 경우

일부 객체-관계 프레임워크에서는 CoC(Convention over Configuration)를 통해 개발을 단순화한다. 이런 프레임워크에서는 모든 테이블이 동일한 방식(칼럼 이름은 id고 데이터 타입은 정수인 가상키)으로 PK를 정의한다고 가정한다. 이런 프레임워크를 사용한다면 그 관례를 따르고 싶을 것이다. 그렇게 해야 프레임워크의 다른 원하는 기능을 사용할 수 있기 때문이다. 물론 가상키를 사용하고 자동 증가하는 정수를 사용해 키값을 할당하는 것이 잘못은 아니다. 그러나 모든 테이블에 가상키가 필요한 것도 아니고, 모든 가상키 컬럼 이름을 id로 해야하는 것도 아니다. 가상키는 지나치게 긴 자연키를 대체하기 위해 사용한다면 적절한 선택이다. 예를 들어, 파일 시스템의 파일 속성을 저장하는 테이블에서, 파일 경로는 좋은 자연키가 될 수 있겠지만, 이렇게 긴 문자열을 키로 하면 인덱스를 만들고 유지하는 데 많은 비용이 들 것이다. 

 

해법: 상황에 맞추기

PK는 제약조건이지 데이터 타입이 아니다. 데이터 타입이 인덱스를 지원하기만 하면, 어느 칼럼 또는 칼럼의 묶음에 대해서도 PK를 선언할 수 있다. 또한 테이블의 특정 칼럼을 PK로 잡지 않고도 자동 증가하는 정수값을 가지도록 정의할 수 있다. 이 두 개념은 서로 독립적인 것이다. 좋은 설계 방법에 경직된 관례가 끼어드는 것을 허용하지 말기 바란다.

 

해법: 있는 그대로 말하기

PK에 의미 있는 이름을 선택해야 한다. 이 이름은 PK가 식별하는 엔티티의 타입을 나타내야 한다. 예를 들어, Bugs 테이블의 PK는 bug_id가 되어야 한다. FK에서도 가능하다면 같은 칼럼 이름을 사용해야 한다. 이는 종종 PK 이름이 스키마 내에서 유일해야 함을 뜻한다. 하나가 다른 쪽의 FK가 아닌 한, 동일한 PK 이름이 다른 테이블에 나오면 안된다. 그러나 예외가 있다. 연결의 본질을 더 잘 표현하는 경우라면, FK를 자신이 참조하는 PK 이름과 다르게 하는 것도 괜찮다. 

CREATE TABLE Bugs (
    ....
    reported_by BIGINT NOT NULL,
    FOREIGN KEY (reported_by) REFERENCES Accounts(account_id)
);

 

해법: 자연키와 복합키 포용

유일함이 보장되고, NULL 값을 가지는 경우가 없고, 행을 식별하는 용도로 사용할 수 있는 속성이 테이블에 있다면, 단지 통념을 따르기 위해 가상키를 추가해야 한다는 의무감을 느낄 필요는 없다. 실제로 테이블에 있는 각 속성은 변하기 마련이고, 유일하지 않게 될 수도 있다. 데이터베이스는 프로젝트 기간 동안 변화하며, 결정권자들이 자연키의 신성함을 존중하지 않을 수도 있다. 처음에는 자연키로 손색이 없어 보이던 칼럼이 나중에 알고 보니 적법하게 중복을 허용하는 것으로 밝혀질 수도 있다. 이런 경우에는 가상키를 사용할 수 있다.

 

복합키가 적절한 경우에는 이를 사용하기를 바란다. BugsProducts 테이블에서와 같이 여러 칼럼의 조합으로 행을 가장 잘 식별할 수 있다면, 이 칼럼 조합을 복합키로 사용해야 한다. 

CREATE TABLE BugsProducts
(
    bug_id     BIGINT NOT NULL,
    product_id BIGINT NOT NULL,
    PRIMARY KEY (bug_id, product_id),
    FOREIGN KEY (bug_id) REFERENCES Bugs (bug_id),
    FOREIGN KEY (product_id) REFERENCES Products (product_id)
);
INSERT INTO BugsProducts (bug_id, product_id)
VALUES (1234, 1), (1234, 2), (1234, 3);

INSERT INTO BugsProducts (bug_id, product_id)
VALUES (1234, 1); -- error: duplicate entry

이런식으로 설계했다면, 제일 처음에 봤던 문제인 ArticleTags에서 발생한 중복 문제도 해결할 수 있었을 것이다. 복합 PK를 참조하는 FK또한 복합키가 되어야 함에 유의하기 바란다. 종속되는 테이블에 이렇게 칼럼 조합을 중복해야 하는 것은 안 좋아 보이지만, 장점도 있다. 중복된 칼럼 값을 얻을 때 조인을 안 해도 되기 때문에 쿼리가 단순해진다. 

 

참고로, 복합 PK를 참조하는 FK또한 복합키가 되어야 한다는 말은 이런 것이다.

CREATE TABLE OrderDetail (
    OrderID INT,
    ProductID INT,
    Quantity INT,
    PRIMARY KEY (OrderID, ProductID)
);

이런 OrderDetail 이라는 테이블이 있고 이 테이블의 PK는 OrderID, ProductID 복합키를 가지고 있을 때, 이를 참조하는 테이블에서 FK도 반드시 OrderID, ProductID를 모두 포함해야 한다는 뜻이다.

CREATE TABLE Shipment (
    ShipmentID INT,
    OrderID INT,
    ProductID INT,
    ShipDate DATE,
    PRIMARY KEY (ShipmentID),
    FOREIGN KEY (OrderID, ProductID) REFERENCES OrderDetail(OrderID, ProductID)
);

 

 

SQL AntiPatterns Tip

관례는 도움이 될 때만 좋은 것이다.

728x90
반응형
LIST
728x90
반응형
SMALL

SQL 관련 안티패턴을 공부하고자 마음먹고 새로 산 책인 [SQL AntiPatterns]을 보면서 배운 내용을 정리하려고 한다. 이 책에서 여러 안티 패턴을 설명하고 이 방식이 왜 잘못된건지, 어떤 문제를 야기하는지, 그 해결 방법은 무엇인지 자세하게 설명해주고 있는데 정말 재밌다.

 

참고 저서: [SQL Antipatterns]

 

목표: 다중 값 속성 저장

테이블의 칼럼이 하나의 값을 가질 땐 설계가 쉽다. 그러나 관련된 값의 집합은 어떻게 한 칼럼에 저장할 수 있을까? 예를 들면, 제품과 담당자가 있을 때 한 제품에 여러 담당자가 있을 수 있다. 최초에는 한 제품에는 한명의 담당자만으로 충분했는데 프로젝트가 성숙해가면서 제품의 담당자가 여러 명일 수 있다는 사실을 깨닫는다. 

 

안티패턴: 쉼표로 구분된 목록에 저장

데이터베이스 구조의 변경을 최소화하기 위해, account_id 칼럼을 VARCHAR로 바꾸고, 여기에 여러 개의 계정 아아디를 쉼표로 구분해 나열하기로 했다. 아래와 같이 테이블을 정의한다.

CREATE TABLE Products
(
    product_id   BIGINT PRIMARY KEY,
    product_name VARCHAR(50),
    account_id VARCHAR(100), -- 쉼표로 구분된 목록
    ...
);

 

그리고 이렇게 데이터를 넣어본다.

INSERT INTO Products (product_id, product_name, account_id) 
VALUES (DEFAULT, 'Visual TurboBuilder', '12,34');

 

성공한 것 같다. 테이블을 새로 만들지도 않았고, 칼럼을 추가하지도 않았기 때문이다. 단지 칼럼 하나의 데이터 타입만 바꿨을 뿐이다. 그러나 이 테이블 설계로부터 겪어야 할 성능 문제와 데이터 정합성 문제를 살펴보자.

 

문제1 - 특정 계정에 대한 제품 조회

모든 FK가 하나의 필드에 결합되어 있으면 쿼리가 어려워진다. 더 이상 같은지를 비교할 수 없다. 대신 어떤 패턴에 맞는지를 검사해야 한다. 예를 들어, MySQL에서는 계정 '12'에 대한 제품을 찾기 위해 다음과 같은 쿼리를 사용할 수 있다.

SELECT * FROM Products WHERE account_id REGEXP '[[:<:]]12[[:>:]]';

 

패턴 매칭을 사용하면 잘못된 결과가 리턴될 수 있고 인덱스도 활용하지 못한다. 패턴 매칭 문법은 데이터베이스 제품에 따라 다르기 때문에 이렇게 작성한 SQL은 벤더 중립적이지도 않다. 

 

문제2 - 주어진 제품에 대한 계정 정보 조회

마찬가지로, 쉼표로 구분된 목록을 참조하는 테이블의 대응되는 행과 조인하기도 불편해지고 비용이 많이 든다.

내가 어떤 제품의 ID를 알고 있을 때 이 제품이 가지고 있는 계정 ID를 통해 조인하는 쿼리를 아래와 같이 기괴하게 작성해야 한다.

SELECT * FROM Products AS p JOIN Accounts AS a 
ON p.account_id REGEXP '[[:<:]]' || a.account_id || '[[:>:]]'
WHERE p.product_id = 123;

이런 식의 표현을 사용해 두 테이블을 조인하면 인덱스를 활용할 기회가 사라진다. 이 쿼리는 두 테이블을 모두 읽어 카테시안 곱(Cartesian product)을 생성한 다음, 모든 행의 조합에 대해 정규 표현식을 평가해야 한다.

 

문제3 - 집계 쿼리 만들기

집계 쿼리는 COUNT(), SUM(), AVG()와 같은 함수를 사용한다. 그러나 이런 함수는 행의 그룹에 대해 사용하도록 설계되었지, 쉼표로 구분된 목록에 대해 사용하도록 설계된 것이 아니다. 따라서 다음과 같은 기교에 의지해야 한다.

SELECT product_id, LENGTH(account_id) - LENGTH(REPLACE(account_id, ',', '')) + 1 AS contacts_per_product
FROM Products;

이런 기교는 교묘하긴 하지만 명확하지 않다. 솔직히 쿼리를 딱 봤을때 이게 뭔지 한번에 알 수 있는 사람이 몇이나 될까? 이런 해법은 개발하는 데 시간도 오래 걸리고 디버깅하기도 어렵다. 심지어, 어떤 집계 쿼리는 이런 기교로도 만들어낼 수 없다. 

 

문제4 - 특정 제품에 대한 계정 갱신

목록의 마지막에 문자열 연결을 통해 새로운 아이디를 추가할 수 있지만, 이렇게 하면 목록이 정렬된 상태로 유지되지 않는다. 

UPDATE Products
SET account_id = account_id || ',' || 56
WHERE product_id = 123;

 

목록에서 항목을 삭제하려면 두 개의 SQL 쿼리를 실행해야 한다. 하나는 예전 목록을 불러오는 데, 다른 하나는 목록을 갱신하기 위해 필요하다. 

 

문제5 - 제품 아이디 유효성 검증

사용자가 'banana'와 같은 유효하지 않은 항목을 입력하는 것을 어떻게 방지할 수 있을까? 

INSERT INTO Products (product_id, product_name, account_id) 
VALUES (DEFALUT, 'Visual TurboBuilder', '12,34,banana');

사용자들은 유효하지 않은 값을 입력하는 방법을 찾아낼 것이고, 데이터베이스는 쓰레기 더미가 될 것이다. 데이터베이스에서 에러가 발생하지는 않지만, 데이터는 의미 없는 것이 될 것이다.

 

문제6 - 구분자 문자 선택

정수 목록 대신 문자열 목록을 저장하는 경우 목록의 일부 항목이 구분자 문자를 포함할 수 있다. 항목 간의 구분자로 쉼표를 사용하면 모호해질 수 있다. 구분자로 다른 문자를 사용할 수도 있으나, 이 새로운 구분자가 항목에 절대 안 나온다고 보장할 수 있을까?

 

문제7 - 목록 길이 제한

VARCHAR(30) 칼럼에 얼마나 많은 목록 항목을 저장할 수 있을까? 각 항목의 길이에 따라 다르다. 각 항목의 길이가 2라면(쉼표 포함) 항목을 열 개 저장할 수 있다. 그러나 각 항목의 길이가 6이라면 항목을 네 개 저장할 수 있을 뿐이다.

UPDATE Products 
SET account_id = '10,14,18,22,26,30,34,38,42,46'
WHERE product_id = 123;
UPDATE Products 
SET account_id = '101418,222630,343842,467790'
WHERE product_id = 123;

 

VARCHAR(30)이 미래에 필요한 가장 긴 목록을 지원할 수 있는지 어떻게 알 수 있겠는가? 얼마나 길게 하면 충분할까? 이런 길이 제한에 대한 이유를 상사나 고객에게 설명해보기 바란다.

 

안티패턴 인식 방법

프로젝트 팀에서 다음과 같은 말이 나온다면, 이 안티패턴이 사용되고 있음을 나타내는 단서로 간주할 수 있다.

  • "이 목록이 지원해야 하는 최대 항목 수는 얼마나 될까?" → VARCHAR 칼럼의 최대 길이를 선정하려 할 때 이런 질문이 나온다.
  • "SQL에서 단어의 경계를 어떻게 알아내는지 알아?" → 문자열의 일부를 찾아내기 위해 정규 표현식을 사용한다면, 이런 부분을 별도로 저장해야 함을 뜻하는 단서일 수 있다.  
  • "이 목록에서 절대 나오지 않을 문자가 어떤 게 있을까?" → 모호하지 않은 문자를 구분자로 사용하고 싶겠지만, 어떤 구분자를 사용하든 언젠가는 그 문자가 목록의 값에 나타날 것이라 예상해야 한다.

 

안티패턴 사용이 합당한 경우

어떤 종류의 쿼리는 데이터베이스에 반정규화를 적용해 성능을 향상시킬 수 있다. 목록을 쉼표로 구분된 문자열로 저장하는 것도 반정규화의 예다. 애플리케이션에서 쉼표로 구분된 형식의 데이터를 필요로 하고, 목록 안의 개별 항목에는 접근할 필요가 없을 수 있다. 비슷하게 애플리케이션이 다른 출처에서 쉼표로 구분된 형식으로 데이터를 받아 데이터베이스에 그대로 저장하고 나중에 동일한 형식으로 불러내야 하며, 목록 안의 개별 값을 분리할 필요가 없다면 안티패턴을 사용할 수 있다.

 

반정규화를 사용하기로 결정할 때는 보수적이어야 한다. 데이터베이스를 정규화하는 것이 먼저다. 정규화는 애플리케이션 코드를 좀 더 융통성 있게 하고, 데이터베이스의 정합성을 유지할 수 있게 한다.

 

해법: 교차 테이블 생성

account_idProducts 테이블에 저장하는 대신, 별도의 테이블에 저장해 account_id가 별도의 행을 차지하도록 하는 것이 좋다. 이 새로 만든 Contacts 테이블은 ProductsAccounts 사이의 다대다 관계를 구현한다.

 

CREATE TABLE Contacts
(
    product_id BIGINT NOT NULL,
    account_id BIGINT NOT NULL,
    PRIMARY KEY (product_id, account_id),
    FOREIGN KEY (product_id) REFERENCES Products (product_id),
    FOREIGN KEY (account_id) REFERENCES Accounts (account_id)
);
INSERT INTO Contacts (product_id, account_id)
VALUES (123, 12), (123, 34),
       (345, 23), (567, 12),
       (567, 34);

 

어떤 테이블이 FK로 두 테이블을 참조할 때 이를 교차 테이블이라 한다. 교차 테이블은 참조되는 두 테이블 사이의 다대다 관계를 구현한다. 즉 각 제품은 교차 테이블을 통해 여러 개의 계정과 연관되며, 마찬가지로 각 계정은 여러 개의 제품과 연관된다. 안티패턴의 문제가 이 교차 테이블을 사용하면 어떻게 해결될 수 있는지 살펴보자.

 

문제1, 2 타파 - 계정으로 제품 조회하기와 제품으로 계정 조회하기

주어진 계정에 대한 모든 제품의 속성을 조회하려면, Products 테이블과 Contacts 테이블을 조인하면 된다.

SELECT p.*
FROM Products AS p JOIN Contacts AS c
ON (p.product_id = c.product_id)
WHERE c.account_id = 34;

 

어떤 사람들은 조인을 포함한 쿼리를 거부하는데, 성능이 나쁘다고 생각하기 때문이다. 그러나 이 쿼리는 안티패턴에서 문제를 어떻게 어떻게 해결하려 본 방법보다 인덱스를 훨씬 잘 사용한다. 마찬가지로 계정 상세 정보를 조회하는 쿼리도 읽기 쉽고 최적화하기도 쉽다.

SELECT a.*
FROM Accounts AS a JOIN Contacts AS c
ON (a.account_id = c.account_id)
WHERE c.products_id = 123;

 

문제3 타파 - 집계 쿼리 만들기

다음 쿼리는 제품당 계정 수를 리턴한다.

SELECT product_id, COUNT(*) AS accounts_per_product
FROM Contacts
GROUP BY product_id;

 

계정당 제품 수를 구하는 것도 마찬가지로 간단하다.

SELECT account_id, COUNT(*) products_per_account
FROM Contacts
GROUP BY account_id;

 

가장 많은 담당자를 할당 받은 제품을 구하는 것과 같이 좀 더 복잡한 리포트를 만드는 것도 가능하다.

SELECT c.product_id, c.contacts_per_product
FROM (
    SELECT product_id, COUNT(*) AS contacts_per_product
    FROM Contacts
    GROUP BY product_id
) AS c
ORDER BY c.contacts_per_product DESC LIMIT 1

 

문제4 타파 - 특정 제품에 대한 계정 갱신 

목록에 항목을 추가하거나 삭제하는 것은 교차 테이블에 행을 삽입하거나 삭제하는 방법으로 할 수 있다. 각 제품에 대한 참조는 Contacts 테이블에 별도의 행으로 저장되므로, 한번에 하나씩 추가 또는 삭제할 수 있다. 

INSERT INTO Contacts (product_id, account_id) VALUES (456, 34);

DELETE FROM Contacts WHERE product_id = 456 AND account_id = 34;

 

문제5 타파 - 제품 아이디 유효성 검증

어떤 항목이 다른 테이블에 있는 합당한 값에 대해 유효한지를 확인하기 위해 FK를 사용할 수 있다. Contacts.account_idAccounts.account_id를 참조하도록 선언해, 참조 정합성을 데이터베이스가 강제하도록 할 수 있다. 이렇게 하면 교차 테이블에는 실제로 존재하는 계정 아이디만 들어있음을 확신할 수 있다. 

 

항목을 제한하는 데 SQL 데이터 타입을 사용할 수도 있다. 예를 들어, 목록에 들어갈 항목이 유효한 INTEGER 또는 DATE 값이어야 하고, 해당 칼럼이 이 데이터 타입을 사용하도록 선언했다면, 모든 항목이 해당 타입의 유효한 값이라 확신할 수 있다. 즉, `banana`와 같은 무의미한 값이 없다고 확신할 수 있다. 

 

문제6 타파 - 구분자 문자 선택

각 항목을 별도의 행으로 저장하므로, 구분자를 사용하지 않는다. 쉼표나 구분자로 사용하는 다른 문자가 항목에 포함되어 있을지 걱정할 필요가 없다.

 

문제7 타파 - 목록 길이 제한

각 항목이 교차 테이블에 별도 행으로 존재하기 때문에, 한 테이블에 물리적으로 저장할 수 있는 행 수에만 제한을 받는다. 항목 수를 제한하는 것이 적당하다면, 목록의 항목을 합한 길이를 보는 것보다는 애플리케이션에서 항목 수를 세어 이 정책을 강제해야 한다.

 

교차 테이블의 다른 장점

Contacts.account_id에 걸린 인덱스를 활용하면 쉼표로 구분된 목록에서 부분 문자열 매칭하는 것보다 성능이 좋아진다. 칼럼에 FK를 선언하면 많은 데이터베이스가 내부적으로 해당 칼럼에 대한 인덱스를 생성한다. (그러나 확실한 건 해당 데이터베이스 문서를 확인)

 

또한, 교차 테이블에 칼럼을 추가해 각 항목에 추가 속성을 넣을 수 있다. 예를 들어, 주어진 제품에 담당자가 할당된 날짜를 저장하거나, 누가 주 담당자이고 누가 부 담당자인지를 표시하는 속성을 추가할 수 있다. 

728x90
반응형
LIST

'SQL AntiPatterns' 카테고리의 다른 글

2. PK 관례 확립: 만능키  (6) 2024.12.30
728x90
반응형
SMALL

이전 포스팅까지는 Querydsl의 기본 사용 방법에 대해 쭉 정리를 해봤는데, 이제 그 지식을 바탕으로 실무에 가까운 코드를 작성해보자.

먼저, 순수한 JPA 레포지토리와 Querydsl을 사용해보고, 이후에 스프링 데이터 JPAQuerydsl을 사용해보는 것도 하나씩 해보자.

 

순수 JPA 레포지토리와 Querydsl

MemberJpaRepository

package cwchoiit.querydsl.repository;

import com.querydsl.jpa.impl.JPAQueryFactory;
import cwchoiit.querydsl.entity.Member;
import jakarta.persistence.EntityManager;
import lombok.RequiredArgsConstructor;
import org.springframework.stereotype.Repository;

import java.util.List;
import java.util.Optional;

import static cwchoiit.querydsl.entity.QMember.member;

@Repository
@RequiredArgsConstructor
public class MemberJpaRepository {

    private final EntityManager em;
    private final JPAQueryFactory queryFactory;

    public void save(Member member) {
        em.persist(member);
    }

    public Optional<Member> findById(Long id) {
        return Optional.ofNullable(em.find(Member.class, id));
    }

    public List<Member> findAll() {
        return em.createQuery("select m from Member m", Member.class)
                .getResultList();
    }

    public List<Member> findAllQuerydsl() {
        return queryFactory
                .selectFrom(member)
                .fetch();
    }

    public List<Member> findByUsername(String username) {
        return em.createQuery("select m from Member m where m.username = :username", Member.class)
                .setParameter("username", username)
                .getResultList();
    }

    public List<Member> findByUsernameQuerydsl(String username) {
        return queryFactory
                .selectFrom(member)
                .where(member.username.eq(username))
                .fetch();
    }
}
  • 순수 JPA 레포지토리는 워낙 많이 만들어봤기 때문에 다른 설명이 필요없다. 그런데 이 레포지토리에서 Querydsl을 사용하기 위해 JPAQueryFactory를 주입받는 방법이 취향차이인데, 지금 방식은 빈으로 등록해서 주입받는 방법이다. 빈으로는 어디에 등록했나? 빈을 등록할 수 있는 어디든 상관은 없다. 나의 경우 엔트리 클래스에 했다. 아래 코드처럼.
package cwchoiit.querydsl;

import com.querydsl.jpa.impl.JPAQueryFactory;
import jakarta.persistence.EntityManager;
import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.context.annotation.Bean;

@SpringBootApplication
public class QuerydslApplication {

    public static void main(String[] args) {
        SpringApplication.run(QuerydslApplication.class, args);
    }

    @Bean
    public JPAQueryFactory jpaQueryFactory(EntityManager em) {
        return new JPAQueryFactory(em);
    }
}
  • 빈으로 JPAQueryFactory를 등록해서 여기저기 주입받아 사용한다. 그럼 여기서 의문이 든다. 동시성 문제가 있지 않을까? 그 걱정은 하지 않아도 된다. 왜냐하면 여기서 스프링이 주입해주는 엔티티 매니저는 실제 동작 시점에 진짜 엔티티 매니저를 찾아주는 프록시 엔티티 매니저를 주입해준다. 이 프록시가 실제 사용 시점에 트랜잭션 단위로 실제 엔티티 매니저를 할당해준다.
  • 이렇게 빈으로 등록하고 주입받는 방법을 사용해도 되고, 아래와 같이 사용해도 상관없다.
@Repository
public class MemberJpaRepository {

    private final EntityManager em;
    private final JPAQueryFactory queryFactory;

    public MemberJpaRepository(EntityManager em) {
        this.em = em;
        this.queryFactory = new JPAQueryFactory(em);
    }
    
    ...
}
  • 각자 장단점이 있는데, 이렇게 생성자에서 new로 새로 만들어내는 방법은 테스트 코드를 작성할 때 더 편리하다. 빈으로 등록한 것을 주입 시킬 필요가 없으니까. 근데 이제 실제 코드에서 생성자를 만드는 코드를 작성하는 게 좀 귀찮아진다. 

 

그리고, findAll(), findByUsername() 이 두 메서드를 보면 Querydsl로 만든 버전이 있고 순수 JPA로 만든 버전이 있는데 차이가 명확하다.

public List<Member> findAll() {
    return em.createQuery("select m from Member m", Member.class)
            .getResultList();
}

public List<Member> findAllQuerydsl() {
    return queryFactory
            .selectFrom(member)
            .fetch();
}

public List<Member> findByUsername(String username) {
    return em.createQuery("select m from Member m where m.username = :username", Member.class)
            .setParameter("username", username)
            .getResultList();
}

public List<Member> findByUsernameQuerydsl(String username) {
    return queryFactory
            .selectFrom(member)
            .where(member.username.eq(username))
            .fetch();
}
  • 순수 JPA로 작성하려면 JPQL을 작성해줘야 하는데 이 부분에서 실수를 해도 컴파일 시점에 그 부분을 잡아내지는 못한다. 왜냐? 단순 문자열이니까. 그렇지만 Querydsl을 사용하는 경우, 컴파일 시점에 문제를 다 잡아낼 수 있다. 왜냐? 자바 코드니까.
  • 또 한가지는, 파라미터 바인딩 코드가 Querydsl은 필요가 없다. 
  • Querydsl을 사용하면 여러모로 장점이 참 많다.

 

동적 쿼리와 성능 최적화 조회 - Builder 사용

동적 쿼리가 존재하는 순수 JPA 레포지토리도 만들어보고, 극한의 최적화를 위해 딱 필요한 것만 조회해오는 DTO로 성능 최적화를 해보자.

MemberTeamDto

package cwchoiit.querydsl.dto;

import com.querydsl.core.annotations.QueryProjection;
import lombok.Data;

@Data
public class MemberTeamDto {

    private Long memberId;
    private String username;
    private int age;
    private Long teamId;
    private String teamName;

    @QueryProjection
    public MemberTeamDto(Long memberId, String username, int age, Long teamId, String teamName) {
        this.memberId = memberId;
        this.username = username;
        this.age = age;
        this.teamId = teamId;
        this.teamName = teamName;
    }
}
  • 쿼리를 날릴 때 SELECT절에 딱 필요한 데이터만 메모리에 퍼올리기 위해 원하는 필드만 있는 DTO를 만들었다.
  • 그리고, @QueryProjection을 사용해서, Querydsl을 사용할 때 DTO를 편리하게 사용할 수 있게 했다.

MemberSearchCondition

package cwchoiit.querydsl.dto;

import lombok.Data;

@Data
public class MemberSearchCondition {

    private String username;
    private String teamName;
    private Integer ageGoe;
    private Integer ageLoe;
}
  • 동적 쿼리에 사용될 조건 객체를 만들었다.

MemberJpaRepository 일부분

public List<MemberTeamDto> searchByBuilder(MemberSearchCondition condition) {

    BooleanBuilder builder = new BooleanBuilder();

    if (StringUtils.hasText(condition.getUsername())) {
        builder.and(member.username.eq(condition.getUsername()));
    }

    if (StringUtils.hasText(condition.getTeamName())) {
        builder.and(team.name.eq(condition.getTeamName()));
    }

    if (condition.getAgeGoe() != null) {
        builder.and(member.age.goe(condition.getAgeGoe()));
    }

    if (condition.getAgeLoe() != null) {
        builder.and(member.age.loe(condition.getAgeLoe()));
    }

    return queryFactory
            .select(new QMemberTeamDto(
                    member.id.as("memberId"),
                    member.username,
                    member.age,
                    team.id.as("teamId"),
                    team.name.as("teamName")))
            .from(member)
            .leftJoin(member.team, team)
            .where(builder)
            .fetch();
}
  • BooleanBuilder를 사용해서 동적 쿼리를 먼저 만들어봤다. 이전에도 이 녀석을 사용해보고 이후에 WHERE 다중 파라미터 방식을 했던것처럼 이번에도 그렇게 해보자.
  • BooleanBuilder를 사용해도 코드가 나쁘지 않다. 느낌은 JDBC를 사용해서 동적 쿼리를 만들어내는 거랑 비슷한데, 확연히 다른 점은 단순 문자열로 동적 쿼리를 만들어내는 게 아니란 점이다. 이게 정말 가장 강력한 장점이다.
  • 한가지 위 코드에는 오점이 있다. 오점이라기 보단 불 필요한 부분. 바로 SELECT절에 퍼올리는 데이터에 as(...)로 별칭을 주는 부분이다. 저렇게 작성한 이유는 데이터베이스에는 MemberID 필드가 `member_id`인데 DTO`memberId`이기 때문에 기본적으로 저렇게 별칭을 주는게 맞다. 근데 저건 Q클래스의 DTO이고 생성자이다. 즉, 필드가 들어가는 순서가 명확하고 어떤 타입인지도 이미 컴파일러는 알고 있으며, 생성자를 사용해 DTO 타입의 객체를 만들어내기 때문에 저렇게 할 필요가 없다. 그러니까 아래처럼 작성해도 된다.
return queryFactory
    .select(new QMemberTeamDto(
            member.id,
            member.username,
            member.age,
            team.id,
            team.name))
    .from(member)
    .leftJoin(member.team, team)
    .where(builder)
    .fetch();

 

그러나, 이 BooleanBuilder를 사용하는 것보다 무조건 WHERE절 다중 파라미터를 사용하는 게 더 좋다. 일단 코드를 보면 무슨말인지 확 이해가 된다.

 

동적 쿼리와 성능 최적화 조회 - WHERE절 다중 파라미터 사용

public List<MemberTeamDto> search(MemberSearchCondition condition) {
    return queryFactory
            .select(new QMemberTeamDto(
                    member.id,
                    member.username,
                    member.age,
                    team.id,
                    team.name))
            .from(member)
            .leftJoin(member.team, team)
            .where(usernameEq(condition.getUsername()),
                   teamNameEq(condition.getTeamName()),
                   ageGoe(condition.getAgeGoe()),
                   ageLoe(condition.getAgeLoe()))
            .fetch();
}

private BooleanExpression usernameEq(String username) {
    return StringUtils.hasText(username) ? member.username.eq(username) : null;
}

private BooleanExpression teamNameEq(String teamName) {
    return StringUtils.hasText(teamName) ? team.name.eq(teamName) : null;
}

private BooleanExpression ageGoe(Integer ageGoe) {
    return ageGoe != null ? member.age.goe(ageGoe) : null;
}

private BooleanExpression ageLoe(Integer ageLoe) {
    return ageLoe != null ? member.age.loe(ageLoe) : null;
}
  • 같은 코드가 이렇게 바뀌었다. 쿼리만 따로 보면 이렇다.
public List<MemberTeamDto> search(MemberSearchCondition condition) {
    return queryFactory
            .select(new QMemberTeamDto(
                    member.id,
                    member.username,
                    member.age,
                    team.id,
                    team.name))
            .from(member)
            .leftJoin(member.team, team)
            .where(usernameEq(condition.getUsername()),
                   teamNameEq(condition.getTeamName()),
                   ageGoe(condition.getAgeGoe()),
                   ageLoe(condition.getAgeLoe()))
            .fetch();
}
  • 이게 가장 큰 장점이 뭐냐? 쿼리가 읽힌다는 점이다. 동적 쿼리를 처리하는 방법은 다양하다. JDBC를 사용해서 동적쿼리를 처리하나 위에서 다뤘던 BooleanBuilder를 사용하나 쿼리만 딱 봤을 때 어떤 쿼리가 나갈지 예상하기 쉽지 않다. 위에 "어떤 코드가 있나~?" 하고 보고 내려와야 하니까. 
  • 그런데 이 방식은 그럴 필요가 없다. 쿼리만 봐도 어떤 쿼리가 나갈지 그냥 눈에 보인다. 이게 정말 정말 큰 장점이다. 그리고 또 하나의 장점은 조건에 사용되는 usernameEq, teamNameEq, ageGoe, ageLoe 와 같은 메서드는 메서드이기 때문에 재사용이 가능하다는 점이다. 다른 동적 쿼리를 작성할 때 이렇게 범용적으로 사용될 것 같은 조건들은 또 사용될 가능성이 높다. 그럴때 그냥 만들어 둔 이 녀석들을 가져다가 사용하면 된다. 
  • 또다른 장점은, 각 메서드를 조합하는 게 가능하다는 점이다. 다 이전 포스팅에서 다뤘던 내용이지만 한번 더 강조하고자 말하는 중이니 어떻게 조합한다는 거지?에 대한 의문은 이전 포스팅이 해결해 줄 것이다.

 

조회 API 컨트롤러 개발

이제 이 동적쿼리를 실제로 어디선가 호출하는 그런 케이스를 만들어보자. REST API로 어떤 데이터를 조회할 때 저 동적 쿼리가 사용된다고 가정해보는 것이다. 이걸 테스트해보기 위해서는 더미데이터가 데이터베이스에 좀 있어야 한다. 그래서 이 부분을 먼저 좀 처리해보자.

 

우선, 프로파일을 나눠서 테스트 코드에는 영향이 끼치지 않도록 아래와 같이 해보자.

 

`src/main/resources/application.yaml`

spring:
  profiles:
    active: local
...

 

`src/test/resources/application.yaml`

spring:
  profiles:
    active: test
...

 

InitMember

package cwchoiit.querydsl.controller;

import cwchoiit.querydsl.entity.Member;
import cwchoiit.querydsl.entity.Team;
import jakarta.annotation.PostConstruct;
import jakarta.persistence.EntityManager;
import lombok.RequiredArgsConstructor;
import org.springframework.context.annotation.Profile;
import org.springframework.stereotype.Component;
import org.springframework.transaction.annotation.Transactional;

@Profile("local")
@Component
@RequiredArgsConstructor
public class InitMember {

    private final InitMemberService memberService;

    @PostConstruct
    public void init() {
        memberService.init();
    }

    @Component
    @RequiredArgsConstructor
    static class InitMemberService {
        private final EntityManager em;

        @Transactional
        public void init() {
            Team teamA = new Team("teamA");
            Team teamB = new Team("teamB");
            em.persist(teamA);
            em.persist(teamB);

            for (int i = 0; i < 100; i++) {
                Team selectedTeam = i % 2 == 0 ? teamA : teamB;
                em.persist(new Member("member"+i, i, selectedTeam));
            }
        }
    }
}
  • 이 클래스는 오직 프로파일이 `local`인 경우에만 살아있을 것이다. @Profile("local") 애노테이션을 달았기 때문이다.
  • 그리고, @PostConstruct 애노테이션을 사용해서, 스프링 띄우고 바로 호출되도록 했다. 뭘 바로 호출해야 하냐? 가 데이터를 만드는 작업이다. 
  • 그런데, 가 데이터를 만들 땐 트랜잭션이 필요하다. 그래서 @Transactional@PostConstruct를 분리해야 한다. 이 둘은 동시에 적용될 수 없다. 
  • 이렇게 가 데이터를 만들게 하고 나서, 컨트롤러 하나를 추가해보자.

MemberController

package cwchoiit.querydsl.controller;

import cwchoiit.querydsl.dto.MemberSearchCondition;
import cwchoiit.querydsl.dto.MemberTeamDto;
import cwchoiit.querydsl.repository.MemberJpaRepository;
import lombok.RequiredArgsConstructor;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RestController;

import java.util.List;

@RestController
@RequiredArgsConstructor
public class MemberController {

    private final MemberJpaRepository memberJpaRepository;

    @GetMapping("/v1/members")
    public List<MemberTeamDto> searchMembersV1(MemberSearchCondition condition) {
        return memberJpaRepository.search(condition);
    }
}
  • 컨트롤러 하나를 간단히 만들고, 파라미터로 위에서 동적 쿼리 조건 처리할 때 사용하는 MemberSearchCondition을 사용했다.

 

이제 이 API를 호출해보자.

### GET Members
GET http://localhost:8080/v1/members?teamName=teamB&ageGoe=31&ageLoe=50&username=member49

 

스프링 데이터 JPAQuerydsl

이제 순수 JPA 레포지토리를 스프링 데이터 JPA로 변경해보자.

 

MemberRepository

package cwchoiit.querydsl.repository;

import cwchoiit.querydsl.entity.Member;
import org.springframework.data.jpa.repository.JpaRepository;

import java.util.List;

public interface MemberRepository extends JpaRepository<Member, Long> {
    List<Member> findByUsername(String username);
}
  • 스프링 데이터 JPA로 변경하려면 이렇게 만들면 끝난다. 기존에 있던, save(), findAll(), findById()와 같은 공통 메서드들은 이미 스프링 데이터 JPA는 다 만들어서 제공해주기 때문에 그런 공통 메서드가 아닌 findByUsername()만 만들면 되는데 이마저도 스프링 데이터 JPA가 제공하는 메서드 쿼리 기능을 사용해서 시그니처만으로 끝낼 수 있다.
  • 문제는 Querydsl을 사용했던 부분들이다. 걔네들은 어떻게 구현하면 될까?

 

사용자 정의 레포지토리

Querydsl을 사용하려면 구현 코드를 작성해야 하는데, 스프링 데이터 JPA는 인터페이스이기 때문에 조금 복잡한 과정이 필요하다.

 

1. 사용자 정의 인터페이스 작성

package cwchoiit.querydsl.repository;

import cwchoiit.querydsl.dto.MemberSearchCondition;
import cwchoiit.querydsl.dto.MemberTeamDto;

import java.util.List;

public interface MemberQuerydslRepository {
    List<MemberTeamDto> search(MemberSearchCondition condition);
}
  • 인터페이스 이름은 원하는대로 만들면 된다. 그리고, 이전에 순수 JPA 레포지토리에서 만들었던 search()를 그대로 만들어준다.

2. 사용자 정의 인터페이스 구현

package cwchoiit.querydsl.repository;

import com.querydsl.core.types.dsl.BooleanExpression;
import com.querydsl.jpa.impl.JPAQueryFactory;
import cwchoiit.querydsl.dto.MemberSearchCondition;
import cwchoiit.querydsl.dto.MemberTeamDto;
import cwchoiit.querydsl.dto.QMemberTeamDto;
import lombok.RequiredArgsConstructor;
import org.springframework.util.StringUtils;

import java.util.List;

import static cwchoiit.querydsl.entity.QMember.member;
import static cwchoiit.querydsl.entity.QTeam.team;

@RequiredArgsConstructor
public class MemberQuerydslRepositoryImpl implements MemberQuerydslRepository {

    private final JPAQueryFactory queryFactory;

    @Override
    public List<MemberTeamDto> search(MemberSearchCondition condition) {
        return queryFactory
                .select(new QMemberTeamDto(
                        member.id,
                        member.username,
                        member.age,
                        team.id,
                        team.name))
                .from(member)
                .leftJoin(member.team, team)
                .where(usernameEq(condition.getUsername()),
                        teamNameEq(condition.getTeamName()),
                        ageGoe(condition.getAgeGoe()),
                        ageLoe(condition.getAgeLoe()))
                .fetch();
    }

    private BooleanExpression usernameEq(String username) {
        return StringUtils.hasText(username) ? member.username.eq(username) : null;
    }

    private BooleanExpression teamNameEq(String teamName) {
        return StringUtils.hasText(teamName) ? team.name.eq(teamName) : null;
    }

    private BooleanExpression ageGoe(Integer ageGoe) {
        return ageGoe != null ? member.age.goe(ageGoe) : null;
    }

    private BooleanExpression ageLoe(Integer ageLoe) {
        return ageLoe != null ? member.age.loe(ageLoe) : null;
    }
}
  • 구현체를 만들고, 순수 JPA 레포지토리에서 만들었던 그 메서드를 그대로 가져와보자. 

3. 스프링 데이터 레포지토리에 사용자 정의 인터페이스 상속

package cwchoiit.querydsl.repository;

import cwchoiit.querydsl.entity.Member;
import org.springframework.data.jpa.repository.JpaRepository;

import java.util.List;

public interface MemberRepository extends JpaRepository<Member, Long>, MemberQuerydslRepository {
    List<Member> findByUsername(String username);
}
  • 스프링 데이터 JPA 레포지토리에 위에서 만든 우리의 커스텀 레포지토리를 상속시키면 끝이다.

 

스프링 데이터 페이징 활용1 - Querydsl 페이징 연동

  • Querydsl을 사용하면서 스프링 데이터의 Page, Pageable을 활용해보자.
package cwchoiit.querydsl.repository;

import cwchoiit.querydsl.dto.MemberSearchCondition;
import cwchoiit.querydsl.dto.MemberTeamDto;
import org.springframework.data.domain.Page;
import org.springframework.data.domain.Pageable;

import java.util.List;

public interface MemberQuerydslRepository {
    List<MemberTeamDto> search(MemberSearchCondition condition);
    Page<MemberTeamDto> search(MemberSearchCondition condition, Pageable pageable);
}
  • 우선, 반환타입이 Page<MemberTeamDto>이고, 파라미터로 Pageable을 받는 메서드를 하나 추가한다.
  • 이제 이 녀석을 새로 구현하면 된다.
@Override
public Page<MemberTeamDto> search(MemberSearchCondition condition, Pageable pageable) {
    List<MemberTeamDto> contents = queryFactory
            .select(new QMemberTeamDto(
                    member.id,
                    member.username,
                    member.age,
                    team.id,
                    team.name))
            .from(member)
            .leftJoin(member.team, team)
            .where(usernameEq(condition.getUsername()),
                    teamNameEq(condition.getTeamName()),
                    ageGoe(condition.getAgeGoe()),
                    ageLoe(condition.getAgeLoe()))
            .offset(pageable.getOffset())
            .limit(pageable.getPageSize())
            .fetch();

    List<String> totalContents = queryFactory
            .select(member.username)
            .from(member)
            .where(usernameEq(condition.getUsername()),
                    teamNameEq(condition.getTeamName()),
                    ageGoe(condition.getAgeGoe()),
                    ageLoe(condition.getAgeLoe()))
            .fetch();

    return new PageImpl<>(contents, pageable, totalContents.size());
}
  • 이전에는 fetchResults()라는 메서드를 사용하면, 데이터와 전체 개수를 같이 받아오는 메서드가 있었는데 이제는 Deprecated됐다. 그래서 데이터를 가져오는 쿼리와 카운트 쿼리를 따로 날려야 한다. 그리고 이후에 설명하겠지만 이게 맞다.
  • 위 코드를 보면, 파라미터로 받은 Pageable에서 offset, limit을 뽑아올 수가 있다. Querydsl을 사용해서 그냥 offset, limit을 넣어주면 페이징은 끝이다.
  • 그럼 카운트 쿼리를 자세히 보자. 이게 중요하다.
List<String> totalContents = queryFactory
                .select(member.username)
                .from(member)
                .where(usernameEq(condition.getUsername()),
                        teamNameEq(condition.getTeamName()),
                        ageGoe(condition.getAgeGoe()),
                        ageLoe(condition.getAgeLoe()))
                .fetch();
  • 카운트 쿼리를 보니, 데이터를 가져오는 쿼리랑 다르다. 조인도 안하고 있고, SELECT절에서 가져오는 것들도 다르다. 이게 최대한의 성능 최적화를 할 수 있는 방법이다. 전체 개수를 가져오는 쿼리는 생각보다 굉장히 무겁다. 데이터가 100백만건이면 그 데이터를 메모리에 퍼 올리는 것만으로도 문제가 될 수 있다. 거기에 더해서, 조인을 하고 SELECT절에 필요하지 않은 데이터까지 다 퍼올리면 이 부분도 성능에 마이너스 요소이다. 
  • LEFT JOIN을 하면 전체 개수는 LEFT JOIN을 아예 하지 않아도 동일하다. 어차피 조인한 결과가 없으면 빈 값으로 그대로 레코드를 가져오기 때문이다. 그래서 굳이 조인을 하지 않아도 전체 개수에 아무런 영향을 끼치지 않는다.
  • 또한, SELECT절에는 다른 데이터가 전혀 필요없이 딱 하나만 있어도 전체 개수에 아무런 영향을 끼치지 않는다. 그래서 굳이 데이터를 가져오는 쿼리에서 봤던 여러 다른 데이터를 가져올 필요가 없다. 
  • 이렇게 전체 개수를 가져오는 쿼리를 최적화할 수 있으면 해야 한다. 매번 이렇게 할 수 있는건 아니지만 가능하면 반드시 해야 한다.
return new PageImpl<>(contents, pageable, totalContents.size());
  • 이제 반환을 하면 된다. 첫번째 파라미터는 contents, 두번째 파라미터는 pageable, 세번째 파라미터는 전체 개수를 받는다. 
  • 이것 또한, 최적화가 가능하다. 다음과 같이 말이다.
JPAQuery<String> countQuery = queryFactory
                .select(member.username)
                .from(member)
                .where(usernameEq(condition.getUsername()),
                        teamNameEq(condition.getTeamName()),
                        ageGoe(condition.getAgeGoe()),
                        ageLoe(condition.getAgeLoe()));

return PageableExecutionUtils.getPage(contents, pageable, () -> countQuery.fetch().size());
  • PageableExecutionUtils.getPage()를 사용하면 어떤 최적화가 가능하냐면, contents를 가져왔을 때 전체 개수 쿼리를 날릴 필요가 없으면 날리지 않는다. 엥? 어떤 경우에 이럴까? 예를 들어 한 페이지의 개수가 100개인 페이징 쿼리를 날렸는데 한 페이지에 데이터가 3개만 들어왔다. 이 말은 그 쿼리 자체의 전체 개수가 3개라는 말이다. 그럼 카운트 쿼리를 날릴 필요없이 그냥 전체 개수는 3인 것이다. 

 

스프링 데이터 페이징 활용2 - 컨트롤러 개발

package cwchoiit.querydsl.controller;

import cwchoiit.querydsl.dto.MemberSearchCondition;
import cwchoiit.querydsl.dto.MemberTeamDto;
import cwchoiit.querydsl.repository.MemberRepository;
import lombok.RequiredArgsConstructor;
import org.springframework.data.domain.Page;
import org.springframework.data.domain.Pageable;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RestController;

import java.util.List;

@RestController
@RequiredArgsConstructor
public class MemberController {

    private final MemberRepository memberRepository;

    @GetMapping("/v1/members")
    public List<MemberTeamDto> searchMembersV1(MemberSearchCondition condition) {
        return memberRepository.search(condition);
    }

    @GetMapping("/v2/members")
    public Page<MemberTeamDto> searchMembersV2(MemberSearchCondition condition, Pageable pageable) {
        return memberRepository.search(condition, pageable);
    }
}
  • searchMembersV2()를 보자. 페이징 처리가 가능한 REST API를 만들었다.
  • 우리가 위에서 만든 Querydsl을 사용해서 페이징 쿼리를 날려보자.
### GET Members
GET http://localhost:8080/v2/members?page=0&size=200
  • 의도적으로 한 페이지에 200개를 가져오게 해봤다. 위에서 말한대로, 카운트 쿼리를 날릴 필요가 없으면 카운트 쿼리를 날리지 않게 최적화했으니 실제로 그런지 확인해보자! 전체 데이터는 100개뿐인데 한 페이지에 200개를 뽑아오게 하면 들어오는 데이터는 100개라 전체 카운트 쿼리를 날리지 않을 것이다.

  • 카운트 쿼리는 예상대로 날라가지 않았다. 그럼 카운트 쿼리가 날라가도록 바꿔서 테스트도 해보자.
### GET Members
GET http://localhost:8080/v2/members?page=0&size=50

  • 카운트 쿼리가 날라가야 하는 경우 제대로 날리는 모습을 확인할 수 있다.

 

 

728x90
반응형
LIST

'Querydsl' 카테고리의 다른 글

참고: 리포지토리 지원 - QuerydslRepositorySupport  (0) 2024.12.30
Querydsl 중급 문법  (0) 2024.12.22
Querydsl 기본 문법  (0) 2024.12.21
[Renewal] QueryDsl  (0) 2024.12.07
Spring Boot 3.1.5에서 QueryDSL 설치하기  (0) 2023.11.26
728x90
반응형
SMALL

프로젝션과 결과 반환 - 기본

SELECT절에 어떤걸 가져올지를 정하는 것을 프로젝션이라고 한다. 프로젝션 대상이 하나라면 타입을 명확하게 지정할 수 있고 프로젝션 대상이 둘 이상이면 튜플이나 DTO로 조회할 수 있다.

 

프로젝션 대상이 하나인 경우

@Test
void simpleProjection() {
    List<String> results = queryFactory
            .select(member.username)
            .from(member)
            .fetch();

    for (String result : results) {
        System.out.println("result = " + result);
    }

    List<Member> members = queryFactory
            .select(member)
            .from(member)
            .fetch();

    for (Member member1 : members) {
        System.out.println("member1 = " + member1);
    }
}
  • SELECT절에 퍼올리는 데이터가 딱 하나인 경우를 프로젝션 대상이 하나인 경우라고 말하고, 위의 경우들이 그 예시이다.
  • 회원의 유저명만 딱 가져오는 경우 또는 회원 엔티티 자체를 딱 가져오는 경우를 프로젝션 대상이 하나인 경우라고 표현한다.

실행 결과

result = member1
result = member2
result = member3
result = member4

member1 = Member(id=1, username=member1, age=10)
member1 = Member(id=2, username=member2, age=20)
member1 = Member(id=3, username=member3, age=30)
member1 = Member(id=4, username=member4, age=40)

 

프로젝션 대상이 둘 이상인 경우 - 튜플 조회

@Test
void tupleProjection() {
    List<Tuple> results = queryFactory
            .select(member.username, member.age)
            .from(member)
            .fetch();

    for (Tuple tuple : results) {
        System.out.println(tuple.get(member.username));
        System.out.println(tuple.get(member.age));
    }
}
  • 위 코드와 같이 회원의 유저명과 나이 두 개를 가져오는 경우 동일한 타입이 아닌것부터 해서 하나의 타입으로 반환할 수가 없다. 이럴때 QuerydslTuple 타입으로 반환하게 된다.
  • 튜플 타입을 반환하고 데이터를 꺼낼때는 tuple.get(...)을 사용하면 된다.
  • 참고로, 그냥 이런게 있구나? 정도로 넘어가자. 왜냐하면 DTO로 반환하는 것을 잘 아는게 더 중요하고 잘 사용되기 때문이다.

실행 결과

member1
10
member2
20
member3
30
member4
40

 

프로젝션과 결과 반환 - DTO 조회

거의 대부분의 경우, DTO로 반환하는 경우를 많이 사용한다. 그리고 이 DTO로 조회하는 것도 여러 방법이 있는데 하나씩 소개하고 어떤게 더 좋은지도 알아보자! 우선 DTO가 필요하다.

package cwchoiit.querydsl.dto;

import lombok.Data;
import lombok.NoArgsConstructor;

@Data
@NoArgsConstructor
public class MemberDto {

    private String username;
    private int age;

    public MemberDto(String username, int age) {
        this.username = username;
        this.age = age;
    }
}
  • 위와 같이 DTO를 만들었다. 이후에 Querydsl에서 DTO 조회를 할때 기본 생성자가 반드시 필요하기 때문에 기본 생성자를 대신 만들어주는 롬복의 @NoArgsConstructor도 사용했다.

 

순수 JPA에서 DTO 조회

먼저, 순수한 JPA를 사용한 DTO 조회 방법을 알아보자.

@Test
void findDtoByJPQL() {
    List<MemberDto> memberDtos = em.createQuery("SELECT new cwchoiit.querydsl.dto.MemberDto(m.username, m.age) FROM Member m", MemberDto.class)
            .getResultList();

    for (MemberDto memberDto : memberDtos) {
        System.out.println("memberDto = " + memberDto);
    }
}
  • 우선, 순수 JPA로 하려면, 위 코드처럼 new 키워드를 사용해서 패키지명부터 다 적어줘야 한다.
  • 조금 불편하고 지저분한 감은 지울수가 없다.

실행 결과

memberDto = MemberDto(username=member1, age=10)
memberDto = MemberDto(username=member2, age=20)
memberDto = MemberDto(username=member3, age=30)
memberDto = MemberDto(username=member4, age=40)

 

Querydsl에서 DTO 조회 - Bean 생성

여기가 중요하니까 글자도 큼지막하게 하고 볼드체도 빵빵하게 넣었다. 크게 3가지 방법이 있다.

  • 프로퍼티 접근 (Setter)
  • 필드 직접 접근
  • 생성자 사용

1. 프로퍼티 접근 - Setter

@Test
void findDtoBySetter() {
    List<MemberDto> results = queryFactory
            .select(Projections.bean(MemberDto.class, member.username, member.age))
            .from(member)
            .fetch();

    for (MemberDto result : results) {
        System.out.println("result = " + result);
    }
  • DTO로 조회하는 방법 중 Setter를 사용하려면, 위와 같이 Projections.bean(...)을 사용하면 된다. 처음 파라미터는 어떤 클래스인지를, 그 다음부터는 원하는 각 필드를 채우면 된다.

실행 결과

result = MemberDto(username=member1, age=10)
result = MemberDto(username=member2, age=20)
result = MemberDto(username=member3, age=30)
result = MemberDto(username=member4, age=40)

 

 

2. 필드 직접 접근

@Test
void findDtoByFields() {
    List<MemberDto> results = queryFactory
            .select(Projections.fields(MemberDto.class, member.username, member.age))
            .from(member)
            .fetch();

    for (MemberDto result : results) {
        System.out.println("result = " + result);
    }
}
  • 위와 다른 것은 Projections.fields(...)를 사용했다는 점이다. 이 방법은 필드에 직접적으로 값을 넣어준다. DTO 클래스에 필드들은 다 private으로 선언했지만? 알다시피 리플렉션은 private도 접근 가능하게 해버릴 수 있기 때문에 상관없다.

실행 결과

result = MemberDto(username=member1, age=10)
result = MemberDto(username=member2, age=20)
result = MemberDto(username=member3, age=30)
result = MemberDto(username=member4, age=40)

 

별칭이 다른 경우

그런데, 가끔 별칭이 다른 DTO가 있을 수 있다. 무슨 말이냐면, 다음과 같은 DTO가 있다고 해보자.

package cwchoiit.querydsl.dto;

import lombok.Data;
import lombok.NoArgsConstructor;

@Data
@NoArgsConstructor
public class UserDto {
    private String name;
    private int age;

    public UserDto(String name, int age) {
        this.name = name;
        this.age = age;
    }
}
  • 이 경우엔 유저명이 `username`이 아니라 `name`이다. 
  • 이런식으로 컬럼명과 필드명이 다른 경우엔 값을 제대로 인식을 못한다. 그래서 이렇게 별칭이 다른 DTO를 사용하려면 다음과 같이 사용해야 한다.
@Test
void findDtoByFieldsAlias() {
    List<UserDto> results = queryFactory
            .select(Projections.fields(UserDto.class, member.username.as("name"), member.age))
            .from(member)
            .fetch();

    for (UserDto result : results) {
        System.out.println("result = " + result);
    }
}
  • 별칭이 다른 필드에 .as(...)를 사용해서 해당 별칭에 맞게 변경해줘야 한다.
  • 또 다른 예시는 서브 쿼리를 사용할때도 있다. 아래 코드를 보자.
@Test
void findDtoByFieldsAlias() {
    QMember memberSub = new QMember("memberSub");

    List<UserDto> results = queryFactory
            .select(Projections.fields(UserDto.class, 
                    member.username.as("name"),
                    ExpressionUtils.as(JPAExpressions.select(memberSub.age.max()).from(memberSub), "age"))
            )
            .from(member)
            .fetch();

    for (UserDto result : results) {
        System.out.println("result = " + result);
    }
}
  • 그러니까, DTO로 조회를 하긴 하는데, 나이에 해당하는 값은 서브쿼리를 통해 어떤 고정값을 넣고 싶은 경우다. 여기서 서브쿼리는 회원의 가장 높은 나이를 넣는 것이다. 
  • 이런 경우에는, ExpressionUtils.as(서브쿼리, "별칭") 이렇게 사용할 수 있다.
  • 여기서 ExpressionUtilscom.querydsl.core.types.ExpressionUtils이다.

 

 

3. 생성자 사용

@Test
void findDtoByConstructor() {
    List<MemberDto> results = queryFactory
            .select(Projections.constructor(MemberDto.class, member.username, member.age))
            .from(member)
            .fetch();

    for (MemberDto result : results) {
        System.out.println("result = " + result);
    }
}
  • 이것도 다른 점은 Projections.constructor(...) 를 사용했다는 점이다. 내가 만들어둔 username, age를 받는 생성자를 그대로 사용한다고 보면 된다. 
  • 생성자의 파라미터 순서대로 필드들을 넣어야 한다. 
  • 생성자를 사용하는 경우에는 별칭이 달라도 상관없다. 어차피 생성자가 있냐 없냐가 중요하기 때문이다. 

실행 결과

result = MemberDto(username=member1, age=10)
result = MemberDto(username=member2, age=20)
result = MemberDto(username=member3, age=30)
result = MemberDto(username=member4, age=40)

 

 

프로젝션과 결과 반환 - @QueryProjection

이 방법은 이제 궁극의 방법인데, 장점이 매우 많지만 단점도 없지는 않다. 일단 한번 보자.

 

조회하려는 DTO의 생성자에 아래와 같이 해보자.

package cwchoiit.querydsl.dto;

import com.querydsl.core.annotations.QueryProjection;
import lombok.Data;
import lombok.NoArgsConstructor;

@Data
@NoArgsConstructor
public class MemberDto {

    private String username;
    private int age;

    @QueryProjection
    public MemberDto(String username, int age) {
        this.username = username;
        this.age = age;
    }
}
  • @QueryProjection 애노테이션을 사용해서, 원하는 생성자에 저 애노테이션을 붙여주면 Querydsl이 Q클래스를 만들때 이 DTO도 Q클래스를 만들어준다.

 

이러면 어떻게 사용할 수가 있냐? 다음 코드를 보자.

@Test
void findDtoByQueryProjection() {
    List<MemberDto> results = queryFactory
            .select(new QMemberDto(member.username, member.age))
            .from(member)
            .fetch();

    for (MemberDto result : results) {
        System.out.println("result = " + result);
    }
}
  • 위 코드처럼 SELECT절에 QMemberDto를 그대로 넣어버릴 수 있다. 저 위에 있는 순수 JPA를 사용해야 할 땐 패키지명까지 다 작성해야 했는데 이건 그럴 필요가 없다. 
  • 또 다른 장점으로는 컴파일 단계에서 오류를 알려준다. 즉, 저 생성자에 들어갈 필드를 이미 컴파일러가 알고 있다는 말이다. 아래 스크린샷을 보자.

  • 이미 지금 저 QMemberDto는 인자는 2개가 필요하고 어떤 타입이 와야 하는지까지 다 알고 있다. 이게 정말 궁극의 장점이라고 볼 수 있다. 이전까지 알아봤던 DTO로 조회는 그렇지가 않다. 순수 JPA를 사용해서 DTO로 조회하는 것을 제외하고는 위에서 봤던 세터를 사용한 방법, 필드에 직접 접근, 생성자를 사용하는 방법 모두 컴파일러는 뭐가 들어올지 모른다. 그래서 이것이 정말 큰 장점이라고 할 수 있다.

 

그러나, 단점도 없지는 않다. 어떤 단점이 있냐? 

  • DTO까지 Q클래스를 만들어야 한다는 것 자체가 단점이다.
  • DTO는 순수한 자바 코드가 아니라 Querydsl을 의존한다.

두번째 말은 이런 것이다. 

package cwchoiit.querydsl.dto;

import com.querydsl.core.annotations.QueryProjection;
import lombok.Data;
import lombok.NoArgsConstructor;

@Data
@NoArgsConstructor
public class MemberDto {

    private String username;
    private int age;

    @QueryProjection
    public MemberDto(String username, int age) {
        this.username = username;
        this.age = age;
    }
}
  • 지금 이 MemberDto는 이제 Querydsl을 의존하고 있다. import 부분을 잘 보면 무슨 말인지 알 수 있다.
  • 이것 자체가 큰 단점이다. 구조적인 부분에서 말이다.
  • 만약, Querydsl을 사용하지 않게 기술을 바꾼다면, 이 부분이 영향을 받게 될 것이다.

 

선택하자

그래서 여기서부터는 선택이다. 실용적 관점에서 그냥 @QueryProjection을 사용하던가, 순수한 자바 코드를 최대한 유지하고 싶으면 @QueryProjection을 사용하지 않고, 위에서 봤던 Projections.bean(...) 이나 Projections.fields(...), Projections.constructor(...)를 사용하면 된다. 정답은 없다. 프로젝트마다, 구성원마다 차이가 있을 것이고 그에 맞게 유동적으로 맞춰가면 된다.

 

 

동적 쿼리 - BooleanBuilder 사용

동적 쿼리를 해결하는 두가지 방식이 있는데 그 중 하나인 BooleanBuilder를 사용해보자.

@Test
void dynamicQuery_booleanBuilder() {
    String usernameParam = "member1";
    Integer ageParam = 10;

    List<Member> results = searchMember1(usernameParam, ageParam);
    assertThat(results).hasSize(1);
}

private List<Member> searchMember1(String usernameParam, Integer ageParam) {

    BooleanBuilder builder = new BooleanBuilder();

    if (usernameParam != null) {
        builder.and(member.username.eq(usernameParam));
    }

    if (ageParam != null) {
        builder.and(member.age.eq(ageParam));
    }

    return queryFactory
            .selectFrom(member)
            .where(builder)
            .fetch();
}
  • 위 코드가 BooleanBuilder를 사용하는 방법이다. 딱히 별 게 없다. 약간 JDBC 기술을 사용해서 동적 쿼리를 작성하는 것과 느낌이 비슷하긴 한데 훨씬 깔끔하다. 문자열이 없기 때문에.

 

동적 쿼리 - WHERE 다중 파라미터 사용

@Test
void dynamicQuery_whereParam() {
    String usernameParam = "member1";
    Integer ageParam = 10;

    List<Member> results = searchMember2(usernameParam, ageParam);
    assertThat(results).hasSize(1);
}

private List<Member> searchMember2(String usernameParam, Integer ageParam) {
    return queryFactory
            .selectFrom(member)
            .where(usernameEq(usernameParam), ageEq(ageParam))
            .fetch();
}

private BooleanExpression ageEq(Integer ageParam) {
    return ageParam == null ? null : member.age.eq(ageParam);
}

private BooleanExpression usernameEq(String usernameParam) {
    return usernameParam == null ? null : member.username.eq(usernameParam);
}
  • 이게 이제 WHERE 다중 파라미터 사용 방법이다. 훨씬 더 깔끔하다.
  • 왜냐하면, 쿼리 자체의 가독성이 높아지기 때문이다. ageEq, usernameEq를 보지말고, 딱 쿼리자체만 보면 굳이 저 메서드를 추적하지 않아도 WHERE절에 usernameEq(...), ageEq(...)만 보더라도 어떤 조건인지 예측이 가능해진다.
  • 저렇게 WHERE절에 다중 파라미터로 만들면 파라미터에 null이 들어오는 경우 그냥 무시를 해버리기 때문에 동적 쿼리를 매우 깔끔하고 간단하게 만들 수 있다. 예를 들어, ageEq(...)null을 반환하면 WHERE절안에 null은 무시가 된다.
  • 그리고 또 장점은 재사용이 가능하다는 점이다. 분명히 회원의 유저명이 같은 조건같은 건 여기저기 사용될 가능성이 높다. 이게 메서드로 만든 이상 여기저기 가져다가 사용이 가능해진다.
  • 또 한가지 장점은  조합이 가능하다는 점이다. 이것도 엄청 강력한 장점인데 아래 코드를 보자.
private BooleanExpression ageAndUsernameEq(Integer ageParam, String usernameParam) {
    return ageEq(ageParam).and(usernameEq(usernameParam));
}
  • 저 두 메서드(조건) ageEq(...), usernameEq(...)는 메서드이고 타입이 BooleanExpression이기 때문에 두 개를 AND 또는 OR로 조합해서도 사용이 가능하다. 기가맥히다.
  • 물론, 이렇게 조합하는 경우, 앞 부분의 null 체크는 조심해야 한다. 왜냐하면 ageEq(...)null인 경우엔 이렇게 될 것 아닌가?null.and(...) 이러면 NullPointerException이기 때문에 이 부분만 조심하면 된다. 뭐 아래와 같이 작성하면 되겠지.
private BooleanExpression ageAndUsernameEq(Integer ageParam, String usernameParam) {
    if (ageParam == null) {
        return usernameEq(usernameParam);
    }
    return ageEq(ageParam).and(usernameEq(usernameParam));
}

 

나는 이 WHERE절에 다중 파라미터 방식을 너무나 선호한다.

 

수정, 삭제 벌크 연산

쿼리 한번으로 대량 데이터에 쓰기 작업을 하는 것을 말한다.

@Test
void bulkUpdate() {
    long count = queryFactory
            .update(member)
            .set(member.username, "비회원")
            .where(member.age.lt(28))
            .execute();

    assertThat(count).isEqualTo(2);
}
  • 쿼리 자체는 새로운 게 전혀 없다.
  • 그렇지만, 벌크 연산은 가장 중요한 부분이 벌크 연산을 하고 나면 반드시 영속성 컨텍스트를 flush(), clear() 해주는 게 그냥 무조건 좋다. 왜 그러냐면, 벌크 연산은 영속성 컨텍스트를 무시하고 바로 데이터베이스에 쿼리를 날리기 때문에 영향받는 레코드가 이미 영속성 컨텍스트에서 관리되고 있다면 이 관리되는 데이터는 벌크 연산을 날린 데이터랑 불일치가 일어난다. 그래서 원치 않는 결과를 마주할 수도 있으니 항상 벌크 연산은 flush(), clear()를 해준다고 그냥 머리에 박아두자.
@Test
void bulkUpdate() {
    long count = queryFactory
            .update(member)
            .set(member.username, "비회원")
            .where(member.age.lt(28))
            .execute();

    assertThat(count).isEqualTo(2);

    em.flush();
    em.clear();
}
  • 이런식으로 말이다.

 

그리고, 벌크 연산으로 자주 사용되는 특정 컬럼에 모두 같은 값을 더하거나 곱하는 경우도 보자.

@Test
void bulkAdd() {
    long count = queryFactory
            .update(member)
            .set(member.age, member.age.add(1))
            .execute();

    assertThat(count).isEqualTo(4);

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

    List<Member> members = queryFactory
            .selectFrom(member)
            .fetch();

    for (Member findMember : members) {
        System.out.println("findMember = " + findMember);
    }
}

@Test
void bulkMultiply() {
    long count = queryFactory
            .update(member)
            .set(member.age, member.age.multiply(2))
            .execute();

    assertThat(count).isEqualTo(4);

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

    List<Member> members = queryFactory
            .selectFrom(member)
            .fetch();

    for (Member findMember : members) {
        System.out.println("findMember = " + findMember);
    }
}
  • 간단하게 나이에 1을 모두 더하거나, 나이에 2를 모두 곱하거나에 대한 쿼리이다.

 

쿼리 한번으로 대량 데이터 삭제

@Test
void bulkDelete() {
    long count = queryFactory
            .delete(member)
            .where(member.age.lt(28))
            .execute();

    assertThat(count).isEqualTo(2);

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

    List<Member> members = queryFactory.selectFrom(member).fetch();

    for (Member findMember : members) {
        System.out.println("findMember = " + findMember);
    }
}
  • 이번엔 삭제를 벌크로 하는 방법에 대한 쿼리이다.

 

SQL Function 호출

@Test
void sqlFunction() {
    // member.username 에서 'member' 라는 단어를 'M' 으로 변경
    List<String> results = queryFactory
            .select(Expressions.stringTemplate(
                    "function('replace', {0}, {1}, {2})", member.username, "member", "M"))
            .from(member)
            .fetch();

    for (String result : results) {
        System.out.println("result = " + result);
    }
}

실행 결과

2024-12-24T22:29:10.394+09:00 DEBUG 39987 --- [    Test worker] org.hibernate.SQL                        : 
select
    replace(m1_0.username, ?, ?) 
from
    member m1_0
    
result = M1
result = M2
result = M3
result = M4

 

 

이번에는 소문자로 변경하는 함수를 사용하는 쿼리를 보자.

@Test
void sqlFunction2() {
    /*List<String> results = queryFactory
            .select(member.username)
            .from(member)
            .where(member.username.eq(Expressions.stringTemplate("function('lower', {0})", member.username)))
            .fetch();*/

    List<String> results = queryFactory
            .select(member.username)
            .from(member)
            .where(member.username.eq(member.username.lower()))
            .fetch();

    for (String result : results) {
        System.out.println("result = " + result);
    }
}
  • 주석 처리한 부분을 먼저보자. 이번에는 WHERE절에 함수를 사용했다. 간단하게 소문자로 변경하는 함수인데, 왜 주석처리했냐? 저런 ANSI 표준 함수들은 Querydsl이 상당 부분 다 내장하고 있어서 저렇게 어렵게 작성할 필요없이 그 바로 아래에 주석 처리하지 않은 부분처럼 할 수 있다.

 

728x90
반응형
LIST

'Querydsl' 카테고리의 다른 글

참고: 리포지토리 지원 - QuerydslRepositorySupport  (0) 2024.12.30
JPA 레포지토리와 Querydsl  (2) 2024.12.26
Querydsl 기본 문법  (0) 2024.12.21
[Renewal] QueryDsl  (0) 2024.12.07
Spring Boot 3.1.5에서 QueryDSL 설치하기  (0) 2023.11.26
728x90
반응형
SMALL

이전 포스팅에서 Querydsl 세팅하는 방법과 왜 Querydsl을 사용해야 하는지를 이야기했다. 이제 천천히 하나씩 Querydsl을 사용해보면서 이게 얼마나 막강한 녀석인지 직접 체감해보자.

 

우선, 엔티티를 정의해야 한다. 참고로, 나는 JPAQuerydsl을 같이 사용한다. 그래서 JPA로 엔티티를 만들어내고 Querydsl을 곁들인다.

 

엔티티 정의

Member

package cwchoiit.querydsl.entity;

import jakarta.persistence.*;
import lombok.AccessLevel;
import lombok.Getter;
import lombok.NoArgsConstructor;
import lombok.ToString;

@Entity
@Getter
@NoArgsConstructor(access = AccessLevel.PROTECTED)
@ToString(of = {"id", "username", "age"})
public class Member {

    @Id
    @GeneratedValue
    @Column(name = "member_id")
    private Long id;

    private String username;
    private int age;

    @ManyToOne(fetch = FetchType.LAZY)
    @JoinColumn(name = "team_id")
    private Team team;

    public Member(String username) {
        this(username, 0, null);
    }

    public Member(String username, int age) {
        this(username, age, null);
    }

    public Member(String username, int age, Team team) {
        this.username = username;
        this.age = age;
        if (team != null) {
            changeTeam(team);
        }
    }

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

 

Team

package cwchoiit.querydsl.entity;

import jakarta.persistence.*;
import lombok.AccessLevel;
import lombok.Getter;
import lombok.NoArgsConstructor;
import lombok.ToString;

import java.util.ArrayList;
import java.util.List;

@Entity
@Getter
@NoArgsConstructor(access = AccessLevel.PROTECTED)
@ToString
public class Team {

    @Id
    @GeneratedValue
    @Column(name = "team_id")
    private Long id;

    private String name;

    @OneToMany(fetch = FetchType.LAZY, mappedBy = "team")
    private final List<Member> members = new ArrayList<>();

    public Team(String name) {
        this.name = name;
    }
}
  • 간단하게 Team - Member 엔티티를 만들었다.
  • 당연히, 팀과 멤버는 1:N 관계이고 여기서는 다대일 양방향 연관관계로 만들었다.

 

Querydsl 맛보기

이제 테스트 코드로 간단한 Querydsl 코드를 작성하자.

QuerydslBasicTest

package cwchoiit.querydsl;

import com.querydsl.jpa.impl.JPAQueryFactory;
import cwchoiit.querydsl.entity.Member;
import cwchoiit.querydsl.entity.Team;
import jakarta.persistence.EntityManager;
import org.junit.jupiter.api.BeforeEach;
import org.junit.jupiter.api.Test;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.test.context.SpringBootTest;
import org.springframework.transaction.annotation.Transactional;

import static cwchoiit.querydsl.entity.QMember.member;
import static org.assertj.core.api.Assertions.assertThat;

@SpringBootTest
@Transactional
public class QuerydslBasicTest {

    @Autowired
    EntityManager em;

    JPAQueryFactory queryFactory;

    @BeforeEach
    public void setUp() {
        queryFactory = new JPAQueryFactory(em);
        Team teamA = new Team("teamA");
        Team teamB = new Team("teamB");
        em.persist(teamA);
        em.persist(teamB);

        Member member1 = new Member("member1", 10, teamA);
        Member member2 = new Member("member2", 20, teamA);
        Member member3 = new Member("member3", 30, teamB);
        Member member4 = new Member("member4", 40, teamB);
        em.persist(member1);
        em.persist(member2);
        em.persist(member3);
        em.persist(member4);
    }

    @Test
    void querydsl() {
        Member findMember = queryFactory
                .select(member)
                .from(member)
                .where(member.username.eq("member1"))
                .fetchOne();

        assertThat(findMember).isNotNull();
        assertThat(findMember.getUsername()).isEqualTo("member1");
        assertThat(findMember.getAge()).isEqualTo(10);
    }
}
  • 우선, Querydsl을 사용하려면 JPAQueryFactory가 필요하다. 이 친구는 필드 레벨에 선언하는 게 가장 좋다. 어차피 멀티스레드 환경에서도 안전하게 동작하게 설계됐기 때문에 필드 레벨에 선언해도 아무런 문제도 없다.
  • 그리고 여기서는 각 테스트 별로 데이터가 준비될 수 있게 @BeforeEach 애노테이션으로 테스트 데이터를 만들어 낸다.
  • JPAQueryFactoryEntityManager가 필요하다. 그래서, 생성자로 전달하는 모습을 확인할 수 있다.
  • 실제로 Querydsl을 사용하는 코드를 중점적으로 봐보자.
@Test
void querydsl() {
    Member findMember = queryFactory
            .select(member)
            .from(member)
            .where(member.username.eq("member1"))
            .fetchOne();

    assertThat(findMember).isNotNull();
    assertThat(findMember.getUsername()).isEqualTo("member1");
    assertThat(findMember.getAge()).isEqualTo(10);
}
  • QMemberstatic-import를 하면 그 클래스 안에 필드로 선언된 `member`를 위 코드처럼 간단하고 명료하게 사용할 수 있다.
  • 그리고 코드를 보면, 자바 코드인데도 불구하고 SQL처럼 보여지는 이 가시성이 정말 막강한 장점이다. 동적 쿼리를 작성할때도 정말 강력한 것이 where(...)안에 필요한 조건문을 아주 간결하게 작성할 수 있다. 이후에 저 부분은 더 멋지게 변경될 것이다.

 

검색 조건 쿼리

아래 코드를 보자.

@Test
void search() {
    /*Member findMember = queryFactory
            .selectFrom(member)
            .where(member.username.eq("member1").and(member.age.eq(10)))
            .fetchOne();*/

    Member findMember = queryFactory
            .selectFrom(member)
            .where(member.username.eq("member1"), member.age.eq(10))
            .fetchOne();

    assertThat(findMember).isNotNull();
    assertThat(findMember.getUsername()).isEqualTo("member1");
}
  • 주석 처리한 것과 주석 처리하지 않은 두 쿼리가 완전히 동일한 쿼리이다. and(...) 으로 메서드 체인형식으로 사용할 수도 있고, and의 경우에는 저렇게 (,)로 연결해도 동일한 결과이다.
  • 참고로, and가 있으면 당연히 or도 있다.
  • 그러 뭐가 더 좋냐? 뭐 사람마다 다르겠지만, 개인적으로는 (,) 방식을 더 선호한다. 근데 이건 뭐가 됐든 상관없다.

 

결과 조회

@Test
void resultFetch() {
    List<Member> members = queryFactory.selectFrom(member).fetch();

    Member findMember = queryFactory.selectFrom(member).fetchOne();

    // 아래와 동일한 코드 queryFactory.selectFrom(member).limit(1).fetchOne();
    Member findMemberFirst = queryFactory.selectFrom(member).fetchFirst();
}
  • fetch() → 리스트 조회, 데이터 없으면 빈 리스트 반환
  • fetchOne() → 단건 조회, 결과가 없으면 null, 결과가 둘 이상이면 NonUniqueResultException 발생
  • fetchFirst()limit(1).fetchOne()과 동일한 편의 메서드

 

정렬

/**
 * 회원 정렬
 * 회원 나이 내림차순
 * 회원 이름 올림차순
 * 단 2에서 회원 이름이 null 이면 마지막에 출력
 */
@Test
void sort() {
    Member memberNull = new Member(null, 100);
    Member member5 = new Member("member5", 100);
    Member member6 = new Member("member6", 100);
    em.persist(memberNull);
    em.persist(member5);
    em.persist(member6);

    List<Member> members = queryFactory
            .selectFrom(member)
            .where(member.age.eq(100))
            .orderBy(member.age.desc(), member.username.asc().nullsLast())
            .fetch();

    assertThat(members).isNotNull();
    assertThat(members.getFirst().getUsername()).isEqualTo("member5");
    assertThat(members.get(1).getUsername()).isEqualTo("member6");
    assertThat(members.get(2).getUsername()).isNull();
}
  • 정렬도 Querydsl을 사용하면 여려 정렬을 한번에 할 수 있으며, 해당값이 null인 경우, 마지막에 위치시킬지 맨 처음에 위치시킬지를 정할 수 있다.
  • 마지막에 위치시키는 건 nullsLast(), 맨 처음에 위치시키는 건 nullsFirst()를 사용하면 된다.
  • 여기서는 nullsLast()를 사용했다.

 

페이징

@Test
void paging1() {
    List<Member> members = queryFactory
            .selectFrom(member)
            .orderBy(member.username.desc())
            .offset(1)
            .limit(2)
            .fetch();

    assertThat(members).isNotNull();
    assertThat(members.size()).isEqualTo(2);
    assertThat(members.getFirst().getUsername()).isEqualTo("member3");
    assertThat(members.get(1).getUsername()).isEqualTo("member2");
}

@Test
void paging2() {
    List<Member> members = queryFactory
            .selectFrom(member)
            .orderBy(member.username.desc())
            .offset(1)
            .limit(2)
            .fetch();

    int totalCount = queryFactory
            .selectFrom(member)
            .fetch()
            .size();

    assertThat(members).isNotNull();
    assertThat(totalCount).isEqualTo(4);
    assertThat(members.size()).isEqualTo(2);
    assertThat(members.getFirst().getUsername()).isEqualTo("member3");
    assertThat(members.get(1).getUsername()).isEqualTo("member2");
}
  • 페이징은 간단하게, offset(), limit()을 사용하면 된다. 
  • 그리고 전체 수를 가져오는 건 별도의 쿼리로 작성해줘야 한다. 예전에는 fetchResults()라는 것을 사용해서 전체 개수를 가져올 수 있었는데 그 메서드는 Deprecated 됐고, 애시당초에 그 메서드도 내부에서 전체 카운트를 가져오는 쿼리를 또 날리는 것 밖에 안된다.
  • 그래서 전체 개수를 가져오는 쿼리는 별도로 작성해서 위 paging2()처럼 가져온다. 보면 알겠지만, 전체 개수를 가져오는 쿼리는 굉장히 간단하고 실제 쿼리랑은 다르다. 지금이야 orderBy() 정도만 있고 없고의 차이지만 어떤것은 그 이상으로 전체 개수를 가져오는 쿼리가 최적화되기 때문에 이 부분은 직접 구현하도록 바뀌었다.

 

집합

집합 함수를 의미하고, SUM, COUNT, AVG, MAX, MIN, GROUP BY를 사용한다.

@Test
void aggregation() {
    List<Tuple> results = queryFactory
            .select(
                    member.count(),
                    member.age.sum(),
                    member.age.avg(),
                    member.age.min(),
                    member.age.max()
            )
            .from(member)
            .fetch();

    Tuple tuple = results.getFirst();

    assertThat(tuple.get(member.count())).isEqualTo(4);
    assertThat(tuple.get(member.age.sum())).isEqualTo(100);
    assertThat(tuple.get(member.age.avg())).isEqualTo(25);
    assertThat(tuple.get(member.age.min())).isEqualTo(10);
    assertThat(tuple.get(member.age.max())).isEqualTo(40);
}
  • COUNT, SUM, AVG, MIN, MAX도 굉장히 간단하게 그저 메서드를 호출하는 것으로 구현해낼 수 있다.
  • 그리고 타입이 가지각색이거나, 어떤 값으로 딱 추출을 해내는 경우엔 객체 타입이 아니라 Tuple 이라는 타입으로 반환받게 되는데 이 Tuple을 통해 값을 가져오는 건 그냥 get(...)으로 내가 원하는 값을 뽑아오면 된다. 
  • 참고로, 실무에서는 Tuple 타입으로 받아오는 것보다 DTO로 변환해서 가져오는 방법이 훨씬 더 많이 사용된다. 이후에 같이 알아보자.

GROUP BY도 간단하게 사용할 수 있다. 아래 코드를 보자.

/**
 * 팀의 이름과 각 팀의 평균 연령을 구해라.
 */
@Test
void group() {
    List<Tuple> results = queryFactory
            .select(team.name, member.age.avg())
            .from(member)
            .join(member.team, team)
            .groupBy(team.name)
            .fetch();

    Tuple teamA = results.getFirst();
    Tuple teamB = results.get(1);

    assertThat(teamA.get(team.name)).isEqualTo("teamA");
    assertThat(teamA.get(member.age.avg())).isEqualTo(15);

    assertThat(teamB.get(team.name)).isEqualTo("teamB");
    assertThat(teamB.get(member.age.avg())).isEqualTo(35);
}

/**
 * 팀의 이름과 각 팀의 평균 연령을 구하고 팀의 이름이 teamA 인것만 가져와라.
 */
@Test
void groupByHaving() {
    List<Tuple> results = queryFactory
            .select(team.name, member.age.avg())
            .from(member)
            .join(member.team, team)
            .groupBy(team.name)
            .having(team.name.eq("teamA"))
            .fetch();

    Tuple teamA = results.getFirst();

    assertThat(results.size()).isEqualTo(1);
    assertThat(teamA.get(team.name)).isEqualTo("teamA");
    assertThat(teamA.get(member.age.avg())).isEqualTo(15);
}
  • GROUP BY, HAVING을 사용한 코드이다. 참고로 HAVINGGROUP BY로 그룹화 된 결과를 제한하는 것이다.

 

조인

INNER

@Test
void join() {
    List<Member> members = queryFactory
            .selectFrom(member)
            .join(member.team, team)
            .where(team.name.eq("teamA"))
            .fetch();

    assertThat(members).isNotNull();
    assertThat(members.size()).isEqualTo(2);

    assertThat(members)
            .extracting(Member::getUsername)
            .containsExactly("member1", "member2");
}
  • 가장 기본이 되는 조인인 INNER 조인하는 방법이다. ON절은 어디있나요?에 대한 대답은 기본으로 ON절을 넣어준다. 이 테스트 코드를 실행했을 때 나가는 쿼리를 보면 바로 이해가 될 것이다.
  • 아 그리고 innerJoin() 메서드도 있는데 이게 join()과 동일하다.
2024-12-22T13:19:06.677+09:00 DEBUG 58042 --- [    Test worker] org.hibernate.SQL                        : 
select
    m1_0.member_id,
    m1_0.age,
    m1_0.team_id,
    m1_0.username 
from
    member m1_0 
join
    team t1_0 
        on t1_0.team_id=m1_0.team_id 
where
    t1_0.name=?

 

[LEFT|RIGHT] OUTER

@Test
void join() {
    List<Member> members = queryFactory
            .selectFrom(member)
            .leftJoin(member.team, team)
            .where(team.name.eq("teamA"))
            .fetch();

    /*List<Member> members = queryFactory
            .selectFrom(member)
            .rightJoin(member.team, team)
            .where(team.name.eq("teamA"))
            .fetch();*/

    assertThat(members).isNotNull();
    assertThat(members.size()).isEqualTo(2);

    assertThat(members)
            .extracting(Member::getUsername)
            .containsExactly("member1", "member2");
}
  • 외부 조인 역시 가능하다. leftJoin(), rightJoin()이 있다.

 

THETA

"막 조인"이라고 하는 세타 조인도 역시 가능하다. 

/**
 * 회원이 이름이 팀 이름과 같은 회원 조회
 */
@Test
void thetaJoin() {
    em.persist(new Member("teamA"));
    em.persist(new Member("teamB"));
    em.persist(new Member("teamC"));

    List<Member> members = queryFactory
            .select(member)
            .from(member, team)
            .where(member.username.eq(team.name))
            .fetch();

    assertThat(members).isNotNull();
    assertThat(members.size()).isEqualTo(2);
    assertThat(members).extracting(Member::getUsername).containsExactly("teamA", "teamB");
}
  • 억지스러운 예제이긴 하지만, 회원의 이름이 "teamA", "teamB", "teamC"라고 만들고 이 회원 이름과 팀 이름이 같은 회원들을 한번 조회해보고 싶은것이다. 원래 세타 조인이 이렇게 막 조인이다.
  • 세타 조인을 할땐 FROM절에 원하는 엔티티를 여러개 넣으면 된다.

 

ON

ON절을 활용한 조인은 다음 두가지 케이스에서 사용된다.

  • 조인 대상 필터링
  • 연관관계 없는 엔티티의 외부 조인

조인 대상 필터링
지금까지 join()을 사용하면서 on()을 사용하지 않으면 그냥 기본으로 조인 대상의 ID가 같은 것들을 넣어주곤 했다. 

이 경우에 더해서, 조인 대상을 필터링하고 싶을 때 추가적으로 ON절을 사용할 수가 있다.

/**
 * 회원과 팀을 조인하면서, 팀 이름이 teamA인 팀만 조인, 회원은 모두 조회
 */
@Test
void on_filtering() {
    List<Tuple> results = queryFactory
            .select(member, team)
            .from(member)
            .leftJoin(member.team, team)
            .on(team.name.eq("teamA"))
            .fetch();

    for (Tuple result : results) {
        System.out.println("result = " + result);
    }
}
  • 위 코드처럼 LEFT JOIN을 한다고 가정해보자. LEFT JOIN은 왼쪽 엔티티를 기준으로 오른쪽에 조인 대상이 없어도 결과로 출력이 된다. 그런데 그 조인 대상을 필터링을 하고 싶은 것이다. MEMBER.TEAM.ID = TEAM.ID 뿐 아니라, TEAM의 이름이 "teamA"인 애들만 조인하고 싶은 것이다.
  • 이렇게 되면 결과는 어떻게 될까? TEAM의 이름이 "teamA"인 녀석들은 조인 결과에서 팀까지 같이 출력이 되고, "teamA"가 아닌 녀석들은 조인 결과에서 팀은 빠지고 멤버만 남을 것이다. LEFT JOIN이니까.

실행 결과

result = [Member(id=1, username=member1, age=10), Team(id=1, name=teamA, members=[Member(id=1, username=member1, age=10), Member(id=2, username=member2, age=20)])]
result = [Member(id=2, username=member2, age=20), Team(id=1, name=teamA, members=[Member(id=1, username=member1, age=10), Member(id=2, username=member2, age=20)])]
result = [Member(id=3, username=member3, age=30), null]
result = [Member(id=4, username=member4, age=40), null]

 

나가는 쿼리

2024-12-22T13:36:36.154+09:00 DEBUG 58927 --- [    Test worker] org.hibernate.SQL                        : 
select
    m1_0.member_id,
    m1_0.age,
    m1_0.team_id,
    m1_0.username,
    t1_0.team_id,
    t1_0.name 
from
    member m1_0 
left join
    team t1_0 
        on t1_0.team_id=m1_0.team_id 
        and t1_0.name=?

 

그런데 만약, 외부 조인이 아니라 내부 조인을 사용하면 ON절을 사용하는 것 말고 WHERE를 사용해도 완전히 동일한 결과를 얻을 것이다. 왜냐하면, 내부 조인은 애시당초에 조인 결과에서 대상이 없는 녀석들은 제외시키기 때문에 조인 대상이 있는 녀석들만 결과로 출력될 것이고 거기서 팀 이름이 "teamA"인 녀석들만 간추리려면 그냥 WHERE절 사용하면 된다. 그러니까, 내부 조인인데 굳이 ON절로 안 익숙한 것을 사용하지 말고 내부조인인 경우에는 WHERE가 더 익숙하니 이걸 사용하면 좋다는 말이다.

 

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

/**
 * 연관 관계가 없는 엔티티 외부 조인
 * 회원의 이름이 팀 이름과 같은 대상 외부 조인
 */
@Test
void thetaJoin_on() {
    em.persist(new Member("teamA"));
    em.persist(new Member("teamB"));
    em.persist(new Member("teamC"));

    List<Tuple> results = queryFactory
            .select(member, team)
            .from(member)
            .leftJoin(team)
            .on(member.username.eq(team.name))
            .fetch();

    for (Tuple result : results) {
        System.out.println("result = " + result);
    }
}
  • 세타 조인은 아닌데, 외부 조인을 하고 싶은데 외부 조인을 할 때 연관관계가 없는 엔티티와 외부 조인을 하려고 할 때 이 ON을 사용할수가 있다. 
  • 위 코드를 보면, 지금 leftJoin()을 사용하는데 매우 주의 깊게 봐야한다! 원래는 leftJoin(member.team, team)이렇게 사용하곤 했는데 여기서는 leftJoin(team)을 사용한다. 즉, FROM절의 member와 아무런 연관이 없는 그냥 팀을 다 가져오는데 조인 조건으로 ON을 사용해서 회원이 이름이 팀의 이름과 동일한 조건을 부여했다.
  • 세타 조인을 할 땐 FROM절에 세타 조인하고 싶은 엔티티들을 여러개 넣었는데 이건 그게 아니다. 즉, 외부 조인인데 연관관계가 없는 녀석들과 외부 조인을 하려고 하는 것이다.

실행 결과

result = [Member(id=1, username=member1, age=10), null]
result = [Member(id=2, username=member2, age=20), null]
result = [Member(id=3, username=member3, age=30), null]
result = [Member(id=4, username=member4, age=40), null]
result = [Member(id=5, username=teamA, age=0), Team(id=1, name=teamA, members=[Member(id=1, username=member1, age=10), Member(id=2, username=member2, age=20)])]
result = [Member(id=6, username=teamB, age=0), Team(id=2, name=teamB, members=[Member(id=3, username=member3, age=30), Member(id=4, username=member4, age=40)])]
result = [Member(id=7, username=teamC, age=0), null]
  • 외부 조인이니까 조인 대상이 없어도 결과로 출력된다. 단지, 조인 대상이 없는 것들은 null로 표시될 뿐.

나가는 쿼리

2024-12-22T13:58:35.827+09:00 DEBUG 60017 --- [    Test worker] org.hibernate.SQL                        : 
select
    m1_0.member_id,
    m1_0.age,
    m1_0.team_id,
    m1_0.username,
    t1_0.team_id,
    t1_0.name 
from
    member m1_0 
left join
    team t1_0 
        on m1_0.username=t1_0.name
  • ON절에 외래키와 PK가 같은 것들을 고려하지 않고 있다. 외부 조인인데 연관관계가 없음을 의미한다.
  • 세타 조인은 FROM절에 여러개가 들어가는 것이다.
  • 물론 외부 조인 말고 내부 조인도 가능하다. 근데 내부조인은 조인 대상이 없으면 결과로 나오지 않기 때문에 그냥 세타 조인을 사용하고 WHERE로 필터링한 결과랑 동일하니까 그 방법을 사용하면 된다.

 

페치 조인

페치 조인은 SQL에서 제공하는 기능이 아니고, SQL 조인을 활용하고 연관된 엔티티를 SQL 한번에 조회하는 기능이다. JPA에서 제공하는 기능으로써 주로 성능 최적화에 사용하는 방법이다. 

@Test
void fetchJoin() {

    Member findMember = queryFactory
            .selectFrom(member)
            .join(member.team, team)
            .fetchJoin()
            .where(member.username.eq("member1"))
            .fetchOne();

    assertThat(findMember).isNotNull();
    assertThat(findMember.getUsername()).isEqualTo("member1");
    assertThat(findMember.getTeam().getName()).isEqualTo("teamA");
}
  • Querydsl을 사용해서 페치 조인을 하는 방법은 너무나 간단하다. join() 이후에 fetchJoin()만 붙여주면 끝난다.
  • leftJoin()이든 뭐든 상관없다.

 

서브 쿼리

당연하게도 서브 쿼리 역시 지원한다. 하나씩 천천히 보자. QueryDsl을 사용할때 서브 쿼리를 사용하려면 com.querydsl.jpa.JPAExpressions를 사용해야 한다. 

/**
 * SubQuery - 나이가 가장 많은 회원 조회 (EQ)
 */
@Test
void subQuery() {

    QMember memberSub = new QMember("memberSub");

    List<Member> members = queryFactory
            .selectFrom(member)
            .where(member.age.eq(
                    JPAExpressions
                            .select(memberSub.age.max())
                            .from(memberSub)
            ))
            .fetch();

    assertThat(members).extracting(Member::getAge).containsExactly(40);
}
  • WHERE절에 서브쿼리를 사용한 모습이다. 쿼리 자체는 뭐 별게 없는데 이렇게 사용하면 된다는 것을 보여주기 위해 작성했다.
  • 당연하지만, 서브 쿼리에서 엔티티에 대한 Alias는 다른 녀석을 사용해야 한다. SQL과 똑같이 생각하면 된다. 그래서 이 경우에는 Q타입 객체를 새로 생성해야만 한다.
  • 참고로, 저 JPAExpressionsstatic-import를 하면 좀 더 깔끔하다. 아래와 같이 말이다.
/**
 * SubQuery - 나이가 동일한 회원 (EQ)
 */
@Test
void subQuery() {

    QMember memberSub = new QMember("memberSub");

    List<Member> members = queryFactory
            .selectFrom(member)
            .where(member.age.eq(
                    select(memberSub.age.max())
                    .from(memberSub)
            ))
            .fetch();

    assertThat(members).extracting(Member::getAge).containsExactly(40);
}

 

EQ말고, GOE, INSELECT절에서도 사용하는 예제들도 있다.

/**
 * SubQuery - 나이가 평균 이상인 회원 (GOE)
 */
@Test
void suqQuery2() {
    QMember memberSub = new QMember("memberSub");

    List<Member> members = queryFactory
            .selectFrom(member)
            .where(member.age.goe(
                    select(memberSub.age.avg())
                            .from(memberSub)
            ))
            .fetch();

    assertThat(members).extracting(Member::getAge).containsExactly(30, 40);
}

/**
 * SubQuery - IN절 사용
 */
@Test
void subQuery3() {
    QMember memberSub = new QMember("memberSub");

    List<Member> members = queryFactory
            .selectFrom(member)
            .where(member.age.in(
                    select(memberSub.age)
                            .from(memberSub)
                            .where(memberSub.age.gt(10))
            ))
            .fetch();

    assertThat(members).extracting(Member::getAge).containsExactly(20, 30, 40);
}

/**
 * SubQuery - SELECT절
 */
@Test
void subQuery4() {
    QMember memberSub = new QMember("memberSub");

    List<Tuple> results = queryFactory
            .select(
                    member.username,
                    select(memberSub.age.avg())
                            .from(memberSub))
            .from(member)
            .fetch();

    for (Tuple result : results) {
        System.out.println("result = " + result);
    }
}

 

FROM절에서 서브쿼리는 불가능하다. 이유는 JPQLFROM절의 서브쿼리를 지원하지 않기 때문. 그리고 사실 FROM 절의 서브쿼리를 꼭 사용해야 할 필요가 없다. 거의 대부분은 JOIN으로 해결이 가능하다. 물론 모든게 다 가능하지는 않다. 그러나 간과하면 안될 것이 있다. 이게 데이터베이스에서 데이터를 가져오는 건 정말 데이터를 가져오는 것이지 데이터를 정제하고 분리하는 건 데이터베이스 레벨에서만 해야하는 게 아니다. 애플리케이션 레벨에서 충분히 가능하다. 만약 애플리케이션 레벨에서 죽어도 하기 싫다면 그냥 네이티브쿼리를 날리면 된다.

 

Case

@Test
void basicCase() {
    List<String> results = queryFactory
            .select(member.age
                    .when(10).then("열살")
                    .when(20).then("스무살")
                    .otherwise("기타")
            )
            .from(member)
            .fetch();

    for (String result : results) {
        System.out.println("result = " + result);
    }
}

@Test
void complexCase() {
    List<String> results = queryFactory
            .select(new CaseBuilder()
                    .when(member.age.between(0, 20)).then("0-20살")
                    .when(member.age.between(21, 30)).then("21-30살")
                    .otherwise("기타")
            )
            .from(member)
            .fetch();

    for (String result : results) {
        System.out.println("result = " + result);
    }
}
  • 아주 단순한 경우에는 그냥 바로 when().then()을 사용하면 된다. 그러나 조금 더 복잡한 경우에는 CaseBuilder()를 사용할 수도 있다.

나는 개인적으로 Case문을 좋아하지 않는다. 가끔 효율적일 때가 있겠지만, 100% 데이터를 퍼올려서 애플리케이션 레벨에서 이 과정을 대체할 수 있기 때문이다. 데이터베이스에서 굳이 이 계산을 할 필요가 없다고 생각한다. 

 

상수, 문자 더하기

이 경우는 꽤나 자주 사용된다.

@Test
void constant() {
    List<Tuple> results = queryFactory
            .select(member.username, Expressions.constant("A"))
            .from(member)
            .fetch();

    for (Tuple result : results) {
        System.out.println("result = " + result);
    }
}

@Test
void concat() {
    // {username}_{age}
    List<String> results = queryFactory
            .select(member.username.concat("_").concat(member.age.stringValue()))
            .from(member)
            .where(member.username.eq("member1"))
            .fetch();

    for (String result : results) {
        System.out.println("result = " + result);
    }
}
  • 상수가 필요하면, Expressions.constant("xxx") 이와 같이 사용하면 된다.
  • 그러면, SELECT절에 동일한 상수를 넣어서 다음과 같이 결과가 출력된다.
result = [member1, A]
result = [member2, A]
result = [member3, A]
result = [member4, A]
  • 이제 문자를 더하는 경우도 있는데, 같은 문자면 상관이 없는데 만약 문자와 숫자라면 자바는 타입에 매우 민감한 언어이기 때문에 단순히 더하는걸로 안되고 위 코드처럼 stringValue()로 형변환을 해줘야 한다.
result = member1_10

 

728x90
반응형
LIST

'Querydsl' 카테고리의 다른 글

참고: 리포지토리 지원 - QuerydslRepositorySupport  (0) 2024.12.30
JPA 레포지토리와 Querydsl  (2) 2024.12.26
Querydsl 중급 문법  (0) 2024.12.22
[Renewal] QueryDsl  (0) 2024.12.07
Spring Boot 3.1.5에서 QueryDSL 설치하기  (0) 2023.11.26

+ Recent posts