🔭Query DSL

박용민·2024년 3월 17일

Spring 공부 및 프로젝트를 하면서 DB에 매핑하는 기술로 JPA를 많이 사용하였다.
특히 많은 CRUD을 JPA로 사용하였고 객체 지향적인 방식 덕분에 SQL에 투자하는 시간을 서비스 로직에 개발하는 시간을 가질 수 있었다.

엔티티 여러게를 만들고 서로 테이블 끼리 조인을 할 수록 복잡하고 길어지는 함수명을 만들 수 밖에 없다.
JPA로 만약에 파티의 제목 또는 게임 이름으로 검색을 하려면 다음과 같은 함수명을 작성해야 한다.

Party findPartyByTitleOrGameTitle(String title, String gameTitle);

or 

@Query("SELECT p FROM Party p WHERE p.title = :title OR p.gameTitle = :gameTitle")
Party findParty(String title, String gameTitle);

이런 복잡한 쿼리를 객체 지향 쿼리 언어인 JPQL을 사용하여 엔티티를 대상으로 쿼리를 작성할 수 있다.

🔬JPQL(Java Persistence Query Language)

JPA는 SQL을 추상화한 객체 쿼리 언어로 JPQL을 제공한다.

SELECT e FROM Employee e JOIN e.department d WHERE d.name = :departmentName

public Party findPartyByTitleOrGameTitle(String title, String gameTitle) {
        String jpql = "SELECT p FROM Party p WHERE p.title = :title OR p.gameTitle = :gameTitle";
        TypedQuery<Party> query = entityManager.createQuery(jpql, Party.class);
        query.setParameter("title", title);
        query.setParameter("gameTitle", gameTitle);
        List<Party> results = query.getResultList();
        return results.isEmpty() ? null : results.get(0);
    }

그러나 해당 코드에도 단점이 있는데 메서드의 결과가 없는 경우 null을 반환하고 JPQL 쿼리가 메서드 내에 하드 코딩되어 있다.

이중 JPQL의 하드 코딩에 문제점에 대해서 지적하자면

쿼리 변경이 필요한 경우 매번 번거럽게 코드 수정을 하여 유지 보수의 어려움이 있다.
코드의 길이가 복잡해지면 가독성이 떨어지고 이해하기가 어렵다.
쿼리 오류가 어려워 런타임 시점에 오류를 발견할 수 있다.
쿼리를 동적으로 변경하거나 조합하기 어렵다.

이중 3,4번째 이유를 가장 큰 문제라고 생각된다.

먼저 프로그램을 만들면서 오류를 피하고 싶어도 생길 수 밖에 없다. 오류에도 좋은 오류가 있고 나쁜 오류가 있는데 가장 좋은 오류는 컴파일 오류 즉 빌드를 하기전에 문제점을 파악하여 실행되기 전 오류를 검출하는 방법이 가장 좋은 오류이다. 런타임 오류나 배포를 했을때 오류가 발생하면 예기치 않은 상황이 발생할 수 있고 프로그램의 안정성과 신뢰성이 낮아질 수 밖에 없다.

두번째로 쿼리 문자열에 조건을 추가하거나 수정하는 것은 문자열 조작에 코드가 더 복잡해지고 가독성이 떨어진다. 다양한 조건들을 재사용하기 어렵고 문자열로 이루어져 동적으로 처리하기 어렵다.

🧬Query DSL

http://querydsl.com/static/querydsl/5.0.0/reference/html_single/#d0e97

탄생한 배경을 살펴보면 HQL(Hibernate Query Language) 쿼리를 유형 안전한 방식으로 유지해야 할 필요성에서 탄생 했으며 문자열을 String 연결이 필요하고 코드를 읽기 어렵게 된다.

요약하면 Query DSL은 자바 코드로 쿼리를 작성할 수 있고 특히 컴파일 시점에 타입을 체크하여 타입에 안정성을 보장하고 코드의 가독성을 높여준다.
동적 쿼리를 생성할 수 있고 수정할 수 있어 유연성을 제공하며 복잡한 쿼리 작업을 수행할 수 있다.

공부하면서 처음에 필요성이 느끼지 못 했다. 동적으로 여러 쿼리를 조회한다? 그냥 JPA로 직접 조회하거나 조인 하면 될 것같은데? 라고 생각했지만 점점 규모가 커지며서 검색에 대해서 여러 필터나 검색 조건들이 많아져서 개발의 속도가 느려지게 되었고 어떤 조건들을 사용하면 좋을까 고민하다가 다음과 같은 사이트에서 영감을 얻어 프로젝트에 적용하기로 하였다.

query string에 브랜드에 무신사 스탠다드 금액을 30000~50000원 사이로 검색을 했을때 다음과 같은 url을 보여준다.

출처 무신사

출처 다나와

🌻Query DSL 적용

🌱Query DSL 의존성 추가

Query DSL을 사용하기 위해 다음과 같은 의존성을 추가한다.

