꾸준히 공부중

다대다 관계의 경우 실무에서는 지양해야 하는 방식이라고 하지만, 그냥 사용하지 않는 것이 아니라 그 이유는 알고 있어야 하므로 다대다 관계에 대해서 정리 해보려고 한다. 샘플 코드는 가장 아래에 있는 링크를 참조하면 된다. 1. 객체와 테이블의 차이 객체 객체는 컬렉션을 사용해서 객체 두 개로 다대다 관계 가능하다. 관계형 DB 관계형 DB는 정규화된 테이블 두 개로 다대다 관계를 표현할 수 없다. 그러므로 연결 테이블을 추가해서 일대다 - 다대일 관계로 풀어내야 한다. 2. 단방향 @ManyToMany 어노테이션을 사용하여 다대다 관계를 매핑한다. 엔티티 예시 @JoinTable: 연결 테이블 지정 @Entity @Table(name = "ORDERS") @NoArgsConstructor(access ..

값 타입(value object) 컬렉션은 제약 사항이 존재해, 실무에서 잘못된 방식으로 사용할 수 있을 것으로 보여 공부한 내용을 샘플 코드와 함께 정리해두려고 한다. 테스트 코드는 쿼리 확인을 위한 용도로 assert 구문은 제외하였다. 1. 개요 값 타입을 하나 이상 저장하려면 컬렉션에 보관하고 @ElementCollection, @CollectionTable 어노테이션을 사용하면 된다. 단, 식별자가 없는 값 타입의 특성 상 제약사항이 존재하는데 이는 뒤에서 자세히 살펴볼 예정이다. 2. 어플리케이션 구성 entity 샘플 코드는 회원 객체가 여러 주소 이력(값 타입 컬렉션)을 가지고 있는 형태로 되어 있다. 값 타입 컬렉션을 사용하는 addressHistory에 @ElementCollection..

TDD, 클린 코드 with Java 교육 중에 메모리 DB를 효율적으로 사용할 수 있는 방법을 배워, 샘플 코드와 함께 정리를 해두려고 한다. 이걸 잘 활용하면, 실무에서 초기 개발 환경 세팅을 눈에 띄게 편하게 만들 수 있을 것 같다 🔥 1. 개요 기존 방식의 문제점: 테스트용 파일 DB 그동안 실무에서 DB에 의존적인 코드를 테스트하기 위해서는 아래와 같은 순서로 보통 작업을 했었다. 문제는 테스트를 위한 DB 파일을 관리해야 한다는 것이고, 테이블이 변경될 때마다 DB 파일도 함께 업데이트 해야한다는 점이다. - (h2 기준으로) 테스트용 DB 파일 생성 - properties(혹은 yml)에 DB 경로 설정 - 테이블이 변경될 경우, 테스트용 DB 파일을 수정 인메모리 DB가 있다는 건 알고 있..

HTTP API 성능 테스트 중에 서버 자원은 남아 있지만 HTTP 요청 수를 늘려도 성능이 선형적으로 늘어나지 않는 문제가 있었고, 이것을 어떤 과정으로 해결했는지 기록을 남겨두고자 한다. 결론 결론부터 얘기하자면 서비스에 트랜잭션 락이 걸리면서, HTTP 쓰레드의 상태가 대부분 TIMED_WAITING이 되어 성능이 일정 수준에 머무르게 되었다 😓 다행히 테스트가 필요한 API는 DB access를 하지 않고 있어 트랜잭션 처리를 하지 않는 것으로 수정하여, TPS 기준으로 성능이 약 35% 증가되었다 😲 분석 과정 request thread 수를 조정하여 테스트 스프링 부트에서 사용되고 있는 WAS는 톰캣이었고 thread 갯수를 별도로 조정(server.tomcat.threads.max)하지 않..

지난 4월 3일부터 8.5주간 NEXTSTEP의 TDD, 클린 코드 with Java를 수강하게 되었다. 여타 강의와 다르게 해당 강의는 수동적으로 강의를 듣고 끝나는 것이 아니라, 스스로 미션을 수행하고 코드 리뷰를 받으며 진행되는 커리큘럼이다. 이 과정을 그냥 흘려보내기엔 아쉬울 것 같다는 생각이 들어, 코드 리뷰를 받은 내용 위주로 포스팅을 하려고 한다. 회사에서 어떻게 하면 코드 리뷰 문화를 정착시킬 수 있을까를 고민하고 있는데, 이 과정을 통해 그에 대한 힌트를 얻을 수 있기를 🔥 1. Collection 검증 리뷰 전 // size() int size = numbers.size(); assertThat(size).isEqualTo(3); // contains assertThat(numbers...

최근에 어플리케이션이 기동되는 동안 주기적으로 특정 작업이 수행되어야 한다는 요구사항이 있었다. 구체적으로는 MQ에서 메세지를 주기적으로 가져와야 하는 상황이었는데, 내부에서 사용하는 어플리케이션이 아니라서 누구나 유지보수 할 수 있도록… 이전에 공부했던 Spring Integration 같은 프레임워크를 사용하지 않아야 했다. 신입 시절에도 이와 비슷하게 DB에서 값을 폴링하여 특정 상태를 체크하는 요구사항이 있어 "쓰레드 풀을 생성하고, 비동기로 무한 루프를 돌면서 DB를 특정 시간 간격으로 조회하는 쓰레드를 실행"하는 조악한 방식을 쓴 적이 있는데(이 일과 관련해서도 할 말이 많다…), 아래의 짤처럼 언제까지 과거에 머물러 있을 수 없으니 조금 더 우아한 방식으로 스케줄링 작업을 개발해보려고 한다...

사내에서 배치 작업을 스케줄링이나 HTTP API가 아닌 DB polling로 기동하길 원하는 요구사항이 있어, 어떤 방식으로 구현하면 좋을지 찾다보니 Spring Integration를 활용할 수 있을 것 같아 학습 겸 Baeldung 자료를 기반으로 소개 및 튜토리얼 자료를 작성해보려 한다. 그리고 Spring Integration에 대한 기본적인 개념을 학습한 후에 이를 활용한 DB polling에 대한 포스팅을 해야겠다. 1. 소개 이 글에서는 실용적인 예제를 통해 Spring Integration의 핵심 개념을 소개한다. Spring Integration은 엔터프라이즈 아키텍처에서 시스템들과 프로세스들 간의 상호 연결성을 크게 향상시킬 수 있는 많은 요소들을 제공한다. 그리고 널리 사용되는 디자..