save의 기본동작은 식별자가 없으면 persist 식별자가 있으면 merge 이다. merge는 데이터베이스에서 식별자로 조회를 해본 후, 없으면 insert, 있으면 update이다.(비효율적이다) 그런데 식별자를 @GenerateValue로 자동 할당하지 않고 직접 할당하게되면 엔티티 save시, 무조건 식별자가 세팅되어 있음으로 merge를 하게된다. 이 문제를 엔티티에 Persistable 인터페이스를 구현함으로서 자동할당시 save와 동일한 성능을 유지할 수 있다. @Override public String getId() { return id; } @Override public boolean isNew() { return createdDate == null; } Persistable을 impl..

컨트롤러에서 Pageable을 파라미터로 받을 수 있다. 예) 1 2 3 4 5 @GetMapping("/members") public Page list(Pageable pageable) { Page page = memberRepository.findAll(pageable); return page; } Colored by Color Scripter cs 스프링 데이터는 pageable에 PageRequest 객체를 주입해준다. 요청 파라미터 예) /members?page=0&size=3&sort=id,desc&sort=username,desc page: 현재 페이지, 0부터 시작한다. size: 한 페이지에 노출할 데이터 건수 sort: 정렬 조건을 정의한다. 예) 정렬 속성,정렬 속성...(ASC | ..

도메인 클래스 컨버터 컨트롤러에서 파라미터로 엔티티의 ID를 받는 것 대신, 엔티티로 받아 객체를 바인딩 해주는 기능. 트랜잭션이 없는 범위에서 엔티티를 조회했음으로 엔티티를 변경하지 않고 조회용으로만 사용해야한다(변경해도 DB 반영 안됨) 도메인 클래스 컨버터도 레퍼지토리를 통해 엔티티 조회. //도메인 클래스 컨버터 적용 전 @RestController @RequiredArgsConstructor public class MemberController { private final MemberRepository memberRepository; @GetMapping("/members/{id}") public String findMember(@PathVariable("id") Long id) { Member..

데이터베이스의 테이블에 등록일, 수정일과 같은 정보는 시스템을 운영하는데 있어서 거의 모든 테이블에 필수적으로 들어가야하는 정보들이다. JPA에서는 @MappedSuperclass 어노테이션으로 베이스 엔티티를 설정 할 수 있고 베이스 엔티티를 상속받아 등록일, 수정일을 적용할 수 있다. 하지만 상속을 해야한다는 것이 꺼림직하다...하지만 스프링 데이터 JPA에서는 이와 같은 정보를 엔티티가 저장될때, 혹은 수정될때 상속없이 어노테이션으로 자동으로 처리할 수 있게 지원하고 있다. 그 방법을 알아보자! 1. @EnableJpaAuditing -> 스프링 부트 설정 클래스에 적용 2. @EntityListeners(AuditingEntityListener.class) -> Auditing을 적용할 엔티티에 ..

사용자 정의 레퍼지토리 스프링데이터 JPA는 레퍼지토리만 인터페이스로 정의해두면 스프링데이터 JPA 규칙에 따라 해당 레퍼지토리 인터페이스를 구현하지 않아도 스프링이 내부적으로 구현클래스를 생성하여 제공해준다. 하지만 다양한 이유로 인해서 레퍼지토리의 구현을 직접 해야할 필요가 있을 수 있다. JPA 직접 사용(EntityManager) 스프링 JDBC Template 사용 MyBatis 사용 데이터베이스 커넥션 직접 사용 Querydsl 사용 그래서 스프링데이터 JPA에서는 사용자 정의 레퍼지토리를 구현할 수 있는 방법을 제공한다. 먼저 메인 레퍼지토리와는 별개로 사용자 정의 레퍼지토리를 따로 인터페이스로 정의 한다. 해당 레퍼지토리를 구현하는 클래스를 만든다 이때 구현 클래스명에 명명 규칙이 있다. ..

벌크 연산이란? insert, update, delete 할때 단건이 아닌 다건으로 한번에 처리하는 쿼리 JPA에서 벌크 연산시 주의점! 벌크 연산 쿼리는 엔티티 매니저가 영속성 컨텍스트에 변경된 내용을 업데이트 하지 않고 바로 데이터베이스로 보내진다. 따라서 벌크 연산 후에 실제 데이터베이스와 영속성 컨텍스트의 엔티티 정보가 다를 수 있다! 그래서 벌크 연산 후에는 flush()와 clear()를 꼭 해줘서 이후의 로직에 대해 다시 영속 상태가 되도록 유도 해야한다! flushAutomatically, clearAutomatically 스프링 데이터 JPA에서는 해당 속성으로 flush()와 clear()를 자동으로 수행되게 할 수 있다. 여기서 flush는 clear하기 전에 혹시 모를 기존에 영속성..