기록하는 개발자

스프링 부트 2.7 버전 이상과 Querydsl 5.0 버전 이상을 설정할 때 발생하는 에러입니다. Q타입 클래스를 만들기 위해 Gradle -> Tasks -> Other -> compileQuerydsl을 실행할 때 발생합니다. Querydsl과 gradle 설정 정보가 일치하지 않기 때문입니다. 1. 그러므로 build.gradle에 querydsl 버전 설정을 추가한 후 buildscript { ext { queryDslVersion = "5.0.0" } } 2. dependencies에 아래 2줄을 추가하면 됩니다. implementation "com.querydsl:querydsl-jpa:${queryDslVersion}" annotationProcessor "com.querydsl:query..

회원가입을 하는 경우, 아이디에 대한 중복검사를 하는 기준을 이메일로 선정하였습니다. Postman으로 테스트하던 중 No entity found for query 라는 에러를 발견하였습니다. javax.persistence.NoResultException가 발생하였고, 말 그대로 해석하면 쿼리를 날렸는데 결과를 찾지 못했다는 뜻입니다. 여기서 떠올랐던 생각은 쿼리를 잘못 날렸거나, 쿼리는 정상인데 엔티티를 찾지 못했다는 것입니다. 생각해보면, 이메일 중복검사를 하기위해 쿼리를 날렸는데 신규 가입을 하는 경우에는 당연히 엔티티를 찾지 못합니다. 그러면 쿼리의 결과를 반환하는 과정에서 문제가 있다고 판단하였습니다. 현재 작성된 findByEmail 반환타팁을 보면 User 객체이고 쿼리의 결과를 getSi..

현재 Order 엔티티와 Member 엔티티는 ManyToOne 관계이고, Order 엔티티와 Delivery 엔티티의 관계는 OneToOne 관계입니다. Order 엔티티를 조회하는 경우에, API 스펙에서 Member의 이름과 Delivery 주소를 요구한다면 OrderDto에서 해당 정보를 함께 반환해야합니다. @Entity @Table(name = "orders") @Getter @Setter @NoArgsConstructor(access = AccessLevel.PROTECTED) public class Order { @Id @GeneratedValue @Column(name = "order_id") private Long id; @ManyToOne(fetch = FetchType.LAZY) @..

JPA에서 연관관계를 매핑하는 관계로 1:1, 1:N, N:1, N:M 등과 같은 다양한 연관관계 매핑이 존재합니다. 일반적인 엔티티와 엔티티 사이의 매핑을 나타내는데, 객체지향 프로그래밍에서는 상속관계가 존재합니다. 그럼 엔티티 사이에도 상속관계가 존재할 수 있을까? 라는 궁금증이 생깁니다. 결론적으로 관계형 데이터베이스는 상속 관계가 존재하지만, 슈퍼타입 서브타입 관계라는 모델링 기법이 존재합니다. 이 기법이 객체 상속과 유사한 기법이라고 할 수 있습니다. 즉, 공통된 데이터를 슈퍼타입에 남기고 객체가 가지고 있는 특별한 속성들만 서브타입에 남겨주는 구조를 가지고 있습니다. JPA에서는 상속관계 매핑을 지원하는데, 객체의 상속 구조와 데이터베이스의 슈퍼타입, 서브타입 관계를 매핑한다고 할 수 있습니다..

이전 포스팅에서 양방향 매핑에 대해 알아보았습니다. 단방향, 양방향 연관관계에 대해서 알아보았고 연관관계의 주인을 설정하는 것 까지 알아보았습니다 ! 이번에는 연관관계를 매핑하는 것에 대해 알아보겠습니다. 연관관계 매핑시 고려해야할 점이 3가지가 있습니다. 첫 번째는 '다중성', 두 번째는 '단방향, 양방향', 세 번째는 '연관관계의 주인' 입니다. 먼저 다중성은 1:1, 1:N과 같은 비율을 이야기합니다. JPA에서 다룰 수 있는 다중성은 N:1(@ManyToOne), 1:N(@OneToMany), 1:1(@OneToOne), N:M(@ManyToMany)가 있습니다. 이런 다중성과 함께 단방향, 양방향 매핑을 정할 수 있습니다. 테이블은 외래 키 하나로 양쪽 조인이 가능하고, 객체는 참조 필드가 있는..

스프링 부트와 AWS로 혼자 구현하는 웹 서비스를 읽고 정리한 내용입니다. 프로젝트를 할 때 프로젝트의 패키지를 나누는 것은 중요합니다. 패키지 마다 구분된 역할을 하도록 설계하여 모듈마다 결합도는 낮추고 응집도를 높여 모듈은 각자의 역할만 해야되기 때문입니다. 스프링 웹 계층에는 Web, Service, Repository, DTOs, Domain Model 5가지 계층이 있습니다. 각 계층의 역할에 대해서 알아보겠습니다. Web Layer 흔히 사용하는 Controller와 JSP등의 View 템플릿 영역입니다. 이외에도 Filter, Intercepter, ControllerAdvise등 외부 요청과 응답에 대한 전반적인 영역을 의미합니다. 웹 애플리케이션의 최상위에 존재한다고 생각하면 됩니다. S..

객체와 테이블 연관관계 차이를 이해하고, 객체의 참조와 테이블의 외래키를 매핑할 수 있어야 합니다. 객체를 테이블에 맞춰 데이터 중심으로 모델링하면 협력관계를 만들 수 없습니다. 테이블은 반드시 외래키로 조인을 해서 연관된 테이블을 찾고, 객체는 참조를 사용해서 연관된 객체를 찾습니다 ex) member.getTeam(). 따라서 테이블과 객체 사이에는 이런 큰 간격이 존재하게 됩니다. 단방향 연관관계 테이블의 연관관계는 외래 키 하나로 양방향이 존재합니다. 즉 테이블의 연관관계는 양방향이라는 것이 없다고 할 수 있습니다. 왜냐하면 외래키 하나만 있으면 양쪽 테이블에 관해 알 수 있기 때문입니다. MEMBER.TEAM_ID 외래 키 하나로 연관관계를 가지고 양쪽 조인이 가능합니다. SELECT * FRO..

