CS/김영한 스프링 강의
실전! 스프링 데이터 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을 사용해서 쿼리 최적화를 해보자. 근데 이렇게만 했을 때 일대다일때 여러 번 언급했던 데이터 증식 문제가 나온다..
실전! 스프링 부트와 JPA 활용2 - API 개발과 성능 최적화 - 섹션3. API 개발 고급 - 지연 로딩과 조회 성능 최적화
주문 + 배송정보 + 회원을 조회하는 API를 만들자 지연 로딩 때문에 발생하는 성능 문제를 단계적으로 해결해보자. > 참고: 지금부터 설명하는 내용은 정말 중요합니다. 실무에서 JPA를 사용하려면 100% 이해해야 합니다. > 안그러면 엄청난 시간을 날리고 강사를 원망하면서 인생을 허비하게 됩니다. 일단 dto를 사용하지 않고 엔티티 자체를 반환하는 방식으로 할 때 이런 문제들이 생기므로 이렇게 쓰지 말라고 하는거다. 그래서 편하게 보면 됨. public List findAllByString(OrderSearch orderSearch) { String jpql = "select o from Order o join o.member m"; boolean isFirstCondition = true; //주문..
실전! 스프링 부트와 JPA 활용2 - API 개발과 성능 최적화 - 섹션2. API 개발 고급 - 준비
준비 섹션을 따로 만들어놨는데 앞으로 진행할 섹션들에 대해 설명한다. 거의 대부분의 문제는 여기 안에서 해결된다. API 개발 고급 - 조회용 샘플 데이터 입력 API 개발 고급 - 지연 로딩과 조회 성능 최적화 API 개발 고급 - 컬렉션 조회 최적화 API 개발 고급 - 페이징과 한계 돌파 API 개발 고급 - OSIV와 성능 최적화 조회용 샘플 데이터 입력은 보통 수정, 삭제 같은 경우는 잘 안하고 한 줄만 하는거라 에러가 거의 안나고 대부분 조회를 하니 조회 쪽에서 문제가 알이남. 그래서 어떻게 할건지 지연 로딩과 조회 성능 최적화는 lazy 사용하고 뭐 하는듯 컬렉션 조회 최적화는 이제 일대다 컬렉션을 불러올 때 복사되서 뻥튀기 되는 문제들 어떻게 대처할지 페이징과 한계 돌파도 위와 비슷하다. ..
실전! 스프링 부트와 JPA 활용2 - API 개발과 성능 최적화 - 섹션1. API 개발 기본
섹션 0 강의 소개 내용 할거다. 섹션1 절대로 엔티티를 입력으로 받거나 출력으로 반환하면 안된다. 무조건 dto를 따로 만들어서 사용하기. 이유는 각 요청에 따라 요청 안의 body json 내용도 달라질텐데 이것 때문에 엔티티 자체를 계속 수정할 수도 없고 애초에 엔티티가 이런 곳에 의존성을 가지고 있으면 안된다. 또 엔티티의 내용 그대로를 반환하기 대문에 보안 문제도 있다. 이건 나중에 볼거임. 주어지지 않은 정보는 null로써 채워진다. 수정도 비슷하게 하는데 이 수정 기능에도 일일이 dto를 만들어 사용한다. 기억해야 할건 이 엔티티의 변화를 엔티티 메니저한테 맡기면 쉬워진다. 즉, 영속성 컨텍스트 이용하라고. 영속성 컨텍스트로 ujpdate가 알아서 나간다. response로 응답해주는 부분인..
자바 ORM 표준 JPA 프로그래밍 - 기본편 - 섹션 11. 객객체지향 쿼리 언어2 - 중급 문법 (JPQL)
말이 경로표현식이지 어렵게 용어를 정의해서 설명하는데 그냥 점(.) 찍고 원하는거 불러오는거다. 근데 그 불러오는게 단순 필드값인지, 엔티티인지, 컬렉션인지에 따라 내부 동작 방식이 다르기 때문에 각각 구분해서 알아야 해서 이름 붙이고 구분 하는 거다. 여기서 경로라고 표현한 이유가 나오는데 자바 객체이기 때문에 불러오는 걸 타고타고 쭉 갈수 있다는 것. db는 이걸 구현하기 위해 join을 하고 안에서 난리가 난다. 그래서 최적화 할 때 알아두어야된다. 난 단순히 자바 객체 안에 있는걸 불러오려고 했을 뿐인데 안에선 나도 모르게 join이 실행된다. 그래서 묵시적 join인거고.. 그래서 잘 알고 써야 한다. 사실 묵시적 join이 나오도록 코드 짜지 말자. 진짜 나중에 sql문 튜닝할 때 힘들어진다...
자바 ORM 표준 JPA 프로그래밍 - 기본편 - 섹션 10. 객체지향 쿼리 언어1 - 기본 문법 (JPQL)
다양하게 있는데 진짜 왠만하면 JPQL, QueryDSL로 대부분 해결되고 진짜 안되는게 있을 땐 SpringJdbcTemplate로 해결한다. 거의 무조건 QueryDSL 사용을 추천. jpql은 쌩 sql과 매우 유사하며 대상이 테이블 객체가 아니라 jpa 객체라는데에 있다. 위 jpql의 경우 쌩 string을 넣기 때문에 동적 쿼리가 힘듬. 그래서 criteria라고 공식으로 지원하는 스펙이 있고, 자바 코드로 짜기 때문에 문법 오류 잡아주고 동적쿼리 하기 쉽고 하다는 장점이 있지만 진짜 뒤지도록 복잡하다.. 걍 안쓴다. querydsl은 진짜 직관적이고 정말 좋다. 자바코드라 문법도 잡아주고 동적도 정말 쉽고 왠만한건 다 이걸로 해결된다. 그냥 이거 써라. jpal말고 진짜 쌩 sql도 날릴 수..