오늘의하루

JPA를 사용하면서 deleteByCouponId(Long couponId)와 같은 네이밍 메서드를 활용하면 간편하게 특정 ID를 기반으로 데이터를 삭제할 수 있지만 이러한 메서드를 사용할 때 몇 가지 주의해야 할 점이 있습니다.deleteByCouponId의 동작 방식JPA에서 deleteByCouponId와 같은 메서드를 실행하면 내부적으로 다음과 같은 과정을 거칩니다.먼저 couponId를 기반으로 해당하는 엔티티 목록을 조회합니다.조회된 엔티티들을 하나씩 순회하면서 EntityManager의 remove 메서드를 호출하여 삭제합니다.삭제된 엔티티는 1개씩 flush 되며 트랜잭션이 걸려 있다면 커밋 시 최종 반영됩니다.이 과정에서 단순히 deleteByCouponId를 호출하면 SQL의 DELET..

readonly 상태라면 영속성도 readonly일까? 라는 궁금증이 들어 테스트 코드를 작성하면서 알게 된 알아둬도 정말 쓸데 없는 내용을 공유하려고 합니다. Hibernate에서 readonly 힌트를 사용하면 해당 엔티티를 조회할 때 스냅샷을 만들지 않게 됩니다.이로 인해 더티 체킹이 발생하지 않으며 결국 수정 쿼리가 DB에 나가지 않게 됩니다.즉, readonly는 DB 쿼리 측면에서 수정할 수 없도록 만들어줍니다.그런데 readonly 상태에서도 엔티티의 필드를 수정해봤더니 수정 쿼리는 발생하지 않지만 1차 캐시에는 수정된 값이 반영되는 걸 알게 되었습니다.@Test@Transactional(readOnly = true)void queryHint() { // given Member m..

1. 벌크 연산 (Bulk Operation)이란?벌크 연산이란 N개의 데이터를 한 번에 UPDATE 또는 DELETE 하는 작업을 의미합니다.Spring Data JPA에서 벌크 연산을 수행하기 위해서는 @Modifying이 필요합니다.2. 왜 필요할까?Spring Data JPA에서는 기본적으로 Query 메서드의 반환 값을 getResultList() 또는 getSingleResult()를 통해 처리하는데 이는 SELECT에서만 사용 가능합니다.이러한 이유로 UPDATE와 DELETE는 수정 또는 삭제된 행의 개수를 반환하게 되기 때문에 반환 값을 맞추기 위해서 @Modifying이 필요한데 만약 사용하지 않는다면 아래와 같은 예외를 맞이할 수 있습니다.예외 클래스 : InvalidDataAcces..

Cascade Type 속성Cascade는 부모 객체의 상태 변화가 자식 객체에게 영향을 미칠지 여부를 설정하는 기능이며 양방향 관계에서 외래 키를 가지지 않는 객체를 부모라고 칭할 때 각 Cascade 유형의 의미는 다음과 같습니다.@Entitypublic class Team { ... @OneToMany(mapped by = "team") private List members = new ArrayList(); ...}1. PERSIST부모 객체를 저장할 때 자식 객체도 자동으로 DB에 저장할 수 있습니다.예를 들어, members.add(...)와 같이 부모 객체에 자식 객체를 추가한 후 Team 객체를 저장하면 Member 객체도 함께 저장됩니다.주의 사항: 자식 테이블에서 부..

API를 설계하다 보면 서로 다른 요청 데이터 타입에 공통 필드가 반복적으로 존재하는 경우가 많습니다.이 상황에서 새로운 공통 필드가 추가되거나 변경될 때 모든(1억개) DTO를 수정해야 하는 번거로움이 발생합니다. DTO(Data Transfer Object)를 쓰는 이유?"Controller에서는 DTO로 요청 정보를 받는 게 좋다."라는 말을 개발 공부를 시작했을 무렵 접하게 되었습니다.하지만 이유를 정확히 알지 못한 상태에서 사용해 오다가 이번에 JPA 공부를 하면서 그jangto.tistory.com1. 문제사항처음 API를 설계할 때 공통 내용을 요청받는 DTO를 각각 따로 만들었다고 가정합니다.예를 들어 BookRequest, AlbumRequest, MovieRequest라는 요청 DTO가..

오류 발생 시점 Spring Security와 JWT를 통해 인증 인가를 진행하려고 했고 Jwt Filter에서 @Transactional를 사용했기 때문에 발생하였다. 원인 정확한 원인은 아닌 것 같지만 @Transactional 어노테이션을 사용하면 스프링은 해당 메서드를 실행할 때 트랜잭션을 시작하려고 하지만, 이미 실행 중인 트랜잭션이 없기 때문에 오류가 발생할 수 있습니다. 느낀점 내가 @Transactional을 적용한 곳은 단순히 데이터를 조회하는 용도이므로 트랜젝션이 필요없다. 트랜젝션 관리는 데이터를 변경하는 작업에만 필요하다는건 알고 있었지만 깜빡하고 썻던거 같다. @Transcational은 일반적으로 서비스 계층에서 DB 트랜젝션을 처리하는데 사용된다. 그리고 필터에서 DB에 직접 ..

예외 발생 이유 이 예외는 Fetch Join을 할 때 발생하게 되는데 원인은 2개 이상의 컬렉션이 있는 상태에서 Fetch Join을 하는 경우에 발생하게 된다. 어쩌다 발생했을까? C Entity와 B Entity는 N:1 관계이고 B Entity와 A Entity는 N:1 관계이고 모두 지연 로딩(LAZY)로 되어있다. A Entity에서 특정 Id값으로 조회하여 조회되는 데이터를 Json 형식으로 보내려고 했다. 처음에 별 생각 없이 A Entity 자체를 보내게 되었는데 이때 Stack Overflow가 발생하고 넘어간 데이터를 보니 재귀현상이 발생하고 있었고 이 문제를 해결하기 위해 Fetch Join을 사용하면서 발견했다. 해결 방안 쿼리를 분리하자! 여러 개의 컬렉션을 가져와야 할 경우, ..

예외 발생 이유 세션이 사라진 후 지연 로딩(LAZY) 상태에서 프록시 초기화가 불가능하기 때문에 발생하는 예외 지연 로딩 ( FetchType.LAZY ) 지연 로딩을 하는 이유는 JPA에서 발생하는 문제 중 가장 유명한 N + 1 문제를 해결하기 위함이다. 지연 로딩은 한번에 연관된 데이터까지 한번에 불러오는 것이 아닌 연관된 데이터를 필요한 시점에 그때 그때 불러오는 것이다. 그래서 왜 지연 로딩을 쓰는가? 예를 들어 Member과 Team테이블이 있고 Member와 Team는 N:1 관계가 있다. 이때 즉시 로딩(EAGER)을 하게 된다면 Team을 조회 시 해당 Team을 가진 모든 Member를 하나씩 조회하게 된다. 분명 Team 1개를 조회했는데 Team에 속한 Member N개의 조회 쿼..

JPA에서 연관 관계 매핑에 대해 쉬운 이해를 하기 위해서는 객체와 테이블의 연관 관계의 차이를 이해해야한다. 객체를 테이블에 맞추어 그대로 모델링 한다면 객체 간 협력 관계를 만들 수 없게 된다. 테이블은 외래키(FK)로 조인하여 연관 된 테이블을 찾을 수 있지만 객체는 참조를 통해 연관된 객체를 찾을 수 있게 된다. 아래는 Member 테이블과 Team 테이블이 N:1관계일때 Entity를 어떻게 만들어야 하는지에 대해 작성하였다. Member 테이블은 Team 테이블의 Id값을 외래키(FK)로 가지고 있다. // 객체를 테이블에 맞추어 데이터 중심으로 모델링 한 경우 @Entity public class Team{ @Id @Column(name = "TEAM_ID") private Long id; ..

JPA에서 기본키를 매핑하는 방법은 @Id, @GeneratedValue 이렇게 두가지가 있다. @Id의 경우 직접 할당 하겠다는 의미이기 때문에 별다른 내용이 없다. 매핑 방법 @GeneratedValue는 자동 생성을 해주는 것이다. SEQUENCE : DB의 시퀀스 사용 ORACLE의 경우 @SequenceGenerator가 필요하다. IDENTITY : DB에 위임 TABLE : 키 생성용 테이블을 만들어서 사용한다. @TableGenerator가 필요하다. 장점으로는 모든 DB에서 공통적으로 사용가능하다. 단점은 테이블이 생겨나기 때문에 추후 성능에 좋지 않다. AUTO : Hibernate에서 지정한 방언에 따라 자동으로 지정된다. (기본값) IDENTITY 전략 - 매핑 이 전략은 기본 키 ..