https://github.com/gavlyukovskiy/spring-boot-data-source-decorator이 레포 들어가서 이걸 그래들에 추가해주면 된다. 참고로 설명에 나와있듯이 스프링 부트 2.X 는 1.8.1 까지가 최신이고스프링 부트 3.X

JPA 에서는 데이터 타입은 크게 두 가지로 분류되는데, 1) 엔티티 타입 그리고 2) 값 타입 으로 나눌 수 있다. 여기서 오해하지말아야할게 지금 말한 JPA에서 말하는 데이터 타입은 자바에서 나누고 있는 원시타입, 참조변수 타입과 다른 개념이다. 위와 같이 회원 엔

영속성 전이란 관계 매핑 설정 중 하나로, 엔티티의 상태 변화가 다른 연관된 엔티티에게 전파 되도록 하는 매커니즘을 나타낸다.간단히 말해 "내가 삭제되면 나랑 연관관계 맺은 애들도 삭제되어야하고, 내가 저장되면 나랑 연관관계 맺은 애들도 같이 저장되어야 한다."는 것

1. 지연 로딩이란? 우리가 게시글을 조회한다고 가정해보자. 게시글 엔티티는 회원 엔티티와 연관관계가 맺어져있긴 하지만 우린 오직 게시글에 대한 정보만을 조회 하고 싶다. 하지만 아쉽게도 `POST 테이블을 조회하면 JPA는 우리 몰래 MEMBER 테이블을 모조리

0. 모든 연관관계 다중성 다대일 : 단방향, 양방향** 일대다 : 단방향, 양방향** 일대일 : 주 테이블 단방향, 양방향 : 대상 테이블 단방향, 양방향 다대다 : 단방향, 양방향 1. 다대일 다대일 : 단방향 여태 앞에서 예시로 다뤘던 연관관계이며 기본적

객체 관계 매핑 - 양방향★★★ 여지껏 단방향만 다뤄 보았으니 이번엔 양방향매핑을 살펴보자. 양방향 관계 연관관계의 경우 앞에서도 설명했지만, _테이블은 양방향, 객체는 단방향_ 이라고 분류를 했다. 그리고 그 뒤에 객체도 각 엔티티 객체가 서로를 참조하게끔 하

1. 테이블 연관관계 VS 객체 연관관계 연관 관계 맺기 `테이블` 는 FK 를 가지고 서로 다른 테이블이 연관 관계를 맺는다. `객체` 는 참조주소 를 통해 서로 다른 객체와 연관 관계를 맺는다. 연관 관계 탐색 `테이블` 는 JOIN 연산을 통해 연관관계 탐색을

0. 매핑 어노테이션 과거에는 엔티티 매핑에 XML 을 사용해왔지만 최근 트랜드는 어노테이션을 활용하는 것이 대세이다. JPA는 다양한 어노테이션들을 제공하고 있기 때문에 엔티티와 테이블을 정확히 매핑하기 위해선 매핑 어노테이션들을 제대로 숙지하고 있어야한다. 어노

엔티티 매니저는 엔티티를 저장하고，수정하고, 삭제하고, 조회 하는 등 엔티티와 관련된 모든 일을 처리한다. 이름 그대로 엔티티를 관리하는 관리자다. 앞장에서 패러다임의 불일치를 다루면서 계속해서 "데이터를 DB가 아닌, 컬렉션에 저장 했더라면? " 과 같은 내용을 언

1. JPA이전의 역사 자바 개발자라면 무조건 알아야하는 기술 스택중 하나이면 자바 개발자를 준비하는 사람이라면 한번쯤은 꼭 들어봤을것이다. 그렇다면 도대체 JPA가 뭘까? >Java Persistence API 의 약자로 자바 진영에서 ORM(Object-Relati

좀 더 와닿는 설명을 위해 한번 있을법한 상황으로 회원가입과 로그 저장 을 예시로 설명을 해보겠다.회원들이 회원가입을 할 경우, 회원가입을 했다는 로그 기록 또한 같이 DB에 저장하고 싶음.데이터 정합성을 위해 회원가입 또는 로그저장 둘 중 하나라도 실패하면 실패한 트

1. 기본적인 트랜잭션 - 커밋, 롤백 여태 우리는 하나의 커넥션에서 하나의 트랜잭션이 발생하는 상황만 고려를 해왔다. 트랜잭션매니저는 먼저 >1. 데이터소스로부터 새로운 커넥션을 할당 받고 `tx1` 이라는 트랜잭션을 생성한다. > 그 다음 서비스로직이 수행된 후

Exception 의 하위 예외 중 런타임 예외(자식 포함)를 제외한 모든 예외들반드시 에러를 처리 혹은 throws를 추가 해줘야한다.런타임 예외와 그 자식들컴파일러가 예외 처리를 강제하지 않기 때문에 따로 처리할 필요가 없다. 스프링에서는 트랜잭션 처리과정에서 예외

이전에 스프링의 트랜잭션 내부동작을 꽤나 디테일하게 다뤘었는데 이번에 한번 슬쩍 다시 복습하는김에 복기를 해본다.서비스 계층은 오로지 비즈니스 로직만을 다루고 있어야한다. 그렇기 때문에 트랜잭션 처리와 같은 데이터 베이스 접근 코드는 따로 분리를 해줘야한다. 트랜잭션

이전에도 말했듯이 서비스계층은 비즈니스 로직만을 담는 계층이다. 즉, DB와 접근하는 기술, 트랜잭션 처리 기술 과 같이 다른 곳에서 처리해야하는 기술 로직이 포함되어있으면 안된다. 이를 해결하고자 스프링에서는 프록시와 AOP를 도입하게되었다.프록시는 간단히 말해서 대

코드의 중복은 언제나 문제를 발생시킨다.트랜잭션이 있을 때마다 커밋과 롤백이 곁다리로 추가가 되며 짜증나는 try-catch 문이 가독성 마져 왕창 떨어뜨린다.역시 이런경우를 대비해 만능의 스프링은 또 좋은걸 제공해준다. 바로 TransactionTemplateTran

관심사의 분리는 한 객체가 너무 많은 역할과 책임을 지면 안된다는 의미로 객체지향 설계의 근간이 되는 철학중 하나이다. 이 이야기를 왜 하는가?우린 앞에서 JDBC 기술을 이용해 DB 와 연동을 하고 트랜잭션도 처리해보았다. 하지만 보다시피 코드는 try-catch 문

`Filter` 에 대해 간단히 알아 보았으니 이제 본격적으로 모든 페이지들에 대해 로그인 체크를 하는 필터를 개발해보자. 1. LoginCheckFilter : Filter 구현체 `Filter` 는 인터페이스였으므로 개발자가 사용 목적에 맞춰 구현을 해줘야한다.

비로그인 사용자의 경우 -> return false;로그인 사용자의 경우 -> return true;Filter 구현 때와 달리 따로 whitelist URL 들을 만들어서 관리할 필요가 없다. 왜냐하면 해당 작업은 있다가 Config 파일에 등록할 때 같이 적용 시킬

앞 시간에선 Filter 를 이용해 컨트롤러 시작전 먼저 request를 검사해 로그인 사용자와 비로그인 사용자를 구분하였다. 하지만 위와 같은 로그인 체크를 필터 말고도 인터셉터 라는 기술로도 구현 할 수 있다고 잠깐 언급되었었다.사실 Filter 의 경우 눈치챘을