기록하는 개발자

회원가입을 하는 경우, 아이디에 대한 중복검사를 하는 기준을 이메일로 선정하였습니다. 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에서는 상속관계 매핑을 지원하는데, 객체의 상속 구조와 데이터베이스의 슈퍼타입, 서브타입 관계를 매핑한다고 할 수 있습니다..

설치환경 서버:Ubuntu 20.04 LTS 커널: 5.13 1. ctags + cscope 설치 apt-get install ctags -y apt-get install cscope -y 2. vim + plugin 설치 git clone을 하기 위해 git도 함께 설치합니다. 미리 설치되있으면 생략해도 됩니다. sudo apt-get install vim -y sudo apt-get install git -y 3. 디렉토리 생성 및 git clone mkdir ~/.vim mkdir ~/.vim/bundle git clone https://github.com/VundleVim/Vundle.vim.git ~/.vim/bundle/Vundle.vim 4. .vimrc 파일 생성 vim 환경설정을 하는 ...

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

얼마전까지만 해도 깃허브에 커밋을 날릴 때 일정한 규칙 없이 커밋 메세지를 작성하고 푸쉬하곤 했습니다. 혼자서 개발할 때야 크게 상관없지만 다른 팀원들과 협업을 하는 경우 커밋 메세지는 상당히 중요한 도구입니다 ! 프로젝트 과정에서 무엇보다도 팀원과의 소통이 굉장히 중요하기 때문에 커밋 메시지를 좀 더 효율적으로 작성해봐야겠다고 생각했습니다. 커밋 메세지를 통해 어떤 점이 추가된지, 변경되었는지 쉽게 알아볼 수 있고 issue도 함께 처리할 수 있다는 장점이 있습니다. 또 과거 커밋내역을 살펴보며 코드 추적도 훨씬 편하게 할 수 있습니다. 온라인에 좋은 커밋 메세지 작성요령이 많이 나와있습니다. 많은 작성요령들을 살펴보다보면 공통적인 특징이 있습니다. 커밋 메세지의 7가지 규칙 : -- 헤더 -- 빈 줄..

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

https://www.acmicpc.net/problem/1520 1520번: 내리막 길 첫째 줄에는 지도의 세로의 크기 M과 가로의 크기 N이 빈칸을 사이에 두고 주어진다. 이어 다음 M개 줄에 걸쳐 한 줄에 N개씩 위에서부터 차례로 각 지점의 높이가 빈 칸을 사이에 두고 주어진다. www.acmicpc.net 문제 설명 0,0 에서부터 내려와 m, n까지 도착하는 경로의 개수를 찾는 것이 문제이다. 다음번 이동할 칸은 현재 칸의 값보다 작아야 이동할 수 있다. bfs를 돌면서 상하좌우를 체크해주면 되는데, 한번 방문한 좌표는 다시 방문할 수 있는 것이 특징이다. 한번 방문한 좌표는 다시 상하좌우를 체크해줄 필요가 없다. 그러므로 이전 경로까지 가는 경우의 수를 더해주기만 하면 된다. 이 문제에서의 중..

객체와 테이블 연관관계 차이를 이해하고, 객체의 참조와 테이블의 외래키를 매핑할 수 있어야 합니다. 객체를 테이블에 맞춰 데이터 중심으로 모델링하면 협력관계를 만들 수 없습니다. 테이블은 반드시 외래키로 조인을 해서 연관된 테이블을 찾고, 객체는 참조를 사용해서 연관된 객체를 찾습니다 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 ..