JPA와 DB 동작 확인

Member 객체 생성

@Id 로 식별,

@GeneratedValue 로 자동으로 값 입력할 수 있는 에노테이션을 붙혔다

 

리포지토리 생성

 

이전 강의들처럼 간단히 저장, 조회만 구현했다

하지만 @PersistenceContext 라는 엔티티 매니저를 사용한다

나는 스프링 핵심 원리 이후에 바로 JPA 활용을 듣고있기 때문에 JPA 에 대한 사전지식이 없는 상태라

엔티티 매니저는 들어만 봤을 뿐, 어떤 기능을 하는지 모르고있다

그것을 감안하더라도 한번 쭉 따라하면서 코딩을 하는것이 중요하다고 들었기에,

앞으로도 모르는 것들은 눈으로만 담아두며 라이브 코딩을 따라하는 것에 집중하고자 한다

 

 

실패한다

엔티티 객체는 항상 트랜잭션 안에서 수정이 일어나야 한다

 

 

이제야 성공을 하는 모습

 

이제 데이터베이스를 확인해보자

 

MEMBER 테이블이 생성되어 있는 모습이다

 

 

이것은 방금 테스트 실행의 로그 중 일부이다

 

이 설정에 의해서 먼저 drop 으로 데이터를 날리고,

create를 한 것이라 보면 된다

자세한 내용은 아직 이해하지 못했다

 

그런데 테이블 안에 왜 데이터가 없을까?
테스트 안에 트랜잭셔널을 사용하면, 테스트가 끝난 이후에 롤백을 한다

그것또한 옳게 된 사용법이지만, 가끔은 내 코드가 의심스러워 DB안에 제대로 저장되었는지 까지

확인하고 싶은 경우가 있다

그럴땐 이와 같은 방법을 사용하면 된다

 

아까와 다르게 insert문이 로그에 나오는 모습

DB에도 데이터가 저장되었다

 

다른 테스트도 진행해보자

findMemer 를 한 결과와 member 는 같은 엔티티일까?

 

같은 엔티티이다

영속성 context에서 같은 식별자를 가지면 같은 엔티티로 인식한다

1차 캐시라는 곳에서 같은 식별자를 가진 엔티티가 있으면, 그것을 꺼내 오는 것이다

JPA 지식이 없기 때문에 이 문장에 대해 나름대로 고민을 해봤다

아마 HTTP 에서 학습했던 캐시의 동작 원리와 같은 내용이지 않을까 싶다

이전에 캐시를 내려받은 클라이언트가, 같은 요청을 했을 때 헤더부분만 보내고 body 부분은

클라이언트가 가지고 있는 캐시를 재사용하는 것으로 해결한다는 내용이 떠올랐다

오해일 수도 있지만, 일단은 그 정도로 생각하고 넘어간다

 

참고: 스프링 부트를 통해 복잡한 설정이 다 자동화 되었다
persistence.xml 도 없고, LocalContainerEntityManagerFactoryBean 도 없다
스프링 부트를 통한 추가 설정은 스프링 부트 메뉴얼을 참고하고, 스프링 부트를 사용하지 않고
순수 스프링과 JPA 설정 방법은 자바 ORM 표준 JPA 프로그래밍 책을 참고하자

 

 

쿼리 파라미터 로그 남기기
- 로그에 다음을 추가하기 : SQL 실행 파라미터를 로그로 남긴다
 - 스프링 부트 3.x, hibernate6
  - org.hibernate.orhttp://m.jdbc.bind: trace

 

로그 오른쪽에 쿼리 파라미터가 표시된다

그런데 직관적으로 ?, ? 의 자리를 바로 해석할 순 없을까?

 

- 외부 라이브러리 사용
 - https://github.com/gavlyukovskiy/spring-boot-data-source-decorator

스프링 부트를 사용하면 이 라이브러리만 추가하면 된다 (스프링 3.0 이상은 1.9.0 이상을 사용, 다른 버전 주의)
implementation 'com.github.gavlyukovskiy:p6spy-spring-boot-starter:1.9.0'

 

훨신더 직관적으로 쿼리 파라미터를 해석하는 로그가 출력된다

 

참고: 쿼리 파라미터를 로그로 남기는 외부 라이브러리는 시스템 자원을 사용하므로,
개발 단계에서는 편하게 사용해도 된다
하지만 운영시스템에 적용하려면 꼭 성능테스트를 하고 사용하는 것이 좋다