| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | 5 | 6 | |
| 7 | 8 | 9 | 10 | 11 | 12 | 13 |
| 14 | 15 | 16 | 17 | 18 | 19 | 20 |
| 21 | 22 | 23 | 24 | 25 | 26 | 27 |
| 28 | 29 | 30 |
- Spring Data JPA
- securitycontextholderfilter
- dockerhub
- 쿠버네티스
- @ComponentScan
- MSA
- 서블릿 컨테이너
- redis
- 스프링 부트
- Web
- mybatis
- kafka
- JPA
- Routing Key
- Spring
- docker
- JWT
- CORS
- JPQL
- 페이징
- AWS
- docker compose
- 컨테이너
- 지연 로딩
- JdbcTemplate
- DLQ
- DI
- @Transactional
- Spring Container
- Dead Letter Queue
- Today
- Total
목록JPA (16)
look-forest
스프링 데이터 JPA가 제공하는 공통 인터페이스의 구현체org.springframework.data.jpa.repository.support.SimpleJpaRepository @Repository 적용JPA 예외를 스프링이 추상화한 예외로 변환 (하부 기술이 바껴도 비즈니스 로직에 변경이 없도록 유연한 설계 지원)@Transactional(readOnly = true)데이터를 단순히 조회만 하고 변경하지 않는 트랜잭션에서 readOnly = true 옵션을 사용하면 flush를 생략해서 약간의 성능 향상을 얻을 수 있음@Transactional 트랜잭션 적용JPA의 모든 변경은 트랜잭션 안에서 동작스프링 데이터 JPA는 변경(등록, 수정, 삭제) 메서드를 트랜잭션 처리서비스 계층에서 트랜잭션을 시작하..
자동 생성되는 쿼리 대신, 쿼리를 직접 구현하고 싶은 경우엔 어떻게 할까?간단한 쿼리는 @Query와 JPQL로 정의.복잡한 SQL이 필요한 경우 네이티브 쿼리 사용.동적 쿼리에는 QueryDSL이 유용.고급 로직이나 복잡한 비즈니스 요구사항은 Custom Repository로 처리.사용자 정의 리포지토리 구현스프링 데이터 JPA 리포지토리는 인터페이스만 정의하고 구현체는 스프링이 자동 생성한다.그런데 스프링 데이터 JPA가 제공하는 인터페이스를 직접 구현하면 구현해야 할 기능이 너무 많다.실무에서는 주로 QueryDSL이나 SpringJdbcTemplate을 함께 사용할 때 사용자 정의 리포지토리 기능 자주 사용한다. Spring data JPA 인터페이스의 모든 메소드가 아니라 특정 메서드만 직접 구..
- 쿼리 메소드 기능메소드 이름으로 쿼리 생성메소드 이름으로 JPA NamedQuery 호출 - 실무에서 거의 사용 안함(도메인에 sql 작성해야해서)@Query 어노테이션을 사용해서 리파지토리 인터페이스에 쿼리 직접 정의- 벌크성 쿼리- 엔티티 그래프 기능메소드 이름으로 쿼리 생성스프링 데이터 JPA는 메소드 이름을 분석해서 JPQL을 생성하고 실행한다.//기본 생성된 메서드는 트랜잭션 처리가 되어있지만, 우리가 만든 메소드에도 트랜잭션 처리를 하려면 붙여야 한다.@Transactional(readOnly = true)public interface MemberRepository extends JpaRepository { List findByUsernameAndAgeGreaterThan(String us..
JpaRepository 인터페이스를 상속 받으면 구현체를 만들어주면서, 공통 CRUD 기능을 사용할 수 있다.(내부에서 entity manager를 사용한다)1. JavaConfig 설정- 스프링 부트 사용시 생략 가능2. 스프링 데이터 JPA가 구현 클래스를 대신 생성 - 실제 출력해보면 프록시. memberRepository.getClass() -> class com.sun.proxy.$ProxyXXX3. 공통 인터페이스 구성 4. 주요 메서드save(S) : 새로운 엔티티는 저장하고 이미 있는 엔티티는 병합한다.delete(T) : 엔티티 하나를 삭제한다. 내부에서 EntityManager.remove() 호출findById(ID) : 엔티티 하나를 조회한다. 내부에서 EntityManage..
1. 실무에서는 엔티티를 API 스펙에 노출하면 안된다!엔티티를 request, response 파라미터로 받으면, 엔티티가 변경되면 API 스펙이 변한다..!엔티티에 프레젠테이션 레이어의 검증을 위한 로직이 들어간다(@NotEmpty 등등). 실무에서는 회원 엔티티를 위한 API가 다양하게 만들어지는데, 한 엔티티에 각각의 API를 위한 모든 요청 요구사항을 담기는 어렵다.추가로 컬렉션을 직접 반환하면 항후 API 스펙을 변경하기 어렵다.(별도의 Result 클래스 생성으로 해결. Result 클래스로 컬렉션을 감싸면 향후 필요한 필드를 추가할 수 있다.)지연 로딩 설정으로 인해 프록시 빈이 주입되었기 때문에 json으로 처리도 불가하다. 특히 양방향 연관관계일 경우 json으로 바꾸면서 무한 루프에..
도메인 분석 설계외래 키가 있는 곳을 연관관계의 주인으로 정해라.연관관계의 주인은 단순히 외래 키를 누가 관리하냐의 문제이지 비즈니스 상 우위에 있다고 주인으로 정하면 안된다..예를 들어서 자동차와 바퀴가 있으면, 일대다 관계에서 항상 다쪽에 외래 키가 있으므로 외래 키가 있는 바퀴를 연관관계의 주인으로 정하면 된다. 물론 자동차를 연관관계의 주인으로 정하는 것이 불가능한 것은 아니지만, 자동차를 연관관계의 주인으로 정하면 자동차가 관리하지 않는 바퀴 테이블의 외래 키 값이 업데이트 되므로 관리와 유지보수가 어렵고, 추가적으로 별도의 업데이트 쿼리가 발생하는 성능 문제도 있다. ※ 마찬가지로 예측의 어려움 관점에서, 가급적 묵시적 조인 대신 명시적 조인을 사용하자.양방향 연관관계에서는 연관관계 편의 메서..
경로 표현식.(점)을 찍어 객체 그래프를 탐색하는 것경로 표현식 용어 정리상태 필드(state field): 단순히 값을 저장하기 위한 필드 (ex: m.username)연관 필드(association field): 연관관계를 위한 필드 -> 묵시적 내부 조인 발생단일 값 연관 필드: @ManyToOne, @OneToOne, 대상이 엔티티(ex: m.team)컬렉션 값 연관 필드: @OneToMany, @ManyToMany, 대상이 컬렉션(ex: m.orders)경로 표현식 특징상태 필드(state field): 경로 탐색의 끝, 탐색X단일 값 연관 경로: 묵시적 내부 조인(inner join) 발생, 탐색 가능컬렉션 값 연관 경로: 묵시적 내부 조인 발생, 탐색 불가(List로 받아서 인식x, 명시적 ..
JPA는 다양한 쿼리 방법을 지원한다. JPQL - em.createQuery()JPA Criteria - QueryDSL 같이 Java로 쿼리 짜는 JPA 표준 스펙. but 복잡함. 비추. QueryDSL 권장.QueryDSL - Java로 JPQL을 작성하는 JPQL 빌더네이티브 SQL - em.createNativeQuery(). JPQL로 해결할 수 없는 특정 데이터베이스에 의존적인 기능 사용 시JDBC API 직접 사용, MyBatis, SpringJdbcTemplate 함께 사용 - 영속성 컨텍스트를 적절한 시점에 강제 플러시 필요!JPQL(Java Persistence Query Language)JPA에서 원하는 쿼리를 만들 때 사용.JPA는 SQL..