[Spring] Cookie HTTP는 Stateless한 프로토콜이므로 이전에 보낸 Request에 대해서 기억하지 못한다 이러한 Stateless한 특징을 해결하기 위해서 "쿠키"라는 개념을 활용한다 예를 들어서 로그인을 한다고 하자 어떤 사 cs-ssupport.tistory.com "쿠키"는 HTTP의 Stateless로 인해 탄생한 "유지를 위한 수단"이다 쿠키를 통해서 중요한 정보를 보관할 수 있고 쿠키를 통해서 Client & Server간에 인증을 간편하게 할 수 있었다 하지만 쿠키에는 여러가지 보안 이슈가 존재한다 가장 대표적인 보안 이슈는 쿠키에 Client의 중요 정보가 담길 수 있다는 것이다. 따라서 이러한 보안 이슈를 해결하려면 "중요한 정보들은 모두 서버에 저장"해야 하고 Cli..

HTTP는 Stateless한 프로토콜이므로 이전에 보낸 Request에 대해서 기억하지 못한다 이러한 Stateless한 특징을 해결하기 위해서 "쿠키"라는 개념을 활용한다 예를 들어서 로그인을 한다고 하자 어떤 사용자가 "A-1"라는 페이지에서 로그인을 하고나서 "A-2" 페이지로 이동하였다고 하자 stateless한 HTTP 특징에 의하면 A-2 페이지에서도 로그인을 유지하려면 query parameter를 통해서 로그인 정보를 유지해야 한다 여기서 이러한 상태 유지를 위해서 "쿠키"를 사용하는 것이다 Cookie 쿠키에는 2가지 종류가 존재한다 세션 쿠키 : 브라우저가 종료되면 사라지는 쿠키 영속 쿠키 : 브라우저가 종료되어도 "지정한 만료일"까지 유지되는 쿠키 기본적인 쿠키 로그인 테스트를 위해..