# build.gradle
// querydsl
	implementation 'com.querydsl:querydsl-jpa:5.0.0:jakarta'
    annotationProcessor "com.querydsl:querydsl-apt:${dependencyManagement.importedProperties['querydsl.version']}:jakarta"
    annotationProcessor "jakarta.annotation:jakarta.annotation-api"
    annotationProcessor "jakarta.persistence:jakarta.persistence-api"

🌱Query DSL 설정

Query DSL의 설정을 추가한다. 여기에서 Qclass 파일이 생성되는데 해당 파일의 생성 위치 및 작업등을 설정한다.

Qclass

QClass는 Querydsl에서 생성되는 클래스로, JPA 엔티티 클래스에 대한 쿼리 타입을 나타낸다.
이 클래스들은 컴파일 시점에 Querydsl 어노테이션 프로세서를 통해 생성된다.
엔티티 클래스에 대한 메타데이터를 담고 있어서, 컴파일러가 타입 안전한 쿼리를 작성할 수 있도록 도와주며 문자열 대신 클래스를 사용하여
컴파일 시점에 오류를 발견할 수 있다.

# build.gradle
// querydsl 설정
def generated = 'src/main/generated' // Querydsl이 생성한 QClass 파일을 저장할 위치를 설정

// querydsl QClass 파일 생성 위치를 지정
tasks.withType(JavaCompile) {
    options.getGeneratedSourceOutputDirectory().set(file(generated))
}

// java source set 에 querydsl QClass 위치 추가 Qclass 파일이 컴파이된 자바 코드와 함께 빌드되도록 설정
sourceSets {
    main.java.srcDirs += [generated]
}

// gradle clean 시에 QClass 디렉토리 삭제
clean {
    delete file(generated)
}

// Querydsl이 생성한 QClass 파일이 JAR 파일에 포함되지 않도록 설정
jar {
    enabled = false
}

🌱Entity 추가

@Entity
@Getter
@Builder
@NoArgsConstructor(access = AccessLevel.PROTECTED)
@AllArgsConstructor
@SQLDelete(sql = "UPDATE partys SET deleted_at=CURRENT_TIMESTAMP where id=?")
@Where(clause = "deleted_at IS NULL")
@Table(name = "partys")
public class Party extends Timestamped {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    @Column(nullable = false)
    private String title;

    @Column(nullable = false)
    private String contents;

    @Column(nullable = false)
    private Boolean status;

    @Column(nullable = false)
    private int view;

    @Column(nullable = false)
    private LocalDateTime deadline;

    @ManyToOne(fetch = FetchType.LAZY)
    @JoinColumn(name = "user_id")
    private User user;

    @ManyToOne(fetch = FetchType.LAZY)
    @JoinColumn(name = "game_id")
    private Game game;
 }

🌱Gradble build

Gradle 창을 보면 build 폴더에 build라는 아이콘을 클릭을한다.
그러면 다음과 같이 gradle 파일에 query dsl에 설정된 'src/main/generated'에 QClass 파일이 생성된다.

🌱Repository 작업

QeuryDSL을 사용하기위해 4가지 파일을 사용하였다.

PartyRepository : PartyRepositoryCustom를 상속 받기 위해 사용한 기본적인 JPA 인터페이스

PartyRepositoryCustom : Querydsl의 함수를 정의하고 사용하기위해 인터페이스 선언

PartyRepositoryCustomImpl : PartyRepositoryCustom 구현체

PartySearchCondition : Querydsl의 동적 쿼리를 위한 조건들

동적 쿼리 적용 방법

BooleanBuilder

Where 다중 파라미터

where 조건에 null 값은 무시되며 쿼리 자체의 가독성이 높아지고 다른 쿼리에서도 재사용 할 수 있다.

BooleanExpression으로 SearchCondition에 검색 조건 함수를 만든다. null을 반환하면 where 절에서 해당 조건을 무시할 수 있다.

🌱결과를 DTO로 반환 방법

나는 생성자를 이용해서 결과를 반환 하는 방식을 사용했다. 엔티티 자체를 반환할지 아니면 domain으로 반환할지는 프로젝트 진행하면서 계속해서 고민해야할 사항이다.

🌱Querydsl 페이징 연동

Querydsl도 페이징 처리가 가능한데 Pageable을 인자로 받는 형태로 가능하다.

offset을 통해 Pageable의 페이지 번호를 설정하고 limit에 페이지 사이즈를 설정한다.

🌱Querydsl 정렬

정렬 처리를 보통 orderby에 삽입하면 되지만 이것 역시 동적으로 처리하기 위해서 다른 방법이 필요하다
일반 조건 명이 아닌 OrderSpecifier형이 필요하다.

OrderSpecifier

QueryDSL에서 정렬 조건을 나타내는 클래스이며 ORDER BY와 유사하게 사용할 수 있다.

먼저 Pageable 객체에서 정렬 조건을 가져온다.
정렬 조건이 존재하면 created(생성일), view(조회수)라는 정렬 조건이 존재하면 해당 조건을 리스트에 삽입한다.(정렬 조건 추가 가능)
만약 정렬 조건이 존재 하지 않으면 기본적으로 내림 차순으로 정렬하고 반환한다.