
JPA를 사용하여 데이터를 조회할 때, 예상과 달리 쿼리가 빈번하게 실행되는 문제를 발견할 수 있다.일반적으로는 단일 쿼리로 모든 관련 데이터를 불러올 것으로 기대하지만, 실제로는 각 연관 엔티티에 접근할 때마다 추가 쿼리가 발생한다.이러한 현상은 Lazy Loadin

개발 중에 종종 Querydsl의 추상화 기능에 의존해 실제 데이터베이스 쿼리의 형태를 면밀히 검토하지 않는 경우가 많은 것 같다. → 저의 이야기 입니다…특히, 단일 쿼리에서 필요한 모든 정보를 얻기 위해 엔티티를 직접 select 문에 포함시키는 실수를 범하기 쉽다

QueryDsl Select시 성능 최적화 1부를 읽고 오시는 것을 추천드립니다.https://velog.io/@devty/QueryDsl-Select시-성능-최적화-1부1부에서 사용했던 Entity를 그대로 사용하도록 하겠다.Entity들의 연관관계Categ

테스트 코드에서 멱등성(idempotence)은 테스트가 얼마나 신뢰할 수 있고 재현 가능한지를 결정하는 중요한 요소이다.멱등성을 가진 테스트는 동일한 조건과 입력 값으로 여러 번 수행되어도 동일한 결과를 보장한다.이는 테스트의 신뢰성을 높이고, 다양한 환경에서의 안정

기본적인 Slack WebHook API Key 발급 관련해서는 다른 블로그들에서도 많이 나오니 넘어가도록 하겠다.AOP 관련 내용들도 간단하니 넘어가도록 하겠다.그리고 다른 블로그들을 확인 했을 때, 거의 90% 이상이 Request에 대한 매핑은 없는 것을 확인할

이번 글에서는 DirtiesContext 제거와 데이터베이스 초기화 최적화에 대해 이야기하려고 합니다.프로젝트 초기에는 DirtiesContext를 사용하여 테스트 환경을 초기화했지만, 테스트 개수가 늘어감에 따라 속도 문제와 유지보수 비용이 커졌습니다. 이 문제를 해

첫 번째 글에서는 DirtiesContext를 제거하고 DatabaseCleaner를 도입하여 테스트 속도를 비약적으로 개선한 사례를 소개했습니다.이번 글에서는 테스트 컨텍스트 관리와 통일성 확보에 대해 이야기하려고 합니다.스프링 테스트는 애플리케이션 컨텍스트(Appl

Flush의 정의와 역할영속성 컨텍스트(1차 캐시): 애플리케이션이 조회·변경한 엔티티 객체를 메모리에 보관하는 공간Flush: 이 메모리상의 변경사항(INSERT, UPDATE, DELETE)을 SQL로 변환해 데이터베이스에 보내는 과정단순히 “변경을 내보낸다”가 아

서비스를 만들다 보면 내부적으로만 쓰는 로직을 private 함수로 빼는 건 흔한 패턴임예를 들어 아래 코드처럼여기까진 깔끔해 보이고 재사용성이 없기에 private로 빼는건 거의 국룰임하지만 이렇게 되면 문제가 생김filterPostsForUser()는 private

저의 Spring Boot와 Kotlin 프로젝트에서 DateTimeUtils 유틸리티 클래스는 날짜와 시간 관련 공통 로직을 제공합니다.처음에는 모든 메서드를 companion object의 정적 메서드로 구현했지만 테스트 코드 작성의 어려움과 확장성 문제로 인스턴스

N+1 쿼리는 한 번의 논리적 요청이 수십, 수백 개의 데이터베이스 쿼리로 폭발하는 현상을 말합니다.주로 ORM(Object-Relational Mapping)의 지연 로딩(Lazy Loading) 때문에 발생하며, 불필요한 네트워크 왕복과 데이터베이스 부하 증가로 이