영속성 전이 : CASCADE 특정 엔티티를 "영속 상태"로 만들 때 → 연관된 엔티티도 함께 영속 상태로 만들고 싶다면 어떻게 해야할까 >> 영속성 전이 기능 (Transitive Persistence) JPA에서는 영속성 전이를 CASCADE 옵션을 통해서 제공한다 @Getter @NoArgsConstructor(access = AccessLevel.PROTECTED) @Entity @Table(name = "member") public class Member { @Id @GeneratedValue(strategy = GenerationType.IDENTITY) @Column(name = "member_id") private Long id; private String name; @ManyToOne(f..

> "즉시 로딩 전략"을 활용하면 연관된 Entity도 DB에서 조회해서 실제 Entity가 반환된다 대부분의 JPA 구현체는 "즉시 로딩을 최적화"하기 위해서 가능하면 조인 쿼리를 사용한다 >> 위의 예제에서도 Member와 Team간의 left outer join을 통해서 쿼리 1번으로 연관된 두 엔티티를 모두 조회하였다 ※ 즉시로딩 & NULL 제약 조건 위의 조인을 잘 보면 "left outer join" : 외부조인을 통해서 Member과 Team이 조인을 하고 있다 현재 Member Table에서는 Team 컬럼에 대한 nullable을 허용하고 있는 상태이다 >> 따라서 Player중에 team이 없는 Player도 존재한다는 의미이다 그렇기 때문에 이 Member에 대한 instance도 ..

선수 Entity와 팀 Entity가 존재하고 서로 다대일 관계이다. Player (N) @Getter @NoArgsConstructor(access = AccessLevel.PROTECTED) @Entity @Table(name = "player") public class Player { @Id @GeneratedValue(strategy = GenerationType.IDENTITY) @Column(name = "player_id") private Long id; private String name; @ManyToOne @JoinColumn(name = "team_id") private Team team; } Team (1) @Getter @NoArgsConstructor(access = Access..

DB에서 두 테이블간에 관계를 나타낼때는 총 2가지로 분류할 수 있다 1. 상대방의 PK를 자신의 PK이자 FK로 사용 = 식별관계 2. 상대방의 PK를 자신의 FK로 사용 = 비식별관계 필수적 비식별 관계(Mandatory) : FK에 NULL 허용 X 선택적 비식별 관계(Optional) : FK에 NULL을 허용 O 비식별 관계 (복합키) 현재 PARENT Table은 PK가 "복합키"로 구성되어있는 상태이고 CHILD와 1:N 관계이다 따라서 CHILD는 PARENT의 PK : 복합키를 자신의 FK로 활용함으로써 둘의 관계는 비식별 관계이다 @Entity @Table(name = "parent") public class Parent { @Id @Column(name = "parent_id1") p..

[JPA] 상속 관계 일반적으로 관계형 DB에서는 객체지향 언어에서 다루는 "상속"이라는 개념이 존재하지 않는다 그대신 "슈퍼타입 - 서브타입"같은 모델링 기법을 통해서 우회적으로 상속을 구현할 수 있다 슈퍼 cs-ssupport.tistory.com 상속 관계의 기본적으로 JOINED 전략을 사용하면 Super Type & Sub Type 모두 DB Table과 매핑되었다 하지만 여기서 부모 클래스는 DB Table과 매핑하지 않고 자식 클래스에게 속성만 물려주고 싶다면 @MappedSuperClass를 사용하면 된다 @MappedSuperClass는 단순히 "필드 정보"를 상속할 목적으로만 사용하는 것이다 예를 들어서 거의 모든 테이블에 필요한 {생성 날짜 / 생성한 사람 / 수정 날짜 / 수정한 사..

일반적으로 관계형 DB에서는 객체지향 언어에서 다루는 "상속"이라는 개념이 존재하지 않는다 그대신 "슈퍼타입 - 서브타입"같은 모델링 기법을 통해서 우회적으로 상속을 구현할 수 있다 슈퍼타입 - 서브타입 논리적 모델을 실제 DB에 들어가는 물리적 모델로 구현하는 방법은 총 3가지가 존재한다 "각각 테이블"로 변환 "통합 테이블"로 변환 "서브타입 테이블"로 변환 1. 각각 테이블로 변환 - "조인 전략 (Super Type + Sub Type)" 조인 전략이란 엔티티 각각을 일단 모두 테이블로 만들어준다 그리고 "자식 테이블"은 부모 테이블의 PK를 자신의 PK이자 FK로 사용한다 조회할때는 당연히 Join을 많이 사용하게 된다 >> @Inheritance(strategy = InheritanceType..

[Spring] 검증(Validation) 1. 직접 구현하기 MVC 패턴에서 Controller는 request로 들어온 URL에 대한 처리도 하지만, HTTP Request 자체가 정상인지 "검증"하는 역할도 수행한다 물론 Front쪽에서 검증을 할 수 있지만, 이는 Client가 의도적인 조작을 통 cs-ssupport.tistory.com 앞에서 검증 기능을 직접 작성함으로써 객체에 대한 검증을 하였다 그런데 검증 기능을 매번 코드로 작성하려면 엄청난 시간과 노력을 투자해야 한다 그리고 대부분의 검증 로직은 {빈 값인지 아닌지 / 특정 크기를 넘는지 아닌지 / ...} 등 매우 일반적인 로직이다 이러한 검증 로직을 모든 프로젝트에 적용할 수 있게 공통화하고, 표준화 한 것이 바로 "Bean Val..

MVC 패턴에서 Controller는 request로 들어온 URL에 대한 처리도 하지만, HTTP Request 자체가 정상인지 "검증"하는 역할도 수행한다 물론 Front쪽에서 검증을 할 수 있지만, 이는 Client가 의도적인 조작을 통해서 우회해서 접근할 수 있기 때문에 Front쪽에서 1차 검증을 한 후, 2차적으로 Server에서 검증을 해야 한다 BindingResult BindingResult를 활용하면 request로 들어온 data에 대한 오류를 간단하게 담을 수 있고 model을 통해서 자동으로 넘겨줄 수 있다 BindingResult가 "없다면" 400 error가 발생하면서 컨트롤러 자체가 호출되지 않는다 반면에 BindingResult가 "있다면" 오류 정보를 BindingRes..

관계형 데이터베이스에서는 애초에 "정규화된 테이블" 2개로 다대다 관계를 표현할 수 없다 따라서 다대다 관계를 {일대다 - 다대일}로 풀어주는 "연결 테이블"을 사용한다 Member & Product는 다대다 관계이므로 "Member_Product"라는 연결 테이블을 통해서 {일대다 - 다대일}로 풀어버렸다 하지만 객체에서는 객체 2개로 "다대다 관계"를 만들어낼 수 있다 각 객체마다 상대방 객체를 컬렉션화 시켜서 관리하면 된다 1. 다대다 단방향 Member (N - 주인) @Getter @NoArgsConstructor(access = AccessLevel.PROTECTED) @Entity @Table(name = "member") public class Member { @Id @GeneratedVa..

일대일 관계는 양쪽이 서로 하나의 관계만 가지는 관계이다 따라서 일대일 관계에서는 "어느 쪽이든 FK를 가질 권리"를 보유하고 있다 참고로 일대일 연관관계에서 FK에는 반드시 UNIQUE도 추가해줘야 한다 왜냐하면 UNIQUE 제약조건을 추가해주지 않으면 일대일이 아니라 일대다가 되기 때문이다 1. 주 테이블 FK 일반적으로 "개발자" 입장에서는 주 테이블에 FK가 있는 것을 선호한다 왜냐하면 주 테이블에 FK가 있어야 더 편리하게 매핑할 수 있기 때문이다 대상 테이블에 FK가 존재한다면 본인이 아닌 상대방의 column을 관리해야 하기 때문 (1) 주 테이블 FK - 단방향 일반적으로 생각해보면 "User는 Ticket 하나를 소유할 수 있다"이므로 User를 "주테이블"로 생각해서 매핑해보자 User..