10장 객체지향 쿼리 언어 (2)

[MinJunKweon]

10.4 QueryDSL
10.5 네이티브 SQL
10.6 객체지향 쿼리 심화
10.7 정리

[minkukjo]

끄적끄적

• JPA Criteria는 QueryDSL처럼 동적 쿼리에 대한 문제를 풀어보고 싶어서 나왔으나, 너무 복잡하고 어려워서 만들어진 코드로 어떤 SQL이 실행될지 알기가 어려움.
• 이젠 JPA + QueryDSL 조합은 마치 라면과 김치처럼 뗄레야 뗄 수 없는 사이가 되어버림.
• 그럼에도 불구하고 JPA에서 QueryDSL은 정식으로 인정해주지 않고 있음.
• 사실 QueryDSL로 복잡한 SQL을 옮겨와보면, Criteria처럼 이해하기가 어려움.
• 그러나 사실 그 문제는 QueryDSL의 문제라기 보다는, 그렇게 거대한 한 방 쿼리를 만드는 것에서 부터 잘못된게 아닐까? 라는 생각이 들었음.
• 최근 팀원들과 플랫폼 구조 개선 과제를 진행하면서, 도메인과 Join에 대한 이야기를 나눔.
• Join을 한다는 것은 서로 다른 테이블을 엮는 건데, 이 지저분함이 결국 코드로까지 가져와져서 오염시킬 수 있지 않냐는 것이엇음.
• 사실 Join을 사용하지 않고, 쿼리를 여러 번 날리는 것으로도 해결할 수 있긴 함.
• 다만 개발자들이 Join을 선호하기도 하고, 애초에 DB에서 지원해주는 기능이다 보니 다들 별 의문을 갖지 않고 사용하고 있지만, ORM을 사용하는 우리 입장에서 Join은 과연 객체지향을 잘할 수 있게 해주는 도구인가? 를 생각해볼 필요가 있음.
• 그걸 좀 객체지향스럽게 해보겠다고 JPA에서 Relational Mapping을 만들어냈는데... 이것도 결국은 N+1 문제가 생겨서, Fetch Join이니 Entity Graph니 하는 끔찍한 것들을 추가로 만들어 버리고 말았음.
• Relational DB에 의존적이지 않게 개발을 하려면 결국 CQRS 밖에는 답이 없는건가? 라는 생각이 요즘은 자주 들고 있음...

jOOQ는 대안이 될 수 있으려나?

• jOOQ와 관련된 글이 몇 개 보이지만, jOOQ는 기본적으로 ORM이 아님.
• JPA를 사용하는 이유는, 생산성의 향상인데 jOOQ를 쓰다보면 모든 것을 다 SQL로 만들어야해서, 오히려 CRUD를 간단하게 만들어줄 수 있는 JPA에 비해 불편한 감이 없지않아 있는 것 같기도 함.
• 게다가 JPA 자체 기능들 ( Dirty Checking, 1차 캐시 )이 편리성을 주는 부분들도 분명히 있어서, 이걸 버리고 jOOQ로 넘어갈 정도는 아닌 것 같음.
• https://sightstudio.tistory.com/54
• https://happy-coding-day.tistory.com/entry/Hibernate-JPA-Querydsl%EB%8A%94-%EA%B3%BC%EC%97%B0-%EC%A2%8B%EC%9D%80-%EB%8F%84%EA%B5%AC%EC%9D%BC%EA%B9%8C

Stroed Procedure

• 제발 이런 것 좀 쓰지 맙시다.

벌크 연산

• 하이버네이트의 벌크연산은 불안정함.
• 이걸 위해 JDBC를 써야한다는 것도 참 불편한 점이긴 하나, 하이버네이트 구조상 그럴 수 없다는 것도 이해가 가는 부분임.
• 결국 벌크 연산은 하이버네이트를 못쓴다는 것도 참으로 아쉬운 부분 중 하나.

JPQL과 findById의 차이

• EntityManager의 경우 1차캐시에서 찾지만, JPQL은 항상 SQL을 날려서 DB에서 찾아온다.
• 즉, 영속성 컨텍스트에서 관리되고 있는지의 유무와 무관하게 항상 DB로부터 찾아옴.
• 물론 JPQL로 조회해온 데이터는 영속 상태로 관리된다.

JPA 플러시모드

• 개인적으로 이 플러시 모드로 인해서 더 복잡해지는게 아닌가 싶다.
• 개발자에게 자유도를 준 것은 좋으나, 복잡한 로직에서 플러시 쿼리가 숨겨져있으면, 이후 로직 파악하는데 어려운 경험이 있었다는 팀 내 개발자의 이야기를 들은 적 있음.

[LOG-INFO]

끄적끄적

• 이번장은 그냥 굉장히 많은 기능들을 소개해주는 장이었던 것 같다. 그냥 이런게 있구나 하고 넘어가고 나중에 필요할 때 '아 그런게 있었는데!' 하고 다시 찾아보는 정도로 딱인 듯
  • • Criteria vs QueryDSL 비교
• Criteria 보다가 QueryDSL 보니까 굉장히 단순하고 직관적이다
• Criteria, QueryDSL 둘 다 컴파일 타임에 에러를 체크할 수 있지만, Criteria는 중간중간 문자열을 사용하는 곳이 있어서 완벽하진 않다
  • Meta Model이란게 있긴 하다
