Back-end

·Back-end
🫧 @SQLDelete JPA에서 기본적인 삭제는 Hard Delete로 되어 있다. 이 삭제 방식을 @SQLDelete를 통해 쿼리를 작성해두면, delete가 호출될 때 데이터를 실제로 삭제하지 않고 미리 정의해둔 쿼리를 실행하도록 방식 변경이 가능하다. Hard Delete 물리 삭제라고도 하며, 데이터베이스에 Delete Query를 날려 해당 데이터를 실제로 삭제한다. Soft Delete 논리 삭제라고도 하며, 데이터베이스에 Update Query를 날려 해당 데이터가 삭제된 것을 하나의 컬럼을 이용하여 구분한다. @SQLDelete는 논리 삭제를 위한 기능인 것이다. 🫧 문제 발견 테스트 코드를 작성하다가 발견하게 된 문제.. @Test @DisplayName("회원을 논리 삭제한다") vo..
·Back-end
이전 포스트에서 다루었던 CascadeType.REMOVE 와 orphanRemoval = true 옵션이 각각 고아객체를 어떻게 처리하는지 알아보고자 한다. 🤔 고아객체 부모 엔티티와 연관관계가 끊어진 자식 엔티티 - 부모가 제거될 때, 부모와 연관되어 있는 모든 자식 엔티티들은 고아객체가 된다. - 부모 엔티티와 자식 엔티티 사이의 연관관계를 삭제할 때, 해당 자식 엔티티는 고아객체가 된다. 공통 예제 코드 CascadeType.REMOVE 와 orphanRemoval = true 옵션이 각각 고아객체를 어떻게 처리하는지 알아보기 위하여, Review 와 ReviewImage 엔티티를 바탕으로 예제 코드를 작성해 보았다. 먼저 두 옵션에 대한 차이점을 제외하고, 공통되는 사항은 아래와 같다. Revi..
·Back-end
🌱 Entity의 상태 (생명 주기) JPA에서 엔티티는 크게 4가지 상태를 가진다. 1. Transient (비영속) 엔티티 객체가 Java 메모리에서만 존재하고, 영속성 컨텍스트와 아무 관련 없는 상태 Person person = new Person(); 2. Persistent (영속) 엔티티 객체가 영속성 컨텍스트에 관리된 상태 영속 상태라고 바로 데이터베이스에 쿼리가 날라가는 것은 아니고 주로 트랜잭션이 commit 되거나 flush 메서드 실행 시 데이터베이스에 반영 된다. entityManger.persist(person); 3. Detached (준영속) 엔티티 객체가 영속성 컨텍스트에 저장되었다가 분리된 상태 더이상 영속성 컨텍스트에 의해 관리되지 않기 때문에 1차 캐시 등에서 모든 정보..
·Back-end
🌱 Entity의 상태 (생명 주기)JPA에서 엔티티는 크게 4가지 상태를 가지며, 상태를 전환시키는 기능을 EntityManager가 제공한다.1. Transient(비영속): 엔티티 객체가 Java 메모리에서만 존재하고, 영속성 컨텍스트와 아무 관련 없는 상태2. Persistent(영속): 엔티티 객체가 영속성 컨텍스트에 관리된 상태(영속 상태라고 바로 DB에 쿼리가 날라가는 것 X)3. Detached(준영속): 엔티티 객체가 영속성 컨텍스트에 저장되었다가 분리된 상태4. Removed(삭제): 실제 DB 삭제를 요청한 상태 🌱 Hibernate JPA EntityManager 핵심 기능1️⃣ Persistpersist는 엔티티의 새로운 인스턴스를 영속성 컨텍스트에 저장할 때 사용된다.Pers..
·Back-end
그냥 내가 기억해 두려고 간단하게 올리는 글.. + 혹시 나같은 사람 있을까 봐 @Configuration @RequiredArgsConstructor public class WebConfig implements WebMvcConfigurer { private final AuthInterceptor authInterceptor; @Override public void addInterceptors(InterceptorRegistry registry) { registry.addInterceptor(authInterceptor) .order(1) .addPathPatterns("/**") .excludePathPatterns("/", "/docs/**", "/*.ico"); } } @Component @Req..
·Back-end
🌏 의존성 주입 방법 생성자 주입(Constructor Injection) 필드 주입(Field Injection) 수정자 주입(Setter Injection) 1️⃣ 생성자 주입(Constructor Injection) 생성자 주입 방법은 생성자를 통해 의존 관계를 주입한다. 생성자 주입은 생성자의 호출 시점에 1회 호출 되는 것이 보장되기 때문에 주입받은 객체가 변하지 않거나, 반드시 객체의 주입이 필요한 경우에 강제하기 위해 사용할 수 있다. @Service public class ProductService { // final을 붙일 수 있음 private final ProductRepository productRepository; @Autowired// 생략 가능 public ProductRepo..
·Back-end
🤭 미리 읽고 오면 좋은 글 [JPA] JPA, Hibernate, Spring Data JPA에 대한 이런저런.. 정리☁️ JPA 인터페이스 🫧 EntityManagerFactory JPA 설정을 기반으로 EntityManager 인스턴스를 생성하는 팩토리 역할 (여러 EntityManager 생성 가능) 애플리케이션이 DB를 하나만 사용하는 경우 EntityManagerFactorychaewsscode.tistory.com [JPA] Hibernate JPA EntityManager 핵심 기능🌱 영속성 컨텍스트 내의 Entity 생명주기 엔티티는 크게 4가지 상태를 가지며, 상태를 전환시키는 기능을 EntityManager가 제공한다. 1. Transient(비영속): 엔티티 객체가 Java 메..
·Back-end
🤔 OSIV에 대해 알아보기 전.. Persistence Context 를 모른다면? [JPA] 영속성 컨텍스트의 동작원리와 이점 👍 영속성 컨텍스트의 동작원리 🌱 member 엔티티를 추가하는 과정 1. 엔티티가 영속화(persist)되어 1차 캐시에 저장된다. 2. 쓰기지연 SQL 저장소에 INSERT문이 생성되어 1차 캐시에 등록된 데이터를 chaewsscode.tistory.com 🤧 OSIV 요약 더보기 특징 OSIV는 클라이언트 요청이 들어올 때 영속성 컨텍스트를 생성해서 요청이 끝날 때까지 같은 영속성 컨텍스를 유지한다. 따라서 한 번 조회된 엔티티는 요청이 끝날 때까지 영속 상태를 유지한다. 엔티티 수정은 트랜잭션이 있는 계층(서비스, 레포지토리 계층)에서만 동작한다. 트랜잭션이 없는 프레..
·Back-end
☁️ Hibernate에서의 객체 캐싱 😶‍🌫️ 1차 캐시(First-Level Cache) JPA의 Persistence Context에서 사용되는 핵심 메커니즘 영속성 컨텍스트 내부에서 트랜잭션 단위로 엔티티 인스턴스를 저장하고 관리하는 저장소 1차 캐시는 기본적으로 활성화되어 있으며 영속성 컨텍스트가 곧 1차 캐시라고 할 수 있음 트랜잭션을 Commit 하거나 Flush 할 경우 1차 캐시에 있는 엔티티의 변경 사항들을 DB에 반영 ❄️ 1차 캐시의 조회 동작 1. 조회 시 식별자(ID)를 통해 1차 캐시에 데이터가 있는지 확인하고, 데이터가 있으면 가져옴 2. 1차 캐시에 데이터가 없으면 DB에 데이터 요청 3. DB에서 받아온 데이터를 재사용할 수 있도록 1차 캐시에 저장 😶‍🌫️ 공유 캐시(S..
서채리
'Back-end' 카테고리의 글 목록 (3 Page)