문제 상황SpringBoot의 Junit5에서 Memory DB를 사용하여 Repository 계층을 테스트하는 방법은 크게 두가지가 있습니다.1. @DataJpaTest 활용2. @SpringBootTest + MemoryDB이중 @DataJpaTest를 활용하여 Repository계층을 테스트하는 상황에서 만난 오류를 정리해보려고 합니다. 오류의 내용은 MEMBER라는 테이블을 찾을 수 없어 sql 쿼리를 준비할 수 없다는 내용이었습니다.분명 application-test.yml 파일은 다음과 같이 ddl-auto를 create로 설정하여 테이블을 생성하도록 하였고@ActiveProfiles("test") 어노테이션을 사용하여 해당 설정파일을 읽도록 하였습니다.도무지 이해할 수 없는 에러였습니다.로그..
1. 문제인식프로젝트를 진행중 Reservation 엔티티와 Review 엔티티는예약을 한 사용자만 리뷰를 작성할 수 있도록 일대일 관계로 매핑되어있습니다.@Entity@Getterpublic class Reservation extends BaseEntity { @Id @GeneratedValue(strategy = GenerationType.IDENTITY) @Column(name = "reservation_id") private Long id; ... @OneToOne(mappedBy = "reservation") private Review review; } @Entity@Getter@Table(name = "rental_home_review")p..
현재 aws의 프리티어 등급의 EC2(1gb ram, 30gb ssd)와 RDS(MySql, 1gb ram, 2gb storage)그리고 ElastiCache(Redis, 0.5 gb ram)을 사용하여 springboot 프로젝트를 배포하고 있습니다. 대상으로 하는 조회 엔티티는 다음과 같습니다. 1. 현상현재 Repository 클래스에서 join을 통해 review의 평균점수, 개수를 기준으로 정렬하여 데이터를 조회하고 있는데아래는 데이터 20만건을 조회하였을때 평군 3초의 로딩시간이 소요되는것을 확인했습니다. 2. 워밍업 - 상속/구현을 사용하지 않고 querydsl 사용하기이전에 querydsl을 사용할 때에는 다음과같이 별도의 ~RepositoryCustom이라는 인터페이스를 생성하고해당..
aws에 spring boot로 만든 프로젝트를 배포 후에 생각지 못한 현상을 발견하게 되었습니다.첫번째 응답에서 매우 느린 응답 지연현상을 발견했기 때문입니다. 처음에 이유는 분명 어딘가에서 쿼리 결과를 캐싱하고 있다고 생각했습니다. (이제와서 다시보니 캐싱되었다고 보기에는 3초의 시간은 너무 느리네요ㅎㅎ..)현재는 따로 쿼리 결과를 Redis에 캐싱하지 않고 있어 어디에서 캐싱을 하고 있는지 알아내려고 했습니다. 1. 데이터베이스(Mysql) 쿼리 캐싱Mysql 8.0 버전 이상부터는 쿼리 캐싱이 제거되었다고 합니다. 따라서 8.0 버전을 쓰고 있는 저에게는 해당 사항이 없습니다. 2. JPA의 1차 캐싱Jpa의 1차 캐싱은 같은 트랜잭션 내에서 유효합니다.API를 여러번 호출 했을 때, 각 호출은 ..
