업무 중 QueryDSL관련 성능 튜닝을 진행하는 중 알게된 내용에 관해 기술합니다. 예제 코드는 github에 업로드 되어 있으며 repository내 테스트 코드로 확인 가능합니다. https://github.com/cobiyu/querydsl-subquery GitHub - cobiyu/querydsl-subquery Contribute to cobiyu/querydsl-subquery development by creating an account on GitHub. github.com QueryDSL에서 from subquery가 필요한 이유 커버링 인덱스 querydsl-jpa에서는 커버링 인덱스를 통한 조회 성능 튜닝의 경우에도 from절의 subquery가 불가능하기 때문에 아래와 같은 방식..
멀티 모듈 구조의 프로젝트를 개발하는 과정에서 Exception에 대해 기존 단일 모듈 프로젝트의 구조와는 다르게 설계해야겠다는 생각이 들었습니다. 그 과정에서 고민했던 내용을 기술합니다. 멀티모듈에서 Exception 처리를 고민하는 이유 모듈간 의존성 규칙 문제 상황 예시 : web모듈에서 결국 jpa의존성이 필요하게 되는 상황 web, batch, store-jpa, resclient 등으로 여러 모듈로 나누면 각 모듈은 자신이 꼭 필요한 의존성만을 포함해야 합니다. 하지만 가끔 기존 관성에 의해서 아래와 같이 web 모듈에서 바로store-jpa 모듈의 참조가 이루어져야 하는 경우가 있습니다 @RequiredArgsConstructor public class WebModuleSomeService ..
이전 글과 이어져서 작성되는 글입니다. https://cobbybb.tistory.com/25 @Transactional에 관한 고찰 (or 반성) @Transactional..??? Spring이 알아서 해주잖아..? Spring + JPA 로 개발하다 보면 눈에 보이지 않는 것들에 대해서 놓치고 개발하는 경우가 빈번하게 생깁니다. 생각보다 많은 개념이 들어가 있는 @Transaction cobbybb.tistory.com TransactionManager와 EntityManager 이전 글에서 Spring에서 @Transactional이 어떤 식으로 트랜잭션을 관리하는지에 TransactionManager를 중심으로 알아보았습니다. 이번엔 spring에서 일반적으로 사용하는 JPA의 Transacti..
회사명만 넣으면 발생하는 IDE의 초록줄 IDE의 모든 밑줄을 없애고 싶은 강박증의 개발자 A씨... 하지만... 변수명에 회사 이름만 넣으면 보이는 저 초록줄.... 개발자라면 한번쯤은 회사명이 들어가있는 변수를 만들어보게 됩니다. 만약 회사명이 cobbybb라는 회사라면 cobbybb라는 회사의 Id를 변수명으로 지을때 아래와 같은 상황이 발생합니다. 초록줄의 원인 IntelliJ는 cobbybb 라는 단어가 회사이름인지 모른다. 원인은 단순합니다. Intellij는 cobbybb라는 단어가 회사이름인지 모르기 때문입니다. 2가지 해결책 해결책은 크게 2가지가 있어보입니다. Intellij에 cobbybb라는 단어가 있다는것을 알려주거나 Intellij에 스펠링 체크를 disable하거나..? 그런데..
@Transactional..??? Spring이 알아서 해주잖아..? Spring + JPA 로 개발하다 보면 눈에 보이지 않는 것들에 대해서 놓치고 개발하는 경우가 빈번하게 생깁니다. 생각보다 많은 개념이 들어가 있는 @Transactional 조차도 말 그대로 Spring느님께서 다 알아서 해주니까요 😅 그러다가 장애 나거나 커스터마이징이 필요하다면...? 그러다 어느 순간 커스타마이징, 장애 등의 상황에서 대응하려고 보면 난감한 상황에 놓이게 됩니다. 그래서 구글링을 시작하지만, Spring이 알아서 해주던 영역이기 때문에 처음 보는 단어들뿐입니다. 그래서 Spring안에서 어떤 방식으로 @Transactional이 동작하는지 눈으로 확인해보려 합니다. @Transactional !!!! AOP ..
외부 API 연동 로직 개발하기 로직을 작성하다 보면 외부 API와의 연동은 피할 수 없게 되었습니다. 피할 수 없게 되었지만 테스트 코드를 짜기에는 아직도 까다로운 것도 사실입니다. 아직 Request날려볼 API 실체도 없다고....? 아직 연동 api의 실체도 없고 서로 약속한 문서만 있을 경우는 테스트 코드는 고수하고 로직 작성 조차도 더욱 까다로워집니다. (벌써 어지러워집니다...)😵💫😵💫😵💫😵💫 그래, 연동할 API 없다고 개발 못하는건 아니니까 연동할 API의 실체가 없다고 개발못하는건 아닙니다. 약속된 문서가 있기때문에 문서 기준으로 가능한 로직을 작성해 봅니다 실체가 없는 외부 API 연동 로직 먼저 개발하기 연동 API 명세 1. GET URL : http://user-api.c..
Memory db를 이용한 Repository Test Repository layer의 테스트를 위해서 내장 Memory DB를 많이 사용합니다. Memory DB 를 사용하는 방법도 천차만별일텐데 크게는 2가지 정도라 생각됩니다. @SpringBootTest+ Memory DB 연결 @DataJpaTest 두 방법의 차이점과 [Junit & JPA의 영속성 컨텍스트]로 인한 여러 가지 현상에 대해 정확히 알기 위해 글을 작성합니다. 두 가지 방법의 쿼리 로그가 다른데? 위 2가지 방법 중 어느것을 선택해서 Repository Layer 테스트를 진행할까 고민하던 중 제 예상과는 다른 쿼리 로그가 찍히는 것을 확인했습니다. 테스트한 코드는 아래 2가지입니다. 예제 코드 // Member.java @Get..
IntelliJ에서 자주 보이는 메세지...? Lambda can be replaced with method reference Anonymous new Consumer() can be replaced with lambda Anonymous new Consumer() can be replaced with method reference IntelliJ를 이용해서 개발하다보면 위와같은 메세지와 함께 여러 Refacotring 들이 생깁니다. 그리고 어떤 옵션을 선택하는 순간 마법처럼 IntelliJ가 코드를 간결하게 만들어줍니다. IntelliJ의 유혹(?) 이런 IntelliJ의 유혹(?)에 견디지 못해 막 실행하다보면 왜 이렇게 코드가 변했는지 알지 못하고 해당 로직에서 문제가 발생했을 때 트러블 슈팅에서..