• p.419. CASE 식 -> 이런건 그냥 어플리케이션에서 하자...
• 네이티브 SQL은 사실 쓸 일이 드물 것 같다
• 벌크 연산 시 영속성 컨텍스트를 무시하고 DB에 직접 쿼리한다는 점을 주의해야한다

[MinJunKweon]

끄적끄적

• QueryDSL이 확실히 지난 스터디 때 보았던 Criteria에 비해 훨씬 간편한 느낌이었음
• Criteria과 마찬가지로 엔티티에 대한 메타 모델을 사용해서 TypeSafe한 SQL을 작성할 수 있다는 점에서 더더욱 Criteria를 쓸 이유가 없어지는듯
• 이번 장은 구현에 대한 코드 설명이 대부분이라 아직 JPA를 제대로 써보지 않은 입장에서는 그냥 슉슉 넘어가게 되었음
• JPA에도 역시 벌크 연산을 지원하는 걸보니 Spring Batch 프로젝트의 JpaItemWriter에서도 이걸 사용하는걸까하고 찾아봤더니 사용하고 있지는 않았다.
  • merge()와 persist()를 쓰고 마지막에 flush()를 명시적으로 하고 있었음

  • protected void doWrite(EntityManager entityManager, Chunk<? extends T> items) {
            // ...
    	if (!items.isEmpty()) {
    		long addedToContextCount = 0;
    		for (T item : items) {
    			if (!entityManager.contains(item)) {
    				if (usePersist) {
    					entityManager.persist(item);
    				}
    				else {
    					entityManager.merge(item);
    				}
    				addedToContextCount++;
    			}
    		}
    		// ...
    	}
    }

• QueryDSL를 보다보니 Kotlin Exposed ORM에서 사용하는 방식과 비슷하다는 느낌을 많이 받았음

Kotlin Exposed - Repo

• 젯브레인에서 관리하는 Kotlin ORM 프레임워크
• 몇 년이 지났는데 아직 0.44.0 버전이라 프로덕션에서는 사용하기 힘들거 같습니다. 그래도 프로젝트는 활발한 편입니다
• 몇 년전에 사이드 프로젝트에서 사용해보려고 하였으나, 불친절한 도큐먼트, 많지않은 레퍼런스, 환경 구성하다 만난 알 수 없는 에러에 막혀서 포기했었습니다 ;(
• Exposed도 ORM 답게 특정 DB를 겨냥한 것이 아니라서 driver만 교체해주고 설정 몇가지만으로 여러 DB로 마이그레이션이 쉽게 하는 방식을 추구하고 있습니다
• 하이버네이트처럼 (문서에서도 하이버네이트와 비슷하다고 명시해놓았네요) DAO API를 제공하고 있어서 좀더 코틀린스럽게 ORM을 사용하기 쉽다는 장점이 있습니다
  • 엔티티 CRUD 뿐만 아니라 Many-to-one 같은 레퍼런싱을 구현하는 방식 등등 생각보다 많은 기능을 제공하고 있네요
• DAO 뿐만 아니라 DSL을 따로 제공하고 있는데, DSL을 사용하게 되면 실제 SQL로 변환되는 Kotlin DSL을 사용할 수 있습니다. QueryDSL이나 Criteria의 역할을 하는 걸로 보입니다
• QueryDSL에도 되는지 모르겠으나 Window Fuction, GROUP BY 및 통계성 함수를 DSL로 제공하고 있어요
• 다만 프로젝트 성숙도가 높은 편은 아니라서 프로젝트에 도입할 지는 많이 고민해봐야겠네요
• 자세한건 Exposed Wiki를 참조하시면 재밌는 내용이 많아요

Exposed + 코루틴 스택으로 Non-Blocking 비동기 쿼리가 가능한가?

• 답변 : https://github.com/JetBrains/Exposed/wiki/Transactions#working-with-coroutines
• Non-Blocking은 사용할 수 없다고 하네요ㅠ
• Exposed가 JDBC-api를 사용하는데, 이게 Blocking I/O를 겨냥해서 설계된 API라서 불가능하다고 합니다. Exposed에서 쿼리 결과 값을 ThreadLocal에 저장하기 때문에, 코루틴을 사용하게되면 ThreadLocal 값이 보장되지 않아서 사용할 수 없다고 하네요

[HaeUlNam]

10장 객체지향 쿼리 언어 - 2

끄적끄적

• QueryDSL도 Criteria처럼 JPQL 빌더 역할을 하는데, JPA Criteria를 대체할 수 있다
• QueryDSL은 이름 그대로 데이터를 조회하는데 기능이 특화되어있다
• 문자가 아닌 코드로 안전하게 쿼리를 작성하고 싶은 것과 복잡한 동적 쿼리를 어떻게 해결해야 하는가에 대한 답이 QueryDSL
• QueryDSL 관련해서 글을 좀 찾아봤다.

더 알아본 내용

• N+1 Issue: https://jojoldu.tistory.com/165
• QueryDsl 적용하기: https://jojoldu.tistory.com/372
• QueryDsl 연관관계 없이 Join하기 with on: https://jojoldu.tistory.com/396
• QueryDsl 다이나믹 쿼리 - BooleanExpression 사용: https://jojoldu.tistory.com/394
  • QueryDsl의 where 절은 null이 들어올 경우 무시
• QueryDsl 페이징 성능 개선하기 - https://jojoldu.tistory.com/528(on going)