# 관련링크 - [재생목록](https://www.youtube.com/playlist?list=PLE0hRBClSk5JELNKnXQWSe1zTdyjgC1Vo) # 1강 - [24 12 11, p 13888, 1강, Spring Data JPA 로 DB를 편하게 다룰 수 있다.](https://youtu.be/tuqtUcJ1_4w) ## Spring Data JPA to DB 까지의 호출구조 $$uml participant "Spring Data JPA" as SpringDataJPA participant "JPA" as JPA participant "Hibernate" as Hibernate participant "JDBC" as JDBC participant "DB Driver" as Driver participant "DBMS" as DBMS SpringDataJPA -> JPA: 요청 activate JPA JPA -> Hibernate: 변환/위임 activate Hibernate Hibernate -> JDBC: SQL 실행 요청 activate JDBC JDBC -> Driver: DB 연결/쿼리 전달 activate Driver Driver -> DBMS: 실제 쿼리 실행 activate DBMS DBMS --> Driver: 결과 반환 deactivate DBMS Driver --> JDBC: 결과 전달 deactivate Driver JDBC --> Hibernate: 결과 전달 deactivate JDBC Hibernate --> JPA: 엔티티 변환 deactivate Hibernate JPA --> SpringDataJPA: 최종 결과 반환 deactivate JPA $$ # 2강 - [24 12 11, p 13888, 2강, 프로젝트 생성 후 GIT PUSH](https://youtu.be/d5WE_PNHxXs) - [GITHUB - 저장소 생성 - https://github.com/new](https://github.com/new) - [GITHUB - 저장소 - https://github.com/jhs512/jpa-2024-12-11](https://github.com/jhs512/jpa-2024-12-11) - [커밋](https://github.com/jhs512/jpa-2024-12-11/commit/da89533) ## 프로젝트 생성 - [스프링 이니셜라이저 - https://start.spring.io/](https://start.spring.io/) - ![img](https://i.imgur.com/BBvnv9x.png) # 3강 - [24 12 11, p 13888, 3강, datasource 설정, 콘솔출력 컬러풀하게 설정, 1부 : 설정](https://youtu.be/j8Ah9XKcOB8) - [24 12 11, p 13888, 3강, datasource 설정, 콘솔출력 컬러풀하게 설정, 2부 : .gitignore 에 db 파일 추가](https://youtu.be/U_QYig1ilNw) - [커밋](https://github.com/jhs512/jpa-2024-12-11/commit/abe4df6) # 4강 - [24 12 11, p 13888, 4강, ddl-auto: update 로 설정하여 엔티티 클래스의 변경사항이 바로바로 DB에 반영됨](https://youtu.be/x-FZG26aNXI) - [커밋](https://github.com/jhs512/jpa-2024-12-11/commit/e039e95) ## 테이블 생성 ```sql create table post (id bigint generated by default as identity, content TEXT, created_at timestamp(6), modified_at timestamp(6), title varchar(100), primary key (id)) ``` ## 테이블 칼럼 추가 ```sql alter table if exists post add column blind boolean not null ``` # 5강 - [24 12 11, p 13888, 5강, PostRepository, ApplicationRunner 로 샘플 Post 데이터 생성되도록](https://youtu.be/sBK-eaLcznY) - [커밋](https://github.com/jhs512/jpa-2024-12-11/commit/6796e9d) # 6강 - [24 12 11, p 13888, 6강, 샘플 글이 이미 존재한다면 더 이상 만들지 않도록](https://youtu.be/ijvt3hwls2I) - [커밋](https://github.com/jhs512/jpa-2024-12-11/commit/509301f) # 7강 - [24 12 11, p 13888, 7강, JPA에 의해서 실행되는 쿼리와 그것의 결과를 자세히 출력하도록](https://youtu.be/ZgfJtH-SEo8) - [커밋](https://github.com/jhs512/jpa-2024-12-11/commit/5dd5cf5) # 8강 - [24 12 11, p 13888, 8강, 엔티티 클래스에 @Builder 를 붙이려면 @AllArgsConstructor, @NoArgsConstructor 가 필수](https://youtu.be/iEoq9pcGYjg) - [커밋 - @AllArgsConstructor 때문에 인자없는 생성자가 생기지 않음, 추후 SELECT 결과로 엔티티 객체 생성시에 문제가 됨](https://github.com/jhs512/jpa-2024-12-11/commit/33b99b3) - [커밋 - 기존의 ApplicationRunner 빈 보다 더 늦게 만들어지는 빈을 하나 더 추가](https://github.com/jhs512/jpa-2024-12-11/commit/a7af9a9) - [커밋 - findById 시도했으나 실패, 엔티티 클래스에는 인자없는 생성자가 필요](https://github.com/jhs512/jpa-2024-12-11/commit/3f0c290) - [커밋 - @Builder만 붙이면 인자없는 생성자가 사라지니 @NoArgsConstructor 붙이고 @AllArgsConstructor 도 추가](https://github.com/jhs512/jpa-2024-12-11/commit/201d054) - @Builder 는 @AllArgsConstructor 를 필요로 한다. - @Builder 만 있으면 자동으로 모든 인자를 받는 생성자(@AllArgsConstructor)를 만든다. - @Builder 와 @NoArgsConstructor 가 있으면 스스로 모든 인자를 받는 생성자(@AllArgsConstructor)를 만들지 않는다.(큰 이유는 없고 롬복의 정책이 그렇다.) - 결론적으로 @Entity 클래스에 @Builder 를 쓰려면 @AllArgsConstructor 와 @NoArgsConstructor 가 필요하다. # 9강 - [24 12 11, p 13888, 9강, @CreatedDate 와 @LastModifiedDate 로 날짜 관련 필드가 자동으로 채워지도록](https://youtu.be/noRPE2Y3eWg) - [커밋](https://github.com/jhs512/jpa-2024-12-11/commit/fb54b70) # 10강 - [24 12 11, p 13888, 10강, JPA 는 save 메서드에서 실제로 바뀐게 없다면 UPDATE 쿼리를 실행하지 않는다.](https://youtu.be/XqVgO1RNQ0U) # 11강 - [24 12 11, p 13888, 11강, 하나의 @Transactional 내에서 SELECT 로 조회된 엔티티 객체의 수정은 자동으로 UPDATE 를 통해서 DB에 반영](https://youtu.be/xzdywDec70E) - [커밋](https://github.com/jhs512/jpa-2024-12-11/commit/72b5ec0) ## 영속성 컨텍스트 - 영속성 컨텍스트 : 하나의 트랜잭션 내에서 조회된 엔티티 객체를 보관하는 공간 - 트랜잭션이 종료되면 영속성 컨텍스트도 사라진다. - 지금은 단순히 엔티티 객체가 저장되는 임시공간 이라고 생각하면 된다. - 영속성 컨텍스트는 트랜잭션 당 하나이다. ## 더티 체킹 - 하나의 @Transactional 이 끝나면 해당 트랜잭션 내에서 조회된 엔티티 객체의 수정사항은 자동으로 UPDATE 를 통해서 DB에 반영된다. - 이를 더티 체킹이라고 한다. - 더티 체킹 시점 : @Transactional 이 끝날 때 - 더티 체킹 원리 - 영속성 컨텍스트에 있는 엔티티 객체의 수정 사항을 찾는다. - 찾은 수정 사항을 반영하여 UPDATE 쿼리를 실행한다. - 더티 체킹이 좋은 이유 : 편리하다. - 자세한 이유 : 더티 체킹은 트랜잭션이 끝날 때 자동으로 실행되기 때문에 개발자가 직접 UPDATE 쿼리를 실행할 필요가 없다. # 12강 - [24 12 12, p 13888, 12강, ORM 개념](https://youtu.be/eTjOlMD4KJU) ## 엔티티 클래스를 정의하면 등가의 DB 테이블이 생성됨 ### Article 엔티티 클래스 ```java @Entity public class Article { @Id @GeneratedValue(IDENTIFY) private Long id; private String title; private String content; private boolean blind; } ``` ### article 테이블 ```sql CREATE TABLE article ( id INT UNSIGNED NOT NULL PRIMARY KEY AUTO_INCREMENT, title CHAR(200) NOT NULL, content TEXT NOT NULL, blind BOOL NOT NULL ); ``` ## JPARepository 상속을 통해서 ArticleRepository 기능을 너무나 쉽게 만들 수 있음 ```java interface ArticleRepository extends JPARepository { // 여기에는 findById, findAll, save, delete 등의 메서드가 자동으로 생성된다. } ``` ## Article 엔티티 객체 생성 및 저장에 따라 관련 SQL이 자동으로 실행됨 ```java Article article = new Article(); article.setTtitle("제목 1"); article.setContent("내용 1"); System.out.println(article.getId()); // NULL, 이유 : 아직 DB에 저장되지 않았기 때문 articleRepository.save(article); // INSERT INTO article (title, content, blind) VALUES ('제목 1', '내용 1', false); System.out.println(article.getId()); // 1, 이유 : 이제 DB에 저장되었기 때문 Article article2 = new Article(); article.setTtitle("제목 2"); article.setContent("내용 2"); articleRepository.save(article2); // INSERT INTO article (title, content, blind) VALUES ('제목 2', '내용 2', false); article.setTitle("새 제목"); articleRepository.save(article); // UPDATE article SET title = '새 제목' WHERE id = 1; articleRepository.findById(5); // SELECT * FROM aritcle WHERE id = 5; articleRepository.findAll(); // SELECT * FROM aritcle; articleRepository.delete(article); // DELETE FROM article WHERE id = 1; ``` # 13강 - [24 12 12, p 13888, 13강, 영속성 컨텍스트에는 엔티티 객체의 복사본이 있고, 그걸 기반으로 끝날때 더티체킹을 통해서 UPDATE 쿼리가 발생](https://youtu.be/DpmDo5V8s1Y) # 14강 - [24 12 12, p 13888, 14강, MySQL 드라이버로 변경 후 트랜잭션 실험, 다시 H2 드라이버로 변경](https://youtu.be/EPIienfs0Zc) - [커밋 - MySQL 드라이버로 변경](https://github.com/jhs512/jpa-2024-12-11/commit/e7bbaa2) - [커밋 - 다시 H2 드라이버로 변경](https://github.com/jhs512/jpa-2024-12-11/commit/4ab8e39) # 15강 - [24 12 12, p 13888, 15강, postRepository.delete](https://youtu.be/rwXK-JfLB50) - [커밋](https://github.com/jhs512/jpa-2024-12-11/commit/d24e9d5) # 16강 - [24 12 12, p 13888, 16강, 강사의 리포지터리를 기반으로 프로젝트를 한방에 만드는 방법, 추가로 강사의 최신소스코드 반영하는 방법](https://youtu.be/8SWjJvZ9QBc) ## 주의사항 - 뭔가가 잘 안되면 그래들 싱크 버튼을 눌러주시고, 스프링부트를 재시작해주세요. ## 여러가지 실험 후 다시 원래대로 돌아오는 방법 ```bash git checkout -f . git clean -fd . ``` ## 강사의 최신소스코드 반영하는 방법 ```bash git pull origin main ``` # 17강 - [24 12 12, p 13888, 17강, domain 패키지 구조 설명, domain.post.comment.entity.PostComment.java](https://youtu.be/VowVIykC-NI) ## 패키지 예시 - domain.post.post.entity.Post.java - 여기서 첫번째 post는 큰 주제, 두번째 post는 작은 주제 - domain.post.comment.entity.PostComment.java - 여기서 첫번째 post는 큰 주제, 두번째 post는 작은 주제 - 위의 두 패키지 모두 큰 주제가 같은 패키지 이름을 가지고 있다. - 이렇게 하는 이유는 패키지 이름을 통해서 두 클래스(Post, PostComment)가 서로 관련이 있음을 알려주기 위함이다. - domain.member.member.entity.Member.java - 여기서 첫번째 member는 큰 주제, 두번째 member는 작은 주제 - domain.member.loginLog.entity.LoginLog.java - 여기서 첫번째 member는 큰 주제, 두번째 loginLog는 작은 주제 - 위의 두 패키지 모두 큰 주제가 같은 패키지 이름을 가지고 있다. - 이렇게 하는 이유는 패키지 이름을 통해서 두 클래스(Member, LoginLog)가 서로 관련이 있음을 알려주기 위함이다. # 18강 - [24 12 12, p 13888, 18강, 댓글(PostComment) 엔티티 클래스 정의, 샘플 댓글 3개 생성](https://youtu.be/aRgGYwwaD5A) - [커밋](https://github.com/jhs512/jpa-2024-12-11/commit/3d1bf04) # 19강 - [24 12 12, p 13888, 19강, Spring Data JPA를 사용할 때 실제 DB의 구조적 한계에 얽매이지 말고 객체지향적으로 사용하면 된다, JPA가 알아서 해결해줌](https://youtu.be/IICwpUzT0i4) ## JPA 패러다임 불일치 해결 - 자바와 데이터베이스 사이에 패러다임 불일치 문제가 있다. - 자바는 객체지향적이고, 데이터베이스는 관계형 데이터베이스이다. - 이러한 패러다임 불일치 문제를 해결하기 위해서 JPA를 사용한다. # 20강 - [24 12 12, p 13888, 20강, PostComment 클래스에서 조금 더 객체지향 적인 코드로 변경(long postId → Post post), @ManyToOne](https://youtu.be/PkEm6Fn2VhA) - [커밋](https://github.com/jhs512/jpa-2024-12-11/commit/dc7a768) ## @ManyToOne - 실제로 DB에 저장될 때는 post 가 아니라 post.id 가 저장되게 한다. # 21강 - [24 12 12, p 13888, 21강, @ManyToOne 필드는 기본적으로 EAGER 로 동작한다. 즉 JOIN 이 발생한다.](https://youtu.be/sy5q2W9pxCo) - [커밋](https://github.com/jhs512/jpa-2024-12-11/commit/19f738a) ## baseInitData2ApplicationRunner 메서드 ```java @Bean @Order(2) public ApplicationRunner baseInitData2ApplicationRunner() { return args -> { PostComment postComment3 = postCommentService.findById(3).get(); /* SELECT PC.id, PC.blind, PC.content, PC.created_at, PC.modified_at, P.id, P.blind, P.content, P.created_at, P.modified_at, P.title FROM post_comment AS PC LEFT JOIN post AS P ON P.id = PC.post_id WHERE PC.id = 3 */ Post postOfComment3 = postComment3.getPost(); }; } ``` # 22강 - [24 12 12, p 13888, 22강, @ManyToOne(fetch = FetchType.LAZY) 로 하면 필요할 만큼의 데이터만 가져오게 된다.](https://youtu.be/2nTXdv9SpBs) - [커밋](https://github.com/jhs512/jpa-2024-12-11/commit/ca6f2b3) ## baseInitData2ApplicationRunner 메서드 ```java @Bean @Order(2) public ApplicationRunner baseInitData2ApplicationRunner() { return new ApplicationRunner() { @Transactional @Override public void run(ApplicationArguments args) throws Exception { PostComment postComment3 = postCommentService.findById(3).get(); /* SELECT PC.* FROM post_comment AS PC WHERE PC.id = 3 */ Post postOfComment3 = postComment3.getPost(); System.out.println("postOfComment3.id = " + postOfComment3.getId()); System.out.println("postOfComment3.title = " + postOfComment3.getTitle()); /* SELECT P.* FROM post AS P WHERE P.id = 2 */ System.out.println("postOfComment3.content = " + postOfComment3.getContent()); } }; } ``` ## EAGER VS LAZY - EAGER : 즉 JOIN 이 발생한다. - LAZY : 필요할 만큼의 데이터만 가져오게 된다. - EAGER 로 할지 LAZY 로 할지는 헷갈린다면 LAZY 로 하는게 좋다. - 주의사항 : DB 커넥션이 끊긴상태에서 LAZY 로 설정된 필드를 조회하면 예외가 발생한다. # 23강 - [24 12 12, p 13888, 23강, 객체가 Lazy하게 로딩된다는 의미](https://youtu.be/07IX9auM-qM) # 24강 - [24 12 12, p 13888, 24강, 엔티티 객체의 LAZY 변수에는 프록시 객체가 연결된다.](https://youtu.be/NfsKP9Hor-k) ## 용어정리 - 가짜 == 프록시 == 대리자 - 가짜 객체는 요청을 받으면 실제 객체에게 요청을 토스합니다. - 프록시 객체는 요청을 받으면 실제 객체에게 요청을 토스합니다. - 대리자 객체는 요청을 받으면 실제 객체에게 요청을 토스합니다. ## 가짜 중국집도 중국집 처럼 행동하면 손님입장에서는 중국집이라고 생각하게 된다. ### 진짜 중국집에서 탕수육을 주문하는 과정 $$uml participant "손님" as 손님 participant "중국집" as 중국집 손님 -> 중국집: 탕수육 주세요. activate 중국집 중국집 --> 손님: 탕수육 응답 deactivate 중국집 $$ ### 가짜(프록시) 중국집에서 탕수육을 주문하는 과정 $$uml participant "손님" as 손님 participant "가짜 중국집" as 프록시 participant "중국집" as 중국집 손님 -> 프록시: 탕수육 주세요. activate 프록시 프록시 --> 중국집: 탕수육 주세요. activate 중국집 중국집 --> 프록시: 탕수육 응답 deactivate 중국집 프록시 -> 손님: 탕수육 응답 deactivate 프록시 $$ # 25강 - [24 12 12, p 13888, 25강, @Transactional 을 붙인 메서드를 가진 빈은 가짜(프록시) 객체로 조종하게 되고 그럴 수밖에 없다.](https://youtu.be/hX9a4tu3KLE) ## @Transactional 을 붙인 메서드를 가진 빈은 가짜(프록시) 객체로 조종하게 된다. - 스프링부트가 알아서 프록시 객체를 만들어주고, 프록시 객체의 리모콘을 제공한다. - 진짜 객체에 대한 리모콘을 바로 얻을 방법은 제공하지 않는다. ## 가짜 중국집에서 요리사도 없는데 트러플 탕수육을 만들 수 있는 과정 $$uml participant "손님" as 손님 participant "가짜 중국집" as 프록시 participant "중국집" as 중국집 손님 -> 프록시: 탕수육 주세요. activate 프록시 프록시 --> 중국집: 탕수육 주세요. activate 중국집 중국집 --> 프록시: 탕수육 응답 deactivate 중국집 프록시 --> 프록시: 탕수육에 트러플 가루 뿌리기 프록시 -> 손님: 트러플 탕수육 응답 deactivate 프록시 $$ ## 가짜 객체(프록시 객체)를 통해서 @Transactional 이 작동하는 과정 $$uml participant "사용자" as 사용자 participant "프록시" as 프록시 participant "실제 객체" as 실제객체 participant "트랜잭션 매니저" as 트랜잭션_매니저 사용자 -> 프록시: run() activate 프록시 프록시 <--> 트랜잭션_매니저: transaction 시작 activate 트랜잭션_매니저 프록시 --> 실제객체: run() activate 실제객체 실제객체 --> 프록시: run() 종료 deactivate 실제객체 프록시 <--> 트랜잭션_매니저: transaction 종료 deactivate 트랜잭션_매니저 프록시 --> 사용자: run() 종료 deactivate 프록시 $$ # 26강 - [24 12 12, p 13888, 26강, @Transactional 붙은 메서드라도 this 를 통한 호출은 트랜잭션이 작동하지 않는다.](https://youtu.be/cJyKrXBf5mc) ## 이유 - @Transactional 붙은 메서드라도 this 를 통한 호출은 트랜잭션이 작동하지 않는다. - 프록시 객체가 아니라 진짜 객체를 호출하기 때문이다. ## 가짜 객체(프록시 객체)를 통하지 않고 진짜 객체의 메서드에서 this 로 @Transactional 메서드 호출하는 과정(트랜잭션 작동 : X) $$uml participant "사용자" as 사용자 participant "프록시" as 프록시 participant "실제객체 run2" as 실제객체_run2 participant "실제객체 run" as 실제객체_run 사용자 -> 프록시: run2() activate 프록시 프록시 --> 실제객체_run2: run2() activate 실제객체_run2 실제객체_run2 --> 실제객체_run: run() activate 실제객체_run 실제객체_run --> 실제객체_run2: run() 종료 deactivate 실제객체_run 실제객체_run2 --> 프록시: run2() 종료. deactivate 실제객체_run2 프록시 --> 사용자: run2() 종료. deactivate 프록시 $$ # 27강 - [24 12 12, p 13888, 27강, @Transactional 붙은 메서드를 내부 호출 하려면 self 를 통해서 호출해야 한다.](https://youtu.be/OS4aQf_FzAI) ## 이유 - @Transactional 붙은 메서드를 내부 호출 하려면 self 를 통해서 호출해야 한다. - this 로 호출하면 프록시 객체를 경유하지 않기 때문이다. - 트랜잭션 시작과 종료 로직은 프록시 객체에 있다. - self 라는 것은 단순히 강사가 사용하는 변수명이다. - self 는 this 와 다르게 프록시 객체와 연결되어 있다. ## self 변수를 얻는 예제 ```java @Configuration @RequiredArgsConstructor public class BaseInitData { @Autowired // 필수 @Lazy // 필수 // final 은 제거해야 한다. private BaseInitData self; // 변수명을 self 가 아닌 다른것을 상요해도 된다. // 나머지 로직 } ``` # 28강 - [24 12 12, p 13888, 28강, self 의 진정한 목적 : @Transactional 붙은 메서드를 내부적으로 호출](https://youtu.be/d9FbO-LfSnE) ## self 를 통해서 같은 객체내에 있는 @Transactional 메서드를 호출하는 과정(트랜잭션 작동 : O) $$uml participant "사용자" as 사용자 participant "프록시" as 프록시 participant "실제객체 run2" as 실제객체_run2 participant "실제객체 run" as 실제객체_run participant "트랜잭션 매니저" as 트랜잭션_매니저 사용자 -> 프록시: run2() activate 프록시 프록시 --> 실제객체_run2: run2() activate 실제객체_run2 실제객체_run2 --> 프록시: self.run() activate 프록시 프록시 <--> 트랜잭션_매니저: transaction 시작 activate 트랜잭션_매니저 프록시 --> 실제객체_run: run() activate 실제객체_run 실제객체_run --> 프록시: run() 종료 deactivate 실제객체_run 프록시 <--> 트랜잭션_매니저: transaction 종료 deactivate 트랜잭션_매니저 프록시 --> 실제객체_run2: self.run() 종료. deactivate 프록시 실제객체_run2 --> 프록시: run2() 종료. deactivate 실제객체_run2 프록시 --> 사용자: run2() 종료. deactivate 프록시 $$ ## self 의 진정한 목적 - @Transactional 붙은 메서드를 내부적으로 호출해야하는 상황에서 이용하면 된다. # 29강 - [24 12 13, p 13888, 29강, JPA 는 우리에게 객체지향적인 방법으로 DB를 다룰 수 있게 해준다.](https://youtu.be/9sxGH49b5fM) ## 아래 2가지 경우 모드 JPA에서 가능합니다. ### JPA 예제 1 : 객체지향적인 코드 ```java 사람 a사람 = new 사람(); a사람.setName("홍길동"); a사람.add학력("서울초등학교", 2000); a사람.add학력("서울중학교", 2003); a사람.add학력("서울고등학교", 2006); a사람.add학력("서울대학교", 2010); class 사람 { @Setter private String name; // 이런 형태의 변수는 DB 테이블에 저장될 수 있다. @OneToMany(mappedBy = "사람", cascade = CascadeType.ALL) // 이 부분은 일단 무시하고 넘어가세요. private List<학력> 학력들 = new ArrayList<>(); // 이런 형태의 변수는 DB 테이블에 저장될 수 없지만 JPA 믿고 이렇게 써보세요. JPA 알아서 잘 처리합니다. public void add학력(String 학교명, int 졸업연도) { 학력 a학력 = new 학력(학교명, 졸업연도); this.학력들.add(a학력); } } @AllArgsConstructor class 학력 { private String 학교명; private int 졸업연도; } ``` ### JPA 예제 2 : DB지향적인 코드 ```java 사람 a사람 = new 사람(); a사람.setName("홍길동"); a학력Service.추가(a사람, "서울초등학교", 2000); a학력Service.추가(a사람, "서울중학교", 2003); a학력Service.추가(a사람, "서울고등학교", 2006); a학력Service.추가(a사람, "서울대학교", 2010); class 사람 { @Setter private String name; } @AllArgsConstructor class 학력 { private String 학교명; private int 졸업연도; } @Service class 학력Service { // ... } ``` # 30강 - [24 12 13, p 13888, 30강, 조금 더 객체지향적인 방법으로 댓글을 추가하도록 변경](https://youtu.be/abpsYp80nLY) - [커밋](https://github.com/jhs512/jpa-2024-12-11/commit/cdd7f61) # 31강 - [24 12 13, p 13888, 31강, OneToMany 를 통한 DB 작업은 해당 트랜잭션이 끝날 때 반영된다.](https://youtu.be/FzJDO5QOGgs) - [커밋](https://github.com/jhs512/jpa-2024-12-11/commit/cf2eebf) ## 주의사항 - postRepository.count(); 는 트랜잭션이 종료될 때 실행되지 않고 바로 실행된다. - postRepository.save(post); 는 트랜잭션이 종료될 때 실행되지 않고 바로 실행된다. - 나머지 작업들은 트랜잭션이 끝난 후 자동으로 DB에 반영된다. # 32강 - [24 12 13, p 13888, 32강, postRepository.save(post); 를 하는 순간 영속성 컨텍스트의 스냅샷이 생성된다.](https://youtu.be/GCqMMA_h9YI) - [커밋](https://github.com/jhs512/jpa-2024-12-11/commit/e424283) ## 스냅샷의 역할 - save 로 인해서 INSERT 가 발생하던 UPDATE 가 발생하던 스냅샷이 생성된다. - save 이후에 변경된 사항은 트랜잭션이 끝날 때 UPDATE 로 DB에 반영된다. - 여기서 스냅샷은 save 이후에 데이터가 변경되었는지 파악하기 위한 역할을 한다. - 스냅샷은 트랜잭션(영속성 컨텍스트)이 끝날 때 사라진다. # 33강 - [24 12 13, p 13888, 33강, @OneToMany 와 @ManyToOne 의 차이점, 1부](https://youtu.be/QqgIEGCTBqc) - [24 12 13, p 13888, 33강, @OneToMany 와 @ManyToOne 의 차이점, 2부](https://youtu.be/vACA9KvPoIs) ## @OneToMany 와 @ManyToOne 표 | 구분 | @OneToMany | @ManyToOne | |---|---|---| | 관계 | 일대다 관계의 일(One) 쪽 | 일대다 관계의 다(Many) 쪽 | | 예시 | 게시물과 댓글의 관계에서 게시물 | 게시물과 댓글의 관계에서 댓글 | | 특징 | 컬렉션(List, Set 등)으로 매핑 | 단일 객체로 매핑 | | 지연로딩 | 기본값 LAZY | 기본값 EAGER | | 외래키 | 반대쪽 테이블에 있음 | 자신의 테이블에 있음 | | 주인 | 연관관계의 주인이 될 수 없음 | 연관관계의 주인이 됨 | | 필수여부 | 선택 | 필수 | # 34강 - [24 12 13, p 13888, 34강, OneToMany 를 활용하면 관련된 데이터 SELECT 를 쉽게할 수 있다, 1부 : 작업](https://youtu.be/ADXrGjSYF5M) - [24 12 13, p 13888, 34강, OneToMany 를 활용하면 관련된 데이터 SELECT 를 쉽게할 수 있다, 2부 : 프록시 설명](https://youtu.be/PENg9vANueA) - [커밋](https://github.com/jhs512/jpa-2024-12-11/commit/c7f2dad) # 35강 - [24 12 13, p 13888, 35강, CascadeType.ALL 의 의미](https://youtu.be/rf0zaR5BLUs) ## 주의사항 - `@OneToMany(mappedBy = "post", cascade = CascadeType.ALL)` 위와 같이 했다고 가정할 때 - @OneToMany 필드를 소유하고 있는 Post 객체의 수정이 PostComment 로 전파되는 의미 - 즉, Post 객체의 수정이 PostComment 객체에 전파되는 의미 - 반대로 PostComment 객체의 수정이 Post 객체에 전파되는 의미는 아니다. ## PERSIST, MERGE, REMOVE, REFRESH, DETACH 차이 표 | 구분 | 설명 | 관련 SQL | |---|---|---| | PERSIST(중요) | 새로운 엔티티를 영속성 컨텍스트에 추가 | INSERT | | MERGE | 준영속/비영속 상태의 엔티티를 영속 상태로 변경 | - | | REMOVE(중요) | 엔티티를 영속성 컨텍스트와 DB에서 삭제 | DELETE | | REFRESH | DB의 데이터로 엔티티를 다시 조회하여 갱신 | - | | DETACH | 영속성 컨텍스트에서 엔티티를 분리(준영속 상태로 전환) | - | # 36강 - [24 12 13, p 13888, 36강, 부모가 이미 영속(PERSIST)상태 이고 자식들 중 비영속 상태가 있다면 해당 자식들을 생성(INSERT) 한다.](https://youtu.be/U7L8vS7l7DA) - [커밋](https://github.com/jhs512/jpa-2024-12-11/commit/583095e) ## CascadeType.PERSIST, CascadeType.REMOVE 의 의미 - CascadeType.ALL : PERSIST, MERGE, REMOVE, REFRESH, DETACH 모두 적용된다. - CascadeType.PERSIST : 부모가 생성(INSERT) 되 때 관련 자식들도 같이 생성(INSERT) 된다. - CascadeType.PERSIST : 부모가 이미 영속(PERSIST)상태 이고 자식들 중 비영속 상태가 있다면 해당 자식들을 생성(INSERT) 한다. - CascadeType.REMOVE : 부모가 삭제(DELETE)될 때 관련 자식들도 같이 삭제(DELETE) 된다. # 37강 - [24 12 13, p 13888, 37강, OneToMany 필드가 List 라면 추가(INSERT) 전에 SELECT 가 필요없다.](https://youtu.be/fjV3Wu3Y_fU) - [커밋](https://github.com/jhs512/jpa-2024-12-11/commit/3edd4c3) ## 요약 - 즉시 로딩(EAGER) 은 즉시 SELECT 쿼리가 발생한다. - 지연 로딩(LAZY) 은 필요할 때만 SELECT 쿼리가 발생한다. - PERSIST == 자식 엔티티들 INSERT : O - MERGE == 자식 엔티티들 UPDATE : X - 더티체킹 : 엔티티들 UPDATE : O ## 쿼리가 발생하는 티이밍 ```java @Transactional public void work3() { Post post1 = postService.findById(1).get(); // 즉시 SELECT 쿼리가 발생 post1.getComments().size(); // 즉시 SELECT 쿼리가 발생 post1.addComment("comment4"); // 위, 아래의 쿼리가 없다면 댓글들을 가져와서 comments 를 채우는 SELECT 없이 INSERT 쿼리만 발생, INSERT 쿼리는 트랜잭션이 종료되면 반영된다. 이 작업은 더티체킹이 아니라 PERSIST 에 의해서 이루어진다. PERSIST==INSERT, 더티체킹==UPDATE post1.getComments().get(2); // 이런경우에도 SELECT 쿼리가 발생 } ``` # 38강 - [24 12 13, p 13888, 38강, PERSIST == 자식 엔티티들 INSERT, 더티체킹 == 엔티티들 UPDATE](https://youtu.be/YTLk83nokEU) - [커밋](https://github.com/jhs512/jpa-2024-12-11/commit/f8444cd) ## 요약 - PERSIST == 자식 엔티티들 INSERT : O - MERGE == 자식 엔티티들 UPDATE : X - 더티체킹 : 엔티티들 UPDATE : O # 39강 - [24 12 13, p 13888, 39강, 외래키 제약이 있다면 글을 삭제할 때는 먼저 관련 댓글들 먼저 삭제해야 한다.](https://youtu.be/zFyG_fYYleg) - [커밋 : REMOVE 가 없어서 자식들이 먼저 삭제되지 않아서 외래키 제약에 의해 삭제 실패](https://github.com/jhs512/jpa-2024-12-11/commit/96b0ec7) - [커밋 : REMOVE 가 있으니 자식들이 먼저 삭제되어 외래키 제약에 위배되지 않아서 삭제 성공, 대신 관련 댓글들도 다 삭제된다.](https://github.com/jhs512/jpa-2024-12-11/commit/c82ab6f) ## JPA에 의해서 POST_COMMENT 테이블에 외래키 제약이 추가된다. - 옵션으로 외래키 제약을 끌 수도 있다. - 실무에서는 일부러 외래키 제약을 끄고 하는 경우도 많다. ```sql alter table if exists post_comment add constraint FKna4y825fdc5hw8aow65ijexm0 foreign key (post_id) references post ``` # 40강 - [24 12 13, p 13888, 40강, orphanRemoval = true 를 통해서 comments 리스트에서 제거된 객체를 DB 에서도 제거](https://youtu.be/kq7I7A8QkKA) - [커밋](https://github.com/jhs512/jpa-2024-12-11/commit/043c1dd) # 41강 - [24 12 13, p 13888, 41강, 지금 상황에 꼭 필요하지는 않지만, 스펙이 동일한 두 객체의 동등성을 체크를 위해서 equals, hashCode 를 재정의해야 한다.](https://youtu.be/2NlT9KH69Jc) - [커밋](https://github.com/jhs512/jpa-2024-12-11/commit/f44d7c0) ## equlas의 List에서의 요소삭제에서 사용된다. ```java package com.ll.jpa.domain.post.post.entity; // 생략 public class Post { // 생략 @Builder.Default @OneToMany(mappedBy = "post", cascade = {CascadeType.PERSIST, CascadeType.REMOVE}, orphanRemoval = true) private List comments = new ArrayList<>(); // 생략 public boolean removeComment(PostComment comment) { // 여기서 내부적으로 comments 안에 있는 comment 의 개수만큼 equals를 수행한다. // 하지만 우리는 PostComment 에서 equals를 재정의하지 않았다. // 따라서 Object 클래스에 정의된 equals를 사용하는데, 이는 각 리모콘이 서로 같은 객체를 가리키는 경우에만 true를 반환한다. // 따라서 아무리 동등한 스펙을 가진 2개의 객체라도 서로 다른 객체로 인정받는다. // 이 문제를 해결하기 위해서는 PostComment 에서 equals를 재정의해야 한다. // 그리고 자바의 규칙상 equals와 hashCode를 함께 재정의해야 한다. return comments.remove(comment); } } ``` ## equals 함수란 - 최상위 클래스(Object)에 정의되어 있다. - 두 객체가 동등한지 판단하는 함수이다. - 두 객체가 동등하다면 true, 아니면 false를 반환한다. - 기본적으로는 두 객체가 동일한 객체인지 판단한다. - 즉 스펙상으로 완벽히 동일한 두 객체의 경우라도 false를 반환한다. - 따라서 스펙상으로 완벽히 동일한 두 객체를 동등한 객체로 인정받고 싶다면 equals, hashCode 를 재정의해야 한다. ## hashCode 함수란 - 최상위 클래스(Object)에 정의되어 있다. - 객체의 해시코드(정수값)를 반환하는 함수이다. - 해시코드는 객체를 식별하는 정수값이다. - 기본적으로는 객체의 메모리 주소를 기반으로 해시코드를 생성한다. - 그래서 기본적으로는 스펙상으로 완벽히 동일한 두 객체의 경우라도 다른 해시코드를 반환한다. - equals() 메서드를 재정의한 클래스는 반드시 hashCode() 메서드도 재정의해야 한다. ## Set과 List의 차이 - Set은 중복을 허용하지 않고 순서가 없는 자료구조이다. - List는 중복을 허용하고 순서가 있는 자료구조이다. - Set은 equals()와 hashCode()를 사용하여 객체의 동등성을 판단한다. - List는 순서(인덱스)로 객체를 구분하므로 equals()와 hashCode()가 필수는 아니다. - Set은 HashSet, TreeSet 등이 있다. - List는 ArrayList, LinkedList 등이 있다. ## equals 함수가 있는데 hashCode 함수까지 필요한 이유 - equals 함수만으로는 Set, HashSet, HashMap 등의 해시 기반 컬렉션에서 객체를 올바르게 처리할 수 없다. - 해시 기반 컬렉션들은 객체를 저장할 때 해시코드를 사용한다. - 따라서 두 객체가 동등하다면 해시코드도 동일해야 한다. - 예를 들어 HashSet에 객체를 저장할 때: 1. 먼저 hashCode() 함수로 객체의 해시값을 구한다. 1. 이 해시값을 기준으로 객체를 저장할 버킷을 결정한다. 1. 같은 버킷에 있는 객체들끼리만 equals() 함수로 비교한다. - 만약 equals()만 재정의하고 hashCode()를 재정의하지 않으면: - 동등한 두 객체가 서로 다른 해시값을 가질 수 있다. - 그러면 서로 다른 버킷에 저장되어 중복 저장될 수 있다. - 이는 해시 기반 컬렉션의 의도된 동작이 아니다. ## 자바 동등성 예제 ### 동등하지만 equals, hashCode 를 재정의하지 않았다면 다른 객체로 인정받는다. ```java @AllArgsConstructor class Post { private Long id; private String title; } @Test void t1() { Post post1 = new Post(1L, "제목1"); Post post2 = new Post(1L, "제목1"); assertThat(post1).isEqualTo(post2); // 실패, 동등하지 않다고 판단 assertThat(post1.hashCode()).isEqualTo(post2.hashCode()); // 실패, 해시코드가 다르다. Set posts = new HashSet<>(); posts.add(post1); posts.add(post2); assertThat(posts.size()).isEqualTo(1); // 실패, 2개가 들어간다. } ``` ### 동등하고 equals, hashCode 를 재정의했다면 같은 객체로 인정받는다. ```java @EqualsAndHashCode @AllArgsConstructor class Post { private Long id; private String title; } @Test void t2() { Post post1 = new Post(1L, "제목1"); Post post2 = new Post(1L, "제목1"); assertThat(post1).isEqualTo(post2); // 성공, 동등하다고 판단 assertThat(post1.hashCode()).isEqualTo(post2.hashCode()); // 성공, 해시코드가 같다. Set posts = new HashSet<>(); posts.add(post1); posts.add(post2); assertThat(posts.size()).isEqualTo(1); // 성공, 1개만 들어간다. } ``` # 42강 - [24 12 13, p 13888, 42강, 롬복을 통해서 equals, hashCode 를 재정의하는 방법](https://youtu.be/ltDpaezX4p4) - [커밋](https://github.com/jhs512/jpa-2024-12-11/commit/9c0abcf) # 43강 - [24 12 13, p 13888, 43강, 언제 특정 도메인을 oneToMany 만으로 관리해도 될까?](https://youtu.be/w1aLqn56AqQ) ## 언제 특정 도메인을 oneToMany 만으로 관리해도 될까? - 개수가 적어야 한다. - 해당 앱이나 서비스에서 글에 댓글이 엄청나게 많다면 댓글 서비스과 댓글 리포지터리를 따로 두는게 좋다. - 서비스 초창기에는 OneToMany 로 관리를 해도 된다. - 추후에는 댓글 서비스와 댓글 리포지터리를 추가하되, 그때 꼭 OneToMany 를 삭제하지 않아도 된다. 즉 둘 다 사용해도 된다. - 종속되어 있어야 한다. - 댓글은 글에 종속되어 있다. - 반면에 글은 회원에게 종속되지 않는 별도의 객체이다. - 보통 회원이 탈퇴해도 그 사람이 쓴 글은 남아있다. - 물론 이게 되려면 JPA에서 회원과 글 사이에 외래키 제약을 없애야 한다. - 회원이 쓴 글을 삭제하지 않고 회원만 삭제할 수 있다. - 그래서 보통 회원이 OneToMany 로 글을 관리하지는 않는다. - 서로의 도메인이 다르기 때문에 # 44강 - [24 12 16, p 13888, 44강, 파일 DB는 2개 이상의 프로세스에서 동시에 접근할 수 없다.](https://youtu.be/o354z243k3Q) # 45강 - [24 12 16, p 13888, 45강, 기본적으로는 dev 모드, 테스트 시에는 test 모드가 되도록 설정, 작업](https://youtu.be/Y9TUE8SA6Nk) - [24 12 16, p 13888, 45강, 기본적으로는 dev 모드, 테스트 시에는 test 모드가 되도록 설정, 정리](https://youtu.be/x2ftEKiWmg0) - [커밋 - 작업 1](https://github.com/jhs512/jpa-2024-12-11/commit/dd05b18) - [커밋 - 작업 2](https://github.com/jhs512/jpa-2024-12-11/commit/410f6b0) ## 작업 1 - 기본 프로파일(모드)을 test 로 설정 - 그러면 설정파일 application.yml 이 먼저 읽히고 - 그 다음에 application-test.yml 이 읽힌다. - 이렇게 되면 인텔리제이에서 앱실행과 테스트케이스실행 둘 다 테스트 모드로 실행된다. ## 작업 2 - 기본 프로파일(모드)을 dev 로 설정 - 그러면 설정파일 application.yml 이 먼저 읽히고 - 그 다음에 application-dev.yml 이 읽힌다. - 이렇게 되면 인텔리제이에서 앱실행은 dev 모드로 실행되고 - 테스트케이스실행은 test 모드로 실행된다. - 왜냐하면 테스트 클래스에 `@ActiveProfiles("test")` 를 추가했기 때문이다. ## application-dev.yml 이 비어있는 이유 - application.yml 에 있는 설정이 기본적으로 개발용으로 맞춰져 있기 때문이다. - 이 부분은 개발자의 취향에 맞게 설정해주면 된다. - 어떤 개발자는 application.yml에 오직 공통설정만 넣고 application-dev.yml 에는 개발용 설정만 넣는다. # 46강 - [24 12 16, p 13888, 46강, PostServiceTest 에서 글 작성하는 테스트케이스 추가](https://youtu.be/OFtx3vsnioA) - [커밋](https://github.com/jhs512/jpa-2024-12-11/commit/0d0988b) # 47강 - [24 12 16, p 13888, 47강, @Transactional과 @Rollback을 추가하여 롤백 되도록, @Rollback은 생략가능](https://youtu.be/5wxShVn4JnM) - [커밋 - @Transactional과 @Rollback을 추가하여 롤백 되도록](https://github.com/jhs512/jpa-2024-12-11/commit/dfb46c9) - [커밋 - @Rollback(false)를 통해서 롤백 되지 않도록](https://github.com/jhs512/jpa-2024-12-11/commit/f7adb4b) - [커밋 - 테스트 환경에서는 @Rollback 생략가능](https://github.com/jhs512/jpa-2024-12-11/commit/2496722) # 48강 - [24 12 16, p 13888, 48강, findAll, findById, findByTitle 테스트](https://youtu.be/N2LRJDAaFyc) - [커밋](https://github.com/jhs512/jpa-2024-12-11/commit/0fdb630) ## findAll, findById, findByTitle 비교 | 메서드 | 자동생성 여부 | 반환타입 | 설명 | | --- | --- | --- | --- | | findAll | O | List | 모든 엔티티를 조회합니다. JpaRepository 인터페이스에서 기본 제공됩니다. | | findById | O | Optional | ID로 단일 엔티티를 조회합니다. JpaRepository 인터페이스에서 기본 제공됩니다. | | findByTitle | X | List | 제목으로 엔티티를 조회합니다. 개발자가 직접 추상 메서드를 리포지터리 인터페이스에서 정의해야 합니다. Spring Data JPA의 쿼리 메서드 작명 규칙을 따릅니다. | # 49강 - [24 12 16, p 13888, 49강, findByTitleAndContent, LIMIT](https://youtu.be/3AJhrS84qD8) - [커밋](https://github.com/jhs512/jpa-2024-12-11/commit/52dafd9) ## 추가된 테스트케이스 ```java @Test @DisplayName("findByTitleAndContent") // SELECT * FROM post WHERE title = 'title1' AND content = 'content1'; void t5() { Post post = postService.findByTitleAndContent("title1", "content1").get(0); assertEquals(1, post.getId()); } @Test @DisplayName("findByTitleLike") // SELECT * FROM post WHERE title LIKE '%2'; void t6() { List posts = postService.findByTitleLike("%2"); Post post = posts.get(0); assertEquals("title2", post.getTitle()); } @Test @DisplayName("findByTitleLikeOrderByIdDesc") // SELECT * FROM post WHERE title LIKE 'title%' ORDER BY id DESC; void t7() { List posts = postService.findByTitleLikeOrderByIdDesc("title%"); assertEquals(3, posts.size()); Post post = posts.get(0); assertEquals(3, post.getId()); assertEquals("title3", post.getTitle()); } @Test @DisplayName("findByOrderByIdDesc") // SELECT * FROM post ORDER BY id DESC; void t8() { List posts = postService.findByOrderByIdDesc(); assertEquals(3, posts.size()); Post post = posts.get(0); assertEquals(3, post.getId()); assertEquals("title3", post.getTitle()); } @Test @DisplayName("findTop2ByTitleLikeOrderByIdDesc") // SELECT * FROM post WHERE title LIKE 'title%' ORDER BY id DESC LIMIT 2; void t9() { List posts = postService.findTop2ByTitleLikeOrderByIdDesc("title%"); assertEquals(2, posts.size()); Post post = posts.get(0); assertEquals(3, post.getId()); assertEquals("title3", post.getTitle()); } @Test @DisplayName("findTop2ByOrderByIdDesc") // SELECT * FROM post WHERE ORDER BY id DESC LIMIT 2; void t10() { List posts = postService.findTop2ByOrderByIdDesc("title%"); assertEquals(2, posts.size()); Post post = posts.get(0); assertEquals(3, post.getId()); assertEquals("title3", post.getTitle()); } ``` # 50강 - [24 12 16, p 13888, 50강, Pageable(페이징 정보), Page(페이징 결과)를 도입하여 더욱 복잡한 SQL 수행](https://youtu.be/9nY6q77Lkm4) - [커밋](https://github.com/jhs512/jpa-2024-12-11/commit/b28afe7) ## 추가된 테스트케이스 ```java @Test @DisplayName("findAll(Pageable pageable)") // SELECT * FROM post ORDER BY id DESC LIMIT 2, 2; void t11() { int itemsPerPage = 2; // 한 페이지에 보여줄 아이템 수 int pageNumber = 2; // 현재 페이지 == 2 pageNumber--; // 1을 빼는 이유는 jpa는 페이지 번호를 0부터 시작하기 때문 Pageable pageable = PageRequest.of(pageNumber, itemsPerPage, Sort.by(Sort.Direction.DESC, "id")); Page postPage = postService.findAll(pageable); List posts = postPage.getContent(); assertEquals(1, posts.size()); // 글이 총 3개이고, 현재 페이지는 2이므로 1개만 보여야 함 Post post = posts.get(0); assertEquals(1, post.getId()); assertEquals("title1", post.getTitle()); assertEquals(3, postPage.getTotalElements()); // 전체 글 수 assertEquals(2, postPage.getTotalPages()); // 전체 페이지 수 assertEquals(1, postPage.getNumberOfElements()); // 현재 페이지에 노출된 글 수 assertEquals(pageNumber, postPage.getNumber()); // 현재 페이지 번호 } @Test @DisplayName("findByTitleLike(Pageable pageable)") // SELECT * FROM post WHERE title LIKE 'title%' ORDER BY id DESC LIMIT 2, 2; void t12() { int itemsPerPage = 2; // 한 페이지에 보여줄 아이템 수 int pageNumber = 2; // 현재 페이지 == 2 pageNumber--; // 1을 빼는 이유는 jpa는 페이지 번호를 0부터 시작하기 때문 Pageable pageable = PageRequest.of(pageNumber, itemsPerPage, Sort.by(Sort.Direction.DESC, "id")); Page postPage = postService.findByTitleLike("title%", pageable); List posts = postPage.getContent(); assertEquals(1, posts.size()); // 글이 총 3개이고, 현재 페이지는 2이므로 1개만 보여야 함 Post post = posts.get(0); assertEquals(1, post.getId()); assertEquals("title1", post.getTitle()); assertEquals(3, postPage.getTotalElements()); // 전체 글 수 assertEquals(2, postPage.getTotalPages()); // 전체 페이지 수 assertEquals(1, postPage.getNumberOfElements()); // 현재 페이지에 노출된 글 수 assertEquals(pageNumber, postPage.getNumber()); // 현재 페이지 번호 } @Test @DisplayName("findByTitleLike(Pageable pageable)") // SELECT * FROM post WHERE title LIKE 'title%' ORDER BY id DESC LIMIT 0, 10; void t13() { int itemsPerPage = 10; // 한 페이지에 보여줄 아이템 수 int pageNumber = 1; // 현재 페이지 == 2 pageNumber--; // 1을 빼는 이유는 jpa는 페이지 번호를 0부터 시작하기 때문 Pageable pageable = PageRequest.of(pageNumber, itemsPerPage, Sort.by(Sort.Direction.DESC, "id")); Page postPage = postService.findByTitleLike("title%", pageable); List posts = postPage.getContent(); assertEquals(3, posts.size()); // 글이 총 3개이고, 현재 페이지는 2이므로 1개만 보여야 함 Post post = posts.get(0); assertEquals(3, post.getId()); assertEquals("title3", post.getTitle()); assertEquals(3, postPage.getTotalElements()); // 전체 글 수 assertEquals(1, postPage.getTotalPages()); // 전체 페이지 수 assertEquals(3, postPage.getNumberOfElements()); // 현재 페이지에 노출된 글 수 assertEquals(pageNumber, postPage.getNumber()); // 현재 페이지 번호 } ``` # 51강 - [24 12 16, p 13888, 51강, 샘플 회원이 5명 생기도록](https://youtu.be/DpHtnyP_aIU) - [커밋](https://github.com/jhs512/jpa-2024-12-11/commit/6951d1f) - ![img](https://i.imgur.com/3E2K5lR.png) # 52강 - [24 12 16, p 13888, 52강, 글 쓰기, 댓글 쓰기에 작성자 추가](https://youtu.be/JZbpqdD_uhc) - [커밋](https://github.com/jhs512/jpa-2024-12-11/commit/4d3a8ce) # 53강 - [24 12 16, p 13888, 53강, 테스트 케이스에서 글 작성할 때도 작성자 추가](https://youtu.be/l2gvFSYFtaU) - [커밋](https://github.com/jhs512/jpa-2024-12-11/commit/31b313b) # 54강 - [24 12 16, p 13888, 54강, findByAuthorNickname, LEFT JOIN 발생](https://youtu.be/QtiYgtzBMzg) - [커밋](https://github.com/jhs512/jpa-2024-12-11/commit/f6df470) ## 실제 발생되는 SQL ```sql SELECT P.* FROM post AS P -- 글 LEFT JOIN member AS P_A -- 글 작성자 ON P_A.id = P.author_id WHERE P_A.nickname = '유저1'; ``` # 55강 - [24 12 16, p 13888, 55강, findByCommentsAuthorNickname, LEFT JOIN 발생](https://youtu.be/g6bQMJIPw3w) - [커밋](https://github.com/jhs512/jpa-2024-12-11/commit/8c99d36) ## 실제 발생되는 SQL - 참고로 중복되는 결과 2개가 나오지만 JPA가 알아서 중복을 제거해 준다. ```sql SELECT P.* FROM post AS P -- 글 LEFT JOIN post_comment PC -- 댓글 ON P.id = PC.post_id LEFT JOIN member AS PC_A -- 댓글 작성자 ON PC_A.id = PC.author_id WHERE PC_A.nickname = '유저3'; ``` # 56강 - [24 12 16, p 13888, 56강, BaseEntity 를 상속받아서 엔티티 클래스의 중복을 제거](https://youtu.be/-A7Nu0C4B8Q) - [커밋](https://github.com/jhs512/jpa-2024-12-11/commit/bd611e6) # 57강 - [24 12 16, p 13888, 57강, PostTag 추가, PostTag 에는 날자 필드가 없도록](https://youtu.be/s_n1BzVcP4k) - [커밋 : PostTag 추가](https://github.com/jhs512/jpa-2024-12-11/commit/de999c0) - [커밋 : BaseEntity 를 상속받아서 PostTag 에 날자 필드 제거](https://github.com/jhs512/jpa-2024-12-11/commit/21457cf) # 58강 - [24 12 17, p 13888, 58강, PostTag가 중복생성되지 않도록 처리](https://youtu.be/Z0v8H9p9E4E) - [커밋](https://github.com/jhs512/jpa-2024-12-11/commit/b4e70d8) ## 요약 - 직접 중복방지로직을 써서 자바수준에서 중복을 방지 - 참고로 강사는 59강, 60강 방식 보다 이 방식을 선호한다. - 이 방식이 더 간단하고 명확하다. - 이렇게 일단 진행 하다가 필요하다면 59강, 60강 방식으로 변경해도 된다. # 59강 - [24 12 17, p 13888, 59강, tags 를 Set 으로 변경, PostTag 에 equals, hashCode 재정의](https://youtu.be/6jJh_S8WIxU) - [커밋](https://github.com/jhs512/jpa-2024-12-11/commit/5bfe665) ## 요약 - Set 이라는 자료구조를 이용해서 자바수준에서 중복을 방지 - 중복방지로직을 제거할 수 있어서 좋다. - 다만 equals 와 hashCode 의 오버라이드가 필요 # 60강 - [24 12 17, p 13888, 60강, PostTag 에 id 필드 제거, @IdClass 추가하여 복합키 처리](https://youtu.be/UciiktNxaiA) - [커밋](https://github.com/jhs512/jpa-2024-12-11/commit/c00f66c) ## 요약 - POST_TAG 테이블에 id 필드를 없애고 복합키 도입 - 이제 DB 수준에서도 중복이 불가능 - 다만 복합키를 처리하는 코드가 추가되어 조금 더 복잡해진다. # 61강 - [24 12 17, p 13888, 61강, 테스트가 끝나면 영속성을 유지할 필요가 없으니 파일DB모드 보다 속도가 훨씬 더 빠른 메모리DB 모드로 변경](https://youtu.be/LOXVbwjrixM) - [커밋](https://github.com/jhs512/jpa-2024-12-11/commit/fa84274)

스프링부트, Spring Data JPA