전체 글
실전! Querydsl - 섹션3. 기본 문법
기본 @SpringBootTest @Transactional public class QuerydslBasicTest { @Autowired EntityManager em; JPAQueryFactory queryFactory; @BeforeEach public void before() { queryFactory = new JPAQueryFactory(em); Team teamA = new Team("teamA"); Team teamB = new Team("teamB"); em.persist(teamA); em.persist(teamB); Member member1 = new Member("member1", 10, teamA); Member member2 = new Member("member2", 20, t..
실전! Querydsl - 섹션2. 예제 도메인 모델
예제 도메인 전에 querydsl 설치는 현재 사용하는 spring boot 버전 검색해서 하면 그나마 잘 나온다.. 종속성 보면 qclass 만들어주는 apt 라이브러리와 실제 select등 함수 도와주는 jpa 라이브러리가 있다. 설정 파일에 querydsl 관련 설정 해준건 플러그인 때문에 그렇다. sql문도 추적하기 위헤 p6spy를 깐다.. 이제 섹션2 예제 도메인 모델
실전! 스프링 데이터 JPA - 섹션7. 나머지 기능들
나머지 기능들인 이유는 잘 안써서. 가끔 유용하게 쓰는 정도 - Specifications (명세) - Query By Example - Projections - 네이티브 쿼리 Specifications은 JPA Creteria인데 사용 금지. QueryDSL을 써라. query by example은 새로 생긴 data-jpa의 기능임. 객체를 넘겨줘서 찾는다. join을 하고싶으면 join을 하는 걸 같이 넣어줘야 한다. 또 null이 될 수 없는 기본 타입은 0이 되기 때문에 이건 무시하라고 조건을 내보내야 함. Projections 프로젝션 엔티티의 특정 속성만 불러오고 싶다면? 원래는 일단 객체 전체를 sql문으로 가져와서 그것을 가져오는 형식으로 했지만 원하는 속성 부분만 sql문 써서 가져오게..
실전! 스프링 데이터 JPA - 섹션6. 스프링 데이터 JPA 분석
JpaRepository를 사용하면 안의 실제 구현물은 어떤지 보는 시간 이런 findById니 findOne... 인 어쩌구 하는것들도 직접 EntityManager를 가져와 구현했듯이 다 똑같은 것들이다. 재밌는건 jpa에서 카운트 같은걸 자체 지원하지 않기 때문에 나름내로 알아서 sql문으로 구현한 모습 어노테이션이 @Repository와 @Transactional 두가지가 있는데 각각의 의미는 다음과 같다. @Repository는 안에 @Component가 있기 때문에 스프링한테 이걸 bean에다가 넣으라는 의미도 있지만, repository는 각각의 db들이 서로 실제 명령어들도 다르고 에러도 다르게 뜰 텐데 @Repository가 이걸 받아 일정한 에러로 변환시켜준다. @Transactiona..
실전! 스프링 데이터 JPA - 섹션5. 확장 기능
자기가 원하는 기능을 data jpa repository interface에서 더 추가해서 사용할 수 있다. 자기만의 인터페이스를 만들고, 이 인터페이스의 구체적 클래스 + Impl를 작성하고(관례 규칙. 이게 있어야 스프링에서 가져감) jpa repository에서 이 인터페이스를 확장하는 것이다. 이렇게 뺄 정도의 복잡한 쿼리인데 핵심 비즈니스와 그다지 관련없는 쿼리라면 따로 레포지토리를 만들어 구조적으로 해결하는 방법도 있다. 어느게 더 좋을지는 본인 선택임. db에서 해당 row가 언제 생성되었고 수정되었는지를 표시하는 만들어진 시간, 업데이트된 시간을 표시하는걸 audit이라고 함. 당연히 다른 곳들에서도 많이 쓰이므로 @Audit도 지원한다. 원래 db로만 있을 땐 상속 개념이 없어 각 테이블..
실전! 스프링 데이터 JPA - 섹션4. 쿼리 메소드 기능
공통으로 있는게 들어있는건 알겠는데 내 앱이여서 내 도메인에 특화된 건 어떻게 하느냐. 즉, data jpa를 그대로 쓰고 여기에 나만의 커스텀 함수는 어떻게 만드느냐. 이게 쿼리 메소드 기능임. 이름만으로 된다. 이름이 같고 나이는 어느 이상인 조건을 찾는 함수를 만든다고 하자. 정석은 EntityManager로 불러오는 것. 하지만 data jpa는 이름만으로도 가능하다는 것. 자동완성이 되어서 참고하면서 하면 된다. 함수 이름은 규칙이 있기 때문에 자세히 알고싶으면 공식 문서를 보면 된다. https://docs.spring.io/spring-data/jpa/docs/current/reference/html/#jpa.query-methods.query-creation Spring Data JPA -..
실전! 스프링 데이터 JPA - 섹션3. 공통 인터페이스 기능
CRUD를 원래 적성대로 직접 만들어보자. update는 변경 감지 기능을 사용할거기 때문에 굳이 필요 없다. 보면 알겠지만 대체로 다 비슷하다. 그래서 이 중복을 줄이기 위해 많은 사람들이 시도해보고, 한 천재가 인터페이스로 만들어서 data jpa에서 같이 해보자고 해서 만든거다. 위가 직접 만든 클래스고 밑이 data jpa로 인터페이스로만 한건데 둘 다 잘 된다. 즉, 내가 직접 만든 기본적인 CRUD는 정의하지 않아도 이미 있다. 구현체는 만든 적 없고 인터페이스만 있는데도 되는 이유는 스프링이 인터페이스를 보고 자기가 프록시 클래스 구현체로 만들어 사용하기 때문. 그래서 주입해야 하는 거고. 실제 인터페이스 내용을 보면 함수들이 미리 정의되어 있다. 상속하는 JpaRepository는 특화 기..
실전! 스프링 데이터 JPA - 섹션1. 프로젝트 환경설정
위 두 클래스는 같은 역할을 한다. data jpa가 많이 생략되어 있어서 한번 상기해 봤음. 기초 세팅
실전! 스프링 부트와 JPA 활용2 - API 개발과 성능 최적화 - 섹션5. API 개발 고급 - 실무 필수 최적화 (OSIV와 성능 최적화)
OSIV는 open session in view의 줄임말인데, 영속성 컨텍스트 즉, db 커넥션이 언제까지 살아있게 할거냐를 결정한다. 기본값은 true이므로, 지금 이게 되어있다고 warn 창이 계속 뜨는것이다. OSIV가 켜저있으면 @Transactional를 벗어나서도 해당 객체가 컨트롤러 등 밖에서도 달라지거나 지연로딩으로 그때 새로 db에서 불러올 수 있기 때문에 계속 추적하는 것이다. 커넥션을 반환할 때는 글자 그대로 진짜 사용자에게 view까지 전부 다 보여지고 모든것이 끝난 다음에 커넥션을 반환하는 것. 문제는 추적하다가 바뀌거나 db에서 로딩을 하게되면 db 커넥션을 들고 있어야 바꾸거나 조회하거나 할 수 있기 때문에 @Transactional를 벗어나서도 db 커넥션을 계속 들고 있다...
실전! 스프링 부트와 JPA 활용2 - API 개발과 성능 최적화 - 섹션4. API 개발 고급 - 컬렉션 조회 최적화
이제 일대다 조회(컬렉션 조회)해서 데이터 막 복제되고 하는곳에 성능 최적화를 해보자. OneToMany를 반환할거다 이렇게 엔티티를 직접 반환했지만 이것도 dto로 바꿀꺼다. 근데 안의 내용들까지 dto로 바꾸는게 쉽게 안된다. 그래서 따로 섹션 뺀거다. 일단 겉을 dto로 했을 때 orderItems가 null이 나왔는데 지연 로딩이라 안불러와서 그렇다. 하나하나 불러와주는것도 넣어주고 다시 해보면 잘 나온다. 근데 문제는 사실 저것도 엔티티 그대로인 것이다. 즉, 겉은 dto로 바꿨는데 안은 엔티티를 반환하고 있는것. 안에도 dto로 변환해보자. 이제 아까 했던 것처럼 fetch join을 사용해서 쿼리 최적화를 해보자. 근데 이렇게만 했을 때 일대다일때 여러 번 언급했던 데이터 증식 문제가 나온다..