페치 조인은 중요하다고 소문이 자자하다. 대체 어떤 면이 좋길래 그렇게 중요하다고 하는지 알아보자. 페치 조인이란? JPQL에서 성능 최적화를 위해 따로 제공하는 기능이다. 연관된 엔티티나 컬렉션을 한번의 SQL로 조회하는 기능이다. SQL의 조인 종류 중 하나는 아니다. [JPQL] select m from Member m join fetch m.team [SQL] SELECT M.*, T.* FROM MEMBER M INNER JOIN TEAM T ON M.TEAM_ID=T.ID 엔티티 페치 조인 = 다대일 관계의 페치 조인 컬렉션 페치 조인 = 일대다 관계의 페치 조인 이 경우에는 위 사진처럼 하나의 팀에 여러 멤버 ROW가 들어가기 때문에 팀이 두번 조회되어 저장된다. 이는 쿼리 결과로 보면 같은..
경로 표현식은 정말 어려웠다. 단일 값이랑 컬렉션 값이 뭐가 다른지도 이해가 잘 안됐다. 이에 내가 이해한 내용을 바탕으로 나의 언어로 정리해 남기겠다. 경로 표현식이라고 말은 거창하지만 실상은 Java 개발자라면 당연히 써봤을 .(점)이다. 점 찍고 하위로 들어가는걸 그냥 어려운 말로 경로 표현식이라고 말한다. select m.username -> 상태 필드 from Member m join m.team t -> 단일 값 연관 필드 join m.orders o -> 컬렉션 값 연관 필드 where t.name = '팀A' 상태 필드 : 단순 값 저장하는 필드 (m.username) 경로 탐색의 끝, 더 이상 하위로 탐색하지 않음. 연관 필드 : 연관 관계를 위한 필드 단일 값: 다대일 관계의 엔티티 (..
JPQL이란? JPA가 제공하는 SQL을 추상화한 객체 지향 쿼리 언어 SQL을 추상화했기 때문에 특정 데이터베이스 SQL에 의존하지 않는다. JPQL은 결국 SQL로 변환된다. JPQL과 SQL의 차이점 JPQL은 엔티티 객체를 대상으로 쿼리문이 짜여진다. SQL은 데이터베이스 테이블을 대상으로 쿼리문이 짜여진다. JPA가 제공하는 다양한 쿼리 방법 JPQL JPA Criteria 자바코드로 JPQL 작성 가능 JPQL 빌더 역할 JPA의 공식 기능 복잡하고 실용성이 없음. -> 코드가 너무 길어짐 QueryDSL 사용 권장 QueryDSL 자바코드로 JPQL 작성 가능 JPQL 빌더 역할 컴파일 시점에 문법 오류를 찾을 수 있음 동적쿼리 작성이 편리함 단순하고 쉬움 실무 사용 권장 네이티브 SQL S..
(작성 중인 글입니다.) 먼저 refresh token을 왜 적용하게 됐는가? 나는 현재 프로젝트에 JWT를 사용하고 있다. JWT는 말 그대로 토큰을 사용한 로그인 방식이다. 로그인을 했을 때 먼저 access token을 발급해준다. 사용자는 요청 시 이 token과 함께 요청을 해야한다. 다만 여기서 위험한 점이 하나 있는데 중간에 이 token이 탈취되면 누구든 그 사용자인 척 할 수 있다는 것이다. 그러면 개인정보 도용 등 다양한 문제 상황이 발생할 수 있다. 토큰은 한번 부여하면 삭제가 안되기 때문이다. 그래서 이에 대한 보완점으로 refresh token이라는 것도 같이 부여해주게 되었다. access token은 짧은 유효기간을 가져 탈취당하더라도 오래 사용하지 못하게 안정성을 챙기면서, ..
JPA의 데이터 타입 분류 엔티티 타입 @Entity로 정의하는 객체 데이터가 변해도 식별자로 지속해서 추적 가능 member 엔티티의 키나 나이 등 값을 변경해도 pk값으로 인식 가능 생명 주기를 관리한다. 값 타입 int, Integer, String, LocalDateTime처럼 단순히 값으로 사용하는 자바의 기본 타입이나 객체 식별자(PK)가 없고 값만 있어서 값을 변경하면 추적이 불가능하다. lastModifiedDate를 now로 변경하면 완전히 다른 값으로 대체된다. 생명 주기를 엔티티에 의존한다. (엔티티의 생명주기를 따라간다) 공유하지 않는 것이 안전(객체면 불변객체로 해서 복사해 사용하자) 값 타입의 분류 기본값 타입 자바 기본 타입(int, double) 래퍼 클래스(Integer, ..
문제 상황 분명히 나는 아래와 같이 ExceptionHandler 작업을 해주었는데 이를 통과하지 않는 현상이 지속됐다. 다른 예외는 잘만 통과하는데 대체 왜 스프링 시큐리티 예외만 저 메소드를 거쳐가지 않을까? 이를 이해하려면 스프링 시큐리티의 작동 순서를 알아야 한다. 이 이유에 관한 작동 순서는 별도의 글로 간략히 작성해두었다. Spring Security 동작 원리 / 필터 순서 스프링 시큐리티에 대해 이해하기 위해서는 기본적으로 필터에 대한 이해가 필요하다. 스프링에서는 client로부터 HTTP 요청이 들어오면 Servlet에 도달하기 전 필터를 거친다. 이 필터는 하나일 수 layton0-0.tistory.com 해결 (구현) 과정 AuthenticationEntryPoint 구현 시큐리티의..
스프링 시큐리티에 대해 이해하기 위해서는 기본적으로 필터에 대한 이해가 필요하다. 스프링에서는 client로부터 HTTP 요청이 들어오면 Servlet에 도달하기 전 필터를 거친다. 이 필터는 하나일 수도 있고 여러개일 수도 있다. (원하는 만큼 필터 추가 가능하다.) 하나의 필터를 통과하면 다음 필터로, 그 다음 필터를 통과하면 또 다음 필터로 넘어가는 형태이다. 이를 필터 체인이라고 한다. HTTP 요청 -> WAS -> 필터 1 -> 필터 2 -> ... -> 서블릿 -> 컨트롤러 HTTP 요청 -> WAS -> 필터 1 -> 필터 2(적절하지 않은 요청, 서블릿 호출 X) 스프링 시큐리티는 여기서 DelegatingFilterProxy라는 서블릿 필터를 만들어서 메인 필터체인에 끼워 넣는다. 그리..
영속성 전이는 코드로 이해하는 것이 가장 빠른 듯 하다. Before: em.persist()를 3번 해줘야 한다. Child child1 = new Child(); Child child2 = new Child(); // 위의 두 Child객체를 가지는 Parent객체 Parent parent = new Parent(); parent.addChild(child1); parent.addChild(child2); em.persist(parent); em.persist(child1); em.persist(child2); After: em.persist()를 한번만 해도 된다. Child child1 = new Child(); Child child2 = new Child(); // 위의 두 Child객체를 가지..
