JPA

1. 개요JPA 프로젝트를 진행하며 한가지 의문이 들었다. 'fetch = FetchType.EAGER' 와 'fetch-join (@Entity-graph)' 둘 다 진짜 객체를 한번에 조회할 수 있도록 하는 것인데.. 왜 'fetch-join (@Entity-graph)'의 성능이 더 좋은 것일까? 이 의문을 풀기 위해 공부한 내용을 포스팅 하려한다.   2. 공통점두 개념은 모두 가짜 객체를 사용하지 않고, 엔티티를 조회할때 모두 진짜 객체로 가져와 한꺼번에 조회할 수 있도록 하는 기능을 가진다.   3. 차이점 이 둘의 차이점이 이번 포스팅의 핵심 내용이 될 것이다. 차이점을 하나하나 살펴보자.  3-1. fetch = FetchType.EAGER이 코드는 엔티티 클래스 내부의 연관관계 어노테이션..

1. 개요게시판 조회 쿼리(네이티브 쿼리)를 작성하고 여러 ROW 건수를 DTO를 활용하여 리턴할 때 마주한 에러이다. 이 에러를 해결한 사례를 포스팅한다. 2. 원인쿼리 조회 결과와 DTO 간의 매핑이 제대로 되지 않아 생긴 오류이다. 3. 해결방법네이티브 쿼리를 사용하고, 다중 건수의 DTO로 리턴하기 위해선 DTO를 class로 만들지 않고, interface로 생성한다.// as-is@Data@NoArgsConstructorpublic class MyDto { private String A; private String B; // ... }// to-bepublic interface MyDto { String getA(); String getB(); ..

1. 지연로딩엔티티 조회 시 일반 멤버 변수만 먼저 조회되고, 객체(연관관계 엔티티)로 되어 있는 멤버 변수 조회 시, 가짜 객체로 먼저 조회되고, 실제 멤버 변수가 조회될 때, 실제 쿼리를 한번 더 실행시키는 기법이다. 말이 좀 어려운데, 간단한 코드로 보면@Entity@Getter@NoArgsConstructor(access = AccessLevel.PROTECTED)public class Member{ @Id @GeneratedValue @Column(name = "member_id") private Long id; private String name; private int age; // 연관관계 엔티티 @ManyToOne(fetch = FetchType..

JPA 초기 구현 시, API 요청 JSON 데이터를 바로 엔티티에 적용하여 개발했다. 하지만, 이렇게 코드를 구현하면서 문득 든 생각이 있었으니...  '만약 API 스펙이 변경되면 엔티티와 매핑이 되는건가...?'나의 의심은 역시나.. 실무에서 엔티티를 외부에 노출시키거나, 파라미터로 받으면 절대 절대!! 안된다!그 이유를 한번 살펴보겠다.1. 보안회사 및 서비스 데이터베이스 정보는 굉장히 민감한 정보이다. 엔티티를 직접 파라미터로 받거나 노출시킨다면, API를 호출하는 과정에서 엔티티에 대한 정보가 모두 노출될 수 있다. 이는 곧 서비스의 민감한 정보가 노출될 수 있음을 의미한다.  2. 유연성API 요청 스펙이 변경되면, 엔티티의 구조도 같이 변경해야할 수도 있다. 예를 들어, User라는 엔티티..