JpaRepository를 사용하면 안의 실제 구현물은 어떤지 보는 시간 이런 findById니 findOne... 인 어쩌구 하는것들도 직접 EntityManager를 가져와 구현했듯이 다 똑같은 것들이다. 재밌는건 jpa에서 카운트 같은걸 자체 지원하지 않기 때문에 나름내로 알아서 sql문으로 구현한 모습 어노테이션이 @Repository와 @Transactional 두가지가 있는데 각각의 의미는 다음과 같다. @Repository는 안에 @Component가 있기 때문에 스프링한테 이걸 bean에다가 넣으라는 의미도 있지만, repository는 각각의 db들이 서로 실제 명령어들도 다르고 에러도 다르게 뜰 텐데 @Repository가 이걸 받아 일정한 에러로 변환시켜준다. @Transactiona..

자기가 원하는 기능을 data jpa repository interface에서 더 추가해서 사용할 수 있다. 자기만의 인터페이스를 만들고, 이 인터페이스의 구체적 클래스 + Impl를 작성하고(관례 규칙. 이게 있어야 스프링에서 가져감) jpa repository에서 이 인터페이스를 확장하는 것이다. 이렇게 뺄 정도의 복잡한 쿼리인데 핵심 비즈니스와 그다지 관련없는 쿼리라면 따로 레포지토리를 만들어 구조적으로 해결하는 방법도 있다. 어느게 더 좋을지는 본인 선택임. db에서 해당 row가 언제 생성되었고 수정되었는지를 표시하는 만들어진 시간, 업데이트된 시간을 표시하는걸 audit이라고 함. 당연히 다른 곳들에서도 많이 쓰이므로 @Audit도 지원한다. 원래 db로만 있을 땐 상속 개념이 없어 각 테이블..

공통으로 있는게 들어있는건 알겠는데 내 앱이여서 내 도메인에 특화된 건 어떻게 하느냐. 즉, data jpa를 그대로 쓰고 여기에 나만의 커스텀 함수는 어떻게 만드느냐. 이게 쿼리 메소드 기능임. 이름만으로 된다. 이름이 같고 나이는 어느 이상인 조건을 찾는 함수를 만든다고 하자. 정석은 EntityManager로 불러오는 것. 하지만 data jpa는 이름만으로도 가능하다는 것. 자동완성이 되어서 참고하면서 하면 된다. 함수 이름은 규칙이 있기 때문에 자세히 알고싶으면 공식 문서를 보면 된다. https://docs.spring.io/spring-data/jpa/docs/current/reference/html/#jpa.query-methods.query-creation Spring Data JPA -..

CRUD를 원래 적성대로 직접 만들어보자. update는 변경 감지 기능을 사용할거기 때문에 굳이 필요 없다. 보면 알겠지만 대체로 다 비슷하다. 그래서 이 중복을 줄이기 위해 많은 사람들이 시도해보고, 한 천재가 인터페이스로 만들어서 data jpa에서 같이 해보자고 해서 만든거다. 위가 직접 만든 클래스고 밑이 data jpa로 인터페이스로만 한건데 둘 다 잘 된다. 즉, 내가 직접 만든 기본적인 CRUD는 정의하지 않아도 이미 있다. 구현체는 만든 적 없고 인터페이스만 있는데도 되는 이유는 스프링이 인터페이스를 보고 자기가 프록시 클래스 구현체로 만들어 사용하기 때문. 그래서 주입해야 하는 거고. 실제 인터페이스 내용을 보면 함수들이 미리 정의되어 있다. 상속하는 JpaRepository는 특화 기..

위 두 클래스는 같은 역할을 한다. data jpa가 많이 생략되어 있어서 한번 상기해 봤음. 기초 세팅

OSIV는 open session in view의 줄임말인데, 영속성 컨텍스트 즉, db 커넥션이 언제까지 살아있게 할거냐를 결정한다. 기본값은 true이므로, 지금 이게 되어있다고 warn 창이 계속 뜨는것이다. OSIV가 켜저있으면 @Transactional를 벗어나서도 해당 객체가 컨트롤러 등 밖에서도 달라지거나 지연로딩으로 그때 새로 db에서 불러올 수 있기 때문에 계속 추적하는 것이다. 커넥션을 반환할 때는 글자 그대로 진짜 사용자에게 view까지 전부 다 보여지고 모든것이 끝난 다음에 커넥션을 반환하는 것. 문제는 추적하다가 바뀌거나 db에서 로딩을 하게되면 db 커넥션을 들고 있어야 바꾸거나 조회하거나 할 수 있기 때문에 @Transactional를 벗어나서도 db 커넥션을 계속 들고 있다...

이제 일대다 조회(컬렉션 조회)해서 데이터 막 복제되고 하는곳에 성능 최적화를 해보자. OneToMany를 반환할거다 이렇게 엔티티를 직접 반환했지만 이것도 dto로 바꿀꺼다. 근데 안의 내용들까지 dto로 바꾸는게 쉽게 안된다. 그래서 따로 섹션 뺀거다. 일단 겉을 dto로 했을 때 orderItems가 null이 나왔는데 지연 로딩이라 안불러와서 그렇다. 하나하나 불러와주는것도 넣어주고 다시 해보면 잘 나온다. 근데 문제는 사실 저것도 엔티티 그대로인 것이다. 즉, 겉은 dto로 바꿨는데 안은 엔티티를 반환하고 있는것. 안에도 dto로 변환해보자. 이제 아까 했던 것처럼 fetch join을 사용해서 쿼리 최적화를 해보자. 근데 이렇게만 했을 때 일대다일때 여러 번 언급했던 데이터 증식 문제가 나온다..

주문 + 배송정보 + 회원을 조회하는 API를 만들자 지연 로딩 때문에 발생하는 성능 문제를 단계적으로 해결해보자. > 참고: 지금부터 설명하는 내용은 정말 중요합니다. 실무에서 JPA를 사용하려면 100% 이해해야 합니다. > 안그러면 엄청난 시간을 날리고 강사를 원망하면서 인생을 허비하게 됩니다. 일단 dto를 사용하지 않고 엔티티 자체를 반환하는 방식으로 할 때 이런 문제들이 생기므로 이렇게 쓰지 말라고 하는거다. 그래서 편하게 보면 됨. public List findAllByString(OrderSearch orderSearch) { String jpql = "select o from Order o join o.member m"; boolean isFirstCondition = true; //주문..

준비 섹션을 따로 만들어놨는데 앞으로 진행할 섹션들에 대해 설명한다. 거의 대부분의 문제는 여기 안에서 해결된다. API 개발 고급 - 조회용 샘플 데이터 입력 API 개발 고급 - 지연 로딩과 조회 성능 최적화 API 개발 고급 - 컬렉션 조회 최적화 API 개발 고급 - 페이징과 한계 돌파 API 개발 고급 - OSIV와 성능 최적화 조회용 샘플 데이터 입력은 보통 수정, 삭제 같은 경우는 잘 안하고 한 줄만 하는거라 에러가 거의 안나고 대부분 조회를 하니 조회 쪽에서 문제가 알이남. 그래서 어떻게 할건지 지연 로딩과 조회 성능 최적화는 lazy 사용하고 뭐 하는듯 컬렉션 조회 최적화는 이제 일대다 컬렉션을 불러올 때 복사되서 뻥튀기 되는 문제들 어떻게 대처할지 페이징과 한계 돌파도 위와 비슷하다. ..

섹션 0 강의 소개 내용 할거다. 섹션1 절대로 엔티티를 입력으로 받거나 출력으로 반환하면 안된다. 무조건 dto를 따로 만들어서 사용하기. 이유는 각 요청에 따라 요청 안의 body json 내용도 달라질텐데 이것 때문에 엔티티 자체를 계속 수정할 수도 없고 애초에 엔티티가 이런 곳에 의존성을 가지고 있으면 안된다. 또 엔티티의 내용 그대로를 반환하기 대문에 보안 문제도 있다. 이건 나중에 볼거임. 주어지지 않은 정보는 null로써 채워진다. 수정도 비슷하게 하는데 이 수정 기능에도 일일이 dto를 만들어 사용한다. 기억해야 할건 이 엔티티의 변화를 엔티티 메니저한테 맡기면 쉬워진다. 즉, 영속성 컨텍스트 이용하라고. 영속성 컨텍스트로 ujpdate가 알아서 나간다. response로 응답해주는 부분인..