엔티티 매핑 객체와 테이블 매핑: @Entity, @Table 필드와 컬럼 매핑: @Column 기본 키 매핑: @Id 연관관계 매핑: @ManyToOne, @JoinColumn 객체와 테이블 매핑 @Entity가 붙은 클래스는 JPA가 관리하고 엔티티라고 합니다. JPA를 사용해서 테이블과 매핑할 클래스는 @Entity가 필수입니다. 기본 생성자도 public 이나 protected로 반드시 생성하고, final class, enum, interface, inner class에는 사용할 수 없습니다. @Table로 디비 테이블에 저장될 이름을 따로 설정할 수 있습니다. @Entity @Table(name = "ORDERS") public class Order extends BaseEntity{ @Id ..

JPA가 도입된 배경 SQL을 한 땀 한 땀 작성하는 것은 효율적이지 못합니다. CRUD 하나 만드는데만 INSERT INTO, UPDATE, SELECT .. 등등의 많은 쿼리문들을 손으로 직접 작성하여 디비에 쿼리를 날리는 것은 무한 반복작업입니다. 만약 테이블을 다 짜고 SQL 구문까지 다 작성했는데 갑자기 수정사항이 발생하면 쿼리 모두를 수정해야하는 경우가 생깁니다. 즉 SQL에 의존적인 개발을 피할 수 없었습니다. 수십줄의 코드가 단 한 두줄로 ! -> 수십 개 이상의 복잡한 객체와 테이블을 사용합니다. 그러므로 객체 테이블을 정확하게 설계하고 매핑하는 것이 중요합니다. -> JPA 내부 동작 방식을 반드시 이해해야합니다. JPA가 어떤 SQL을 만들고 언제 SQL을 실행하는지 ! JPA에서 가..

스프링 버젼이 높아지며 변화한 것 중 하나는 JUnit 기반의 테스트입니다. 4.X에서 JUnit의 테스트 러너를 확장하는 방법 중 하나로 @RunWith(SpringRunner.class) 에노테이션을 사용하였습니다. 스프링 부트를 사용하여 테스트를 진행하는 경우 항상 이 에노테이션을 붙여서 사용했습니다. 아래의 MemberServiceTest 코드를 보시면 알 수 있습니다. // JUnit 4 버젼의 테스트 코드 @RunWith(SpringRunner.class) @SpringBootTest @Transactional public class MemberServiceTest { @Autowired MemberService memberService; @Autowired MemberRepository me..