📖 ORM

Object-relational mapping(객체 관계 매핑)
프로그래밍 언어의 객체와 관계형 데이터베이스의 데이터를 자동으로 매핑(연결)해주는 도구이다.

객체는 객체대로 설계하고 관계형 데이터베이스는 관계형 데이터베이스대로 설계.

---

📖 JPA

Java 진영에서 ORM(Object-Relational Mapping) 기술 표준으로 사용하는 인터페이스 모음으로 자바 어플리케이션에서 관계형 데이터베이스를 사용하는 방식을 정의한 인터페이스이다.

**사용 이유**

1. 반복적인 CRUD SQL을 처리해준다. -> 생산성
저장 : jpa.persist(member)
조회 : Member member = jpa.find(memberId)
수정 : member.setName("변경할 이름")
삭제 : jpa.remove(member)

2. 유지보수 => 기존에는 필드 변경 시 모든 SQL을 수정했지만 JPA는 필드만 추가하면 된다. 즉 SQL은 JPA가 처리해준다.

3. 상속, 연관관계, 객체 그래프 탐색, 비교하기 같은 패러다임 불일치 해결해준다.

JPA와 상속 - 저장
개발자의 일 -> jpa.persist(album);
JPA 처리 -> INSERT INTO ITEM, INSERT INTO ALBUM

JPA와 상속 - 조회
개발자의 일 -> Album album = jpa.find(Album.class, albumId);
JPA 처리
-> SELECT I., A.
FROM ITEM I
JOIN ALBUM A ON I.ITEM_ID = A.ITEM_ID

신뢰할 수 있는 엔티티, 계층

비교하기

String memberId = "100";
Member member1 = jpa.find(Member.class, memberId);
Member member2 = jpa.find(Member.class, memberId);

member1 == member2; //true

동일한 트랜잭션에서 조회한 엔티티는 같음을 보장한다.

JPA의 성능 최적화 기능

1. 1차 캐시와 동일성 보당
   같은 트랜잭션 안에서는 같은 엔티티를 반환한다.

2. 트랜잭션을 지원하는 쓰기 지연
   트랜잭션을 커밋할 때까지 INSERT SQL을 모울 수 있다.
   JDBC BATCH SQL 기능를 사용해서 한 번에 SQL 전송한다.

3. 지연 로딩
   지연로딩은 객체가 실제 사용될 때 로딩하는 것이고 즉시 로딩은 JOIN SQL로 한 번에 연관된 객체까지 미리 조회한다.

Hibernate는 JPA를 구현한 구현체.

---

📃 em.persist()

영속성 컨텍스트를 통해서 엔티티를 영속화 한다는 뜻이다. 객체를 저장한 상태가 됨.

📃 @Entity

JPA가 관리하는 객체고 DB 테이블과 매핑한다.
JPA를 사용해서 테이블과 매핑할 클래스는 필수로 써야한다.
(기본 생성자 필수)

📃 @Entity(name = "")

다른 패키지에 같은 이름의 클래스가 매핑이 되어있을 때 사용

📃 @Table

엔티티와 매핑할 테이블 지정
(name = "MBR") 일경우 "MBR" 이라는 테이블과 매핑한다. <테이블 명을 정해줌>

📃 @EqualsAndHashCode

📃 @NoArgsConstructor

파라미터가 없는 기본생성자를 만들어준다.

📃 @AllArgsContructor

모든 필드 값을 파라미터로 받는 생성자를 만들어줌.

📃 @RequiredArgsConstructor

final이나 @NonNull인 필드 값만 파라미터로 받는 생성자 만들어줌.

📃 @Id

데이터베이스 기본키(PK)와 매핑

📃 @Column

컬럼명으로 name = "" 라고 줄 수 있다.
unique는 @Table 에 있는 것이 더 좋음
ex)@Table(uniqueConstraints = "")

📃 insertable, updatable

등록, 변경 가능 여부 (true, false)

📃 nullable

null 값의 허용 여부를 설정
(false로 설정하면 DDL 생성 시에 not null 제약조건이 붙는다)

📃 columnDefinition

DB 컬럼 정보를 직접 줄 수 있다.
ex) columnDefinition = "varchar(100) default 'EMPTY'"

📃 length = 숫자

varchar(숫자)

📃 precision, scale

BigDecimal 타입에서 사용한다. (BigInteger 도 사용 가능)
precision은 소수점을 포함한 전체 자릿수를, scale은 소수 자릿수 (double, float 타입에는 적용되지 않는다.)
정밀한 소수를 다룰 때 사용

📃 @CreationTimestamp

📃 JpaRepository<MemberEntity, Long>

📃 @SpringBootTest

📃 @Transactional

📃 Transactional(readOnly = true)

읽기 전용으로 데이터 변경이 되지 않게 하기 위해 사용.
조회에서 자주 사용.

📃 @ManyToOne, @JoinColumn

연관관계 매핑.
ex) 회원이 어느 팀에 소속되어 있는지의 관계를 매핑

📃 IllegalArgumentException vs IllegalStateException

IllegalArgumentException
적절하지 않거나 유효하지 않은 데이터를 받았을 때 발생하는 예외 ex) 양수를 파라미터로 기대하고 있었는데 음수가 넘어옴.

IllegalStateException
적절하지 않거나 유효하지 않은 시간대에 메소드가 불러졌을 때 발생하는 예외 ex) 죽은 쓰레드로부터 불려지는 경우와 같이 메소드가 불려져서 안될 시기에 메소드가 호출될 때 발생
-> 메소드가 요구된 처리를 하기에 적합한 상태에 있지 않을 때 발생

📃 @Enumerated

Enum 타입을 매핑할 때 사용
중간에 다른 상태가 중간에 들어가면 숫자가 밀리게 되어 망하게 된다.
절대 @Enumerated(EnumType.ORDINARY) 사용하지 말자. 무조건 STRING으로

📃 @Temporal

날짜 타입을 매핑할 때 사용
ex)TemporalType.DATE -> 날짜, DB date 타입과 매핑 (2022-08-26)

TemporalType.TIMe -> 시간, DB time 타입과 매핑 (11:23:12)

TemporalType.TIMESTAMP -> 날짜와 시간, DB timestamp 타입과 매핑

📃 Lob

데이터베이스 BLOB, CLOB 타입과 매핑
@Lob에는 지정할 수 있는 속성이 없다.
매핑하는 필드 타입이 문자면 CLOB매핑, 나머지는 BLOB 매핑
CLOB: String, char[], java.sql.CLOB
BLOB: byte[], java.sql.BLOB

📃 Transient

필드 매핑하기 싫을 때 사용
DB에 저장 X, 조회 X
주로 메모리상에서만 임시로 어떤 값을 보관하고 싶을 때 사용
@Transient
private Integer temp;

위에 것들은 필드와 컬럼 매핑이었음.

📃 DB시퀀스

몇 가지 작동을 어떤 기준에 따라 공간적 또는 시간적으로 순서를 정해 놓는 것
즉 오라클에서 행을 구분하기 위해서 기본키를 두는데 기 기본 키는 중복된 값을 가질 수 있으므로 항상 유일한 값을 가져야 한다.
그런 기본 키가 유일한 값을 갖도록 사용자가 직접 생성해내는 것이 아니라 숫자를 자동으로 생성해주는 명령어를 의미한다.
(시작 값이 1부터 해서 증가하는 값 1로 진행된다.)

기본키 매핑

📃 @GeneratedValue

PK를 나타내기 위해 @Id 어노테이션을 사용하며, 생성 전략을 정의하기 위해 @GeneratedValue 를 사용
기본키를 자동으로 생성할 때에는 @Id와 @GenerratedValue 어노테이션이 함께 사용되어야 한다.

strategy = GenerationType.Identity
기본 키 생성을 DB에 위임
(DB가 알아서 해주도록)
IDENTITY 전략은 em.persist() 시점에 즉시 INSERT SQL 실행 하고 DB에서 식별자를 조회
왜냐하면 영속성은 엔티티의 식별값을 기준으로 엔티티를 구별하는데 키값이 필요하기 때문

strategy = GenerationType.SEQUENCE
데이터베이스 시퀀스를 사용하여 기본 키를 할당한다.
유일한 값을 순서대로 생성하는 특별한 데이터베이스 오브젝트 사용
Data를 DB에 Insert한 후 기본 키 값을 조회할 수 있다

테이블마다 따로 시퀀스를 관리하고 싶다면
@SequenceGenerator() 로 매핑한다.

strategy = GenerationType.AUTO
DB 방언에 따라 자동 지정

strategy = GenerationType.TABLE
키 생성 전용 테이블을 하나 만들어서 데이터베이스 시퀀스를 흉내내는 전략

📃 기본키 제약조건은 NULL이 아니고 유일하고 변하면 안되기 때문에 먼 미래까지 이 조건을 만족하는 자연키는 찾기 어려우므로 대리키를 사용하자.

📃 Long형 + 대체키 + 키 생성전략 사용

📃 commit

모든 작업을 정상적으로 처리하겠다고 확정하는 명령어
commit하면 하나의 트랜잭션 과정을 종료하게 된다.
Transaction 작업 내용을 실제 DB에 저장하고 이전 데이터가 완전히 UPDATE 된다.

📃 rollback

작업 중 문제가 발생했을 때, 트랜잭션의 처리 과정에서 발생한 변경 사항을 취소하고, 트랜잭션 과정을 종료시킨다.
Transaction 작업 내용을 취소하고 이전 commit한 곳까지만 복구한다.

연관관계 편의 메서드

한 번에 양방향 관계를 설정하는 메소드 > 양방향인 것을 간결하게 작성할 수 있다.
연관관계 편의 메서드의 위치는 핵심적으로 컨트롤 하는 쪽이 있는 것이 좋다.
ex) member와 order 가 양방향인데 원래는

public ~~(){
	Member member = new Member();
    Order order = new Order();
    
    member.getOrders().add(order);
    order.setMember(member);
}

이런 식으로 할 것을 다음과 같이 간결하게

public void setMember(Member member) {
        this.member = member;
        member.getOrders().add(this);
    }

@PersistenceContext

스프링이 생성한 EntityManager를 주입해준다.

@PersistenceContext
private EntityManager em;

@PersistenceUnit

EntityManagerFactory를 주입받고 싶다면

@PersistenceUnit
private EntityManagerFactory emf;

---

공부하던 도중 localhost:8082 입력을 했는데 h2database에 연결하지 못하는 상황이 발생.
이전에 했을 때는 잘 실행 됐는데....

그래서 intellij 에서 JPA Buddy 를 다시 restart 하고

<!-- H2 데이터베이스 -->
        <dependency>
            <groupId>com.h2database</groupId>
            <artifactId>h2</artifactId>
            <version>1.4.199</version>
        </dependency>

제대로 입력했는지 확인

그리고 실행해봤더니 연결 잘 됌......

---

📖 애플리케이션 개발

EntityManager : 엔티티를 관리하는 역할을 수행.
엔티티 매니저 내부에 영속성 컨텍스트(Persistence Context)**라는 걸 두어서 엔티티들을 관리

EntityManagerFactory : 엔티티 매니저(Entity Manager)를 만드는 공장

Persistence.xml은 JPA가 엑세스하려는 데이터베이스들에 대해 필요한 설정정보 들을 기술해둔 파일이다.

Member

@Entity //JPA가 관리할 객체
//@Table(name="user") //쿼리가 나갈 때 user라는 테이블에 insert하라고 하게 됨
public class Member {
    //PK가 뭔지 알려줌
    @Id
    private Long id;
    private String name;
    //생성자를 생성하면 에러가 나는 이유는 JPA는 기본적으로 내부적으로 reflection 이런 것들을
    //사용하기 때문에 동적으로 객체를 생성해야 한다.

    //그래서 기본생성자를 생성

    public Member() {}

    public Member(Long id, String name) {
        this.id = id;
        this.name = name;
    }

    public Long getId() {
        return id;
    }

    public void setId(Long id) {
        this.id = id;
    }

    public String getName() {
        return name;
    }

    public void setName(String name) {
        this.name = name;
    }
}

JpaMain

public class JpaMain {
    public static void main(String[] args) {
        EntityManagerFactory emf =
                Persistence.createEntityManagerFactory("hello"); //persistence.xml 에서 정해놓은 "hello"
        //EntityManagerFactory를 만드는 순간 데이터베이서와 연결도 다 되고 웬만한게 다 됨
        EntityManager em = emf.createEntityManager();
        //JPA 에서는 꼭 트랜잭션이라는 단위가 매우 중요하다.
        //데이터를 변경하는 모든 작업은 꼭 트랜잭션 안에서 작업을 해야한다.

        EntityTransaction tx = em.getTransaction();
        tx.begin();

        try{
            // 등록
            // Member member = new Member();
            // member.setId(2L);
            // member.setName("HelloB");

            // 조회하고 싶다면
            Member findMember = em.find(Member.class, 1L); //객체를 대신 저장해주는 것(자바 컬렉션처럼 생각)
            System.out.println("findMember.getId() = " + findMember.getId());
            System.out.println("findMember.getName() = " + findMember.getName());

            
            // 삭제
            // em.remove(findMember) // 찾은 얘를 넣어주면 된다.
            
            // 수정
            findMember.setName("HelloJPA");
            // 여기서 em.persist()로 저장하지 않아도 된다. -> JPA를 통해서 Entity를 가져오면 JPA가 관리를 해서 변경이 됐는지 안 됐는지 트랜잭션을 커밋하는 시점에 다 체크를 한다.
            // 그래서 바꼈다면 update 쿼리를 날린다.

            tx.commit();
        }catch(Exception e){
            tx.rollback(); //문제가 생기면 롤백
        }finally{
            em.close();
            //entityManager가 결국 데이터 커넥션을 물고 동작하기 때문에 꼭 닫는다.
        }
        emf.close();
    }
}

실행했더니 Exception in thread "main" org.hibernate.service.spi.ServiceException: Unable to create requested service [org.hibernate.engine.jdbc.env.spi.JdbcEnvironment]
Caused by: org.hibernate.boot.registry.classloading.spi.ClassLoadingException Unable to load class [org.h2.Driver]

Caused by: java.lang.ClassNotFoundException: Could not load requested class : org.h2.Driver

에러 발생
해결 ->
pom.xml 수정

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>
    <groupId>jpa-basic</groupId>
    <artifactId>ex1-hello-jpa</artifactId>
    <version>1.0.0</version>
    <dependencies>
        <!-- JPA 하이버네이트 -->
        <dependency>
            <groupId>org.hibernate</groupId>
            <artifactId>hibernate-entitymanager</artifactId>
            <version>5.3.10.Final</version>
        </dependency>
        <!-- H2 데이터베이스 -->
        <dependency>
            <groupId>com.h2database</groupId>
            <artifactId>h2</artifactId>
            <version>1.4.199</version>
        </dependency>

    </dependencies>
    <properties>
        <maven.compiler.source>11</maven.compiler.source>
        <maven.compiler.target>11</maven.compiler.target>
    </properties>
</project>

그리고 file -> project structure 선택하고 Project Settings -> Project에서 SDK 버전확인 (11로 변경함)
Modules 에서 Language Level을 11로 변경 (5로 되어있어서 Error:java: error: release version 5 not supported 에러가 발생함)
그래도 아직 해결 안됨.

H2 Database 와 연결을 하지 않은제 문제
그래서 숨겨진 아이콘 열어서 H2 DataBase 연결하면 H2 콘솔 창이 생긴다.
다 입력하고 연결 시험 했더니 데이터베이스 "C:/Users/park/jpashop"을 찾을 수 없습니다. 미리 만들거나 원격 데이터베이스 생성을 허용(보안 환경에서는 권장되지 않음) 이런 에러가 또 발생...... 다시 해결 방안 찾음

해결 완료
새로운 DataBase 를 생성할 때는 아이콘을 오른쪽 버튼 클릭해서 create new DataBase로 생성한다. 그러면
요런 창이 뜨는데 Database Path를 임의로 바꾸고 비밀번호는 아무거나 쳐도 상관없음.
그리고나서 다시 H2 콘솔로 가서 JDBC URL에 jdbc:h2:./jpashop 를 입력하고 비밀번호 입력하면 연결 완료됌.

여기도 수정

H2 콘솔은 해결 됐는데 또 Intellij에서 File corrupted while reading record 에러 발생
해결 -> Intellij 에서 jpashop.mv.db 와 jpashop.trace.db 삭제 후 다시 실행

자꾸 실행됐다 안됐다 하는게 불편했었다...... 이제 해결됐다... (너무 오래 걸렸다....)

멤버를 저장하는 방법
EntityManagerFactory를 Application 로딩 시점에 딱 하나만 만든다.
실제 DB에 저장하는 것은 트랜잭션 단위로 DB 커넥션을 얻어서 쿼리를 날리고 종료되는 일관적인 단위를 할 때마다 EntityManager라는 것을 만들어 줘야 한다.

💗 매우 중요

1) EntityManagerFactory는 하나만 생성해서 애플리케이션 전체에서 공유
2) EntityManager는 쓰레드간에 공유X(사용하고 버려야 한다.)
3) JPA의 모든 데이터 변경은 트랜잭션 안에서 실행해야 한다.

---

🪔 JPQL 간단 소개

JPQL로 전체 회원 검색하고 싶다면 try{} 에다가 코드 작성.

//JPQL로 전체 회원 검색하고 싶다면
List<Member> result = em.createQuery("select m from Member as m", Member.class)
         .getResultList();
//JPA는 절대 테이블을 대상으로 코드를 짜지 않는다. Member 객체를 대상으로 한다.

for (Member member : result) {
	System.out.println("member.getName() = " + member.getName());
}

JPA를 사용하면 엔티티 객체를 중심으로 개발하는데 문제는 검색 쿼리이다. 검색을 할 때도 테이블이 아닌 객체를 대상으로 검색을 해버린다.

• 모든 DB 데이터를 객체로 변환해서 검색하는 것은 불가능.

• 애플리케이션이 필요한 데이터만 DB에서 불러오려면 결국 검색 조건이 포함된 SQL이 필요.

JPQL

1. JPA는 SQL을 추상화한 JPQL이라는 객체 지향 쿼리 언어를 제공.
2. 엔티티 객체를 대상으로 쿼리.
3. SQL은 DB 테이블을 대상으로 쿼리.

public static void main(String[] args) {
	EntityManagerFactory emf =
	Persistence.createEntityManagerFactory("hello"); //persistence.xml 에서 정해놓은 "hello"

    EntityManager em = emf.createEntityManager();

    EntityTransaction tx = em.getTransaction();
    tx.begin();

    try{
    	Member member = new Member();
        member.setId(101L);
        member.setName("HelloJPA");
        //여기까지는 비영속

		//em.persist(member); //여기부터 영속상태가 됨, DB에 저장이 되지는 않음
		// EntityManager 안에 있는 영속성 컨텍스트라는 데를 통해서 member가 관리된다는 뜻

		System.out.println("BEFORE");
        em.persist(member);
        System.out.println("AFTER");
            //em.detach(member);
            //회원 엔티티를 영속성 컨텍스트에서 분리 (준영속 상태)

        //조회
        Member findMember1 = em.find(Member.class, 101L);
        Member findMember2 = em.find(Member.class, 101L);

		System.out.println("result = " + (findMember1 == findMember2));
            // 결과는 true가 나온다.
            //영속 엔티티의 동일성을 보장해주기 때문이다.
        tx.commit();
    }
    
    catch(Exception e){
        tx.rollback();
    }
    
    finally{
        em.close();
    }
    
    emf.close();

EntityManagerFactory emf =
     	Persistence.createEntityManagerFactory("hello"); //persistence.xml 에서 정해놓은 "hello"

        EntityManager em = emf.createEntityManager();

        EntityTransaction tx = em.getTransaction();
        tx.begin();

        try{
            Member member1 = new Member(150L, "A");
            Member member2 = new Member(151L, "B");

            em.persist(member1);
            em.persist(member2);
            //이 순간에 DB에 저장되는 것이 아니라 영속성 컨텍스트에 차곡차곡 엔티티와 쿼리가 쌓인다.
            tx.commit(); //여기 커밋을 하는 시점에 진짜 DB에 쿼리가 날라감
            System.out.println("===================");

            //버퍼링이라는 기능이 있다. 위처럼 쿼리를 DB에 날리면 최적화의 여지가 없다.
            //member1,2 가 쌓였는데 이것들을 DB에 한 번에 보낼 수 있다.
            //hibernate에 batch_size가 있는데 이것은 size 만큼 모아서 DB에 한 방에 네트워크로 쿼리 2개를 보내고 DB를 commit한다.
        }catch(Exception e){
            tx.rollback();
        }finally{
            em.close();
        }
        emf.close();

스냅샷: 향후 변경 감지를 위해서 원본을 복사해서 만들어두는 객체가 바로 스냅샷이다. 변경 감지가 일어났을 때 1차캐시에 있는 원본 객체가 중간에 변경되었는지 이 스냅샷으로 확인하게 된다.

try{
      //엔티티 수정
      /*Member member = em.find(Member.class, 150);
      member.setName("ZZZZZ");
      em.persist(member);  쓰지 않도록 한다.
      컬렉션에 넣은 것처럼 값을 꺼내고 변경했는데 다시 컬렉션에 넣을 필요가 없다.*/

      Member member = new Member(200L, "member200");
      em.persist(member);
      //멤버를 저장했는데 커밋되기 전까지는 쿼리를 볼 수가 없다.
      //미리 DB에 반영하고 싶다거나 쿼리를 미리 보고 싶다면
      
      em.flush(); //를 강제로 호출한다. flush 해도 1차 캐시는 지워지지 않음

      System.out.println("==============");
     //그러면 update 커리도 나온다.
 }
 catch(Exception e){
      tx.rollback();
 }
 finally{
     em.close();
}

emf.close();

---

📖 영속성 컨텍스트

● 엔티티를 영구 저장하는 환경이다.
● 애플리케이션과 데이터베이스 사이에서 객체를 보관하는 가상의 데이터베이스 같은 역할을 한다.
● 엔티티 매니저를 통해 엔티티를 저장하거나 조회하면 엔티티 매니저는 영속성 컨텍스트에 엔티티를 보관하고 관리한다

비영속(new/transient): 영속성 컨텍스트와 전혀 관계가 없는 상태 영속(managed): 영속성 컨텍스트에 저장된 상태 준영속(detached): 영속성 컨텍스트에 저장되었다가 분리된 상태 삭제(removed): 삭제된 상태

장점 : 1차 캐시, 동일성 보장, 트랜잭션을 지원하는 쓰기 지연, 변경 감지, 지연 로딩

1차 캐시
동일한 트랜잭션 내에서 한번 조회했던거 또 조회하면 DB에 쿼리 날라가지 않음

---

📖 플러시

flush() : 영속성 컨텍스트의 변경내용을 DB에 반영
flush 발생하면 변경을 감지하고 수정된 엔티티 쓰기 지연 SQL 저장소에 등록하고 쓰기 지연 SQL 저장소의 쿼리를 DB에 전송한다. (SQL 저장소에는 등록, 수정, 삭제 쿼리가 담겨있다.)
플러시는 영속성 컨텍스트를 비우는 것이 아니다.
컨텍스트의 변경 내용을 DB에 동기화한다고 이해.
트랜잭션이라는 작업 단위가 중요 -> 커밋 직전에만 동기화
어떻게든 커밋 직전에만 변경 내용을 DB에 날려주면 된다.

em.persist(member)
이거 할 때 실제로 DB에 쿼리가 날라가지는 않는다.
즉 영속성 상태가 된다고 해서 바로 DB에 쿼리가 날라가는 것은 아니다. 트랜잭션을 커밋하는 시점에 영속성 컨텍스트에 있는 쿼리가 DB로 날라간다.

---

📖 준영속 상태

em.find() 로 member2를 조회했는데 1차 캐시에 없다면 DB에서 가져와서 1차 캐시에 올린다. 이 때 올라간 상태가 영속 상태이다.

준영속 상태는 영속 상태의 엔티티가 영속성 컨텍스트에서 분리되는 것이다. 그러면 영속성 컨텍스트가 제공하는 기능을 사용하지 못한다.

EntityManagerFactory emf = Persistence.createEntityManagerFactory("hello"); //persistence.xml 에서 정해놓은 "hello"

    EntityManager em = emf.createEntityManager();

    EntityTransaction tx = em.getTransaction();
    tx.begin();

    try{
    	Member member = em.find(Member.class, 150L);
        member.setName("AAAA");
            //조회했더니 150L이 없으므로 영속성 컨텍스트에 150L을 올린다. 그리고 값을 "AAAA"로 변경

            //더 이상 영속성 관리를 하기 싫다면
        em.detach(member); //분리 -> JPA에서 더 이상 관리를 하지 않음
            //그러면 트랜잭션 commit할 때 아무 일도 일어나지 않음
    }
    catch(Exception e){
       tx.rollback();
    }
    finally{
       em.close();
    }
emf.close();

em.detach(entity)
특정 엔티티만 준영속 상태로 전환

em.clear()
영속성 컨텍스트를 통째로 지워버림 (초기화)

em.close()
영속성 컨텍스트를 종료

FlushModeType.AUTO
커밋이나 쿼리를 실행할 때 플러시한다.
(AUTO 만 사용한다고 이해)

---

📖 변경 감지(더티 체킹)

데이터를 수정해서 Transaction에서 커밋하면 JPA가 변경분에 대해서 찾아서 자동으로 update 쿼리를 생성해서 데이터베이스에 반영한다.
JPA의 엔티티를 바꿀 수 있다.

🏷️ 준영속 엔티티

영속성 컨텍스트가 더는 관리하지 않는 엔티티

@PostMapping("items/{itemId}/edit")
//파라미터로 넘어온 준영속 상태의 엔티티.
public String updateItem(@PathVariable Long itemId, @ModelAttribute("form") BookForm form) {
    Book book = new Book();
    book.setId(form.getId()); //form을 book으로 바꿈
    book.setName(form.getName());
    book.setPrice(form.getPrice());
    book.setStockQuantity(form.getStockQuantity());
    book.setAuthor(form.getAuthor());
    book.setIsbn(form.getIsbn());

	//어설프게 엔티티를 파라미터로 안 쓰고 정확하게 필요한 데이터만 받음
	itemService.saveItem(book);
	return "redirect:items";
}

여기서 객체는 새로운 객체지만 Id가 세팅되어있으므로 뭔가 JPA에 들어갔다 나온 것이라는 의미이다. 그래서 DB에 정확히 갔다 온 상태(한 번 저장된 상태)로 식별자가 DB에 있으면 준영속 상태의 객체라 한다.

• new 로 Book 새로운 객체를 생성하기는 했지만 JPA에서 Id 기반으로 생각을 해보면
  이미 DB에 한번 저장되고 불러온 것이다.
• 따라서 준영속 엔티티라고 보는 것이 맞다.
  Book이 준영속 엔티티 (이미 DB에 한번 저장돼서 식별자가 존재하면 준영속 엔티티라 볼 수 있다.)
• 위 예시처럼 그냥 new로 직접 만든 것은 기본적으로 JPA가 관리하지 않는다. 그래서 아무리 바꿔치기 해도 DB에 업데이트가 되지 않는다.

영속성 엔티티는 JPA가 관리해서 변경감지가 일어난다. 준영속 상태의 엔티티는 JPA가 관리하지 않는다.
💧 그래서 준영속 상태 엔티티지만 변경 감지 기능을 사용하거나 병합(merge)을 사용할 수 있다.

//준영속성 상태 Book을 변경 감지
@Transactional
public void updateItem(Long itemId, Book param){
    //itemId를 기반으로 실제 DB에 있는 영속성 엔티티를 찾아옴
    Item findItem = itemRepository.findOne(itemId);
    findItem.setPrice(param.getPrice());
    findItem.setName(param.getName());
    findItem.setStockQuantity(param.getStockQuantity());
    //save 호출도 필요없음. persist 호출도 필요없음
    // 이 라인이 끝나면 스프링의 트랜잭션에 의해서 트랜잭션이 커밋된다.
}

findItem은 영속 상태이다.
값을 세팅한 다음에는 스프링의 @Transactional에 의해 커밋된다.
커밋되면 JPA는 flush를 한다. 영속성 컨텍스트에 있는 엔티티 중에서 변경된 것들을 다 찾는다.
바뀌었다면 바뀐 것에 대해서 update 쿼리를 DB에 날려서 update한다.

---

📓 merge

준영속 상태의 엔티틸를 영속 상태로 변경할 때 사용하는 기능이다.

• 영속성 컨텍스트에서 findItemId로 찾은 Id로 DB를 뒤져서 Item을 찾고 파라미터item 값으로 찾아온 값들을 전부 바꿔치기 한다.
• 그래서 트랜잭션 커밋될 때 반영이 된다.

public void save(Item item) {
  if (item.getId() == null) { //item은 JPA에 데이터 저장 전까지 Id가 없다.
      em.persist(item);
  }//그래서 JPA가 제공하는 persist를 사용

  else{ //이미 DB에 등록돼서 가져온 것
      em.merge(item);
  }
}

🏷️ 동작 방식

1. merge() 실행
2. 파라미터로 넘어온 준영속 엔티티의 식별자 값으로 1차 캐시에서 엔티티를 조회
   -> 없으면 DB에서 엔티티를 조회하고 1차 캐시에 저장
3. 조회한 영속성 엔티티에 파라미터로 넘어온 준영속 상태 엔티티의 값을 채워 놓는다. 즉 준영속 상태 엔티티의 모든 값을 조회한 영속성 엔티티에 밀어넣는다.
4. 영속 상태인 엔티티를 반환한다.

// Merge
@Transactional
public Item updateItem(Long itemId, Book param){
    //itemId를 기반으로 실제 DB에 있는 영속성 엔티티를 찾아옴
    Item findItem = itemRepository.findOne(itemId);
    findItem.setPrice(param.getPrice());
    findItem.setName(param.getName());
    findItem.setStockQuantity(param.getStockQuantity());
    
    return findItem;
}

merge 주의점

변경 감지 기능을 사용하면 원하는 속성만 선택해서 변경할 수 있지만, 병합을 사용하면 모든 속성이 변경된다 . 병합 시 값이 없으면 null로 업데이트 할 위험도 있다. (병합은 모든 필드를 교체하기 때문.)

ex) 가격이 한번 책정되면 바꿀 수 없다고 가정하면 book.setPrice(form.getPrice) 없이 update를 하는데 이대로 Merge를 호출해버리면 DB에 Price는 NULL로 업데이트 되버린다. (매우 위험.)

---

✏️ 결론 - 엔티티를 변경할 때는 항상 변경 감지 사용

● 컨트롤러에서 어설프게 엔티티 생성 금지
● 트랜잭션이 있는 서비스 계층에 식별자와 변경할 데이터를 명확하게 전달. 파라미터나 Dto로
● 트랜잭션이 있는 서비스 계층에서 영속 상태의 엔티티를 조회하고, 엔티티의 데이터를 직접 변경
● 트랜잭션 커밋 시점에 변경 감지가 실행된다.

파라미터로 변경할 데이터 명확하게 전달
ItemService.class

@Transactional
public void updateItem(Long itemId, String name, int price, int stockQuantity){
    //itemId를 기반으로 실제 DB에 있는 영속성 엔티티를 찾아옴
    Item findItem = itemRepository.findOne(itemId);
    findItem.setName(name);
    findItem.setPrice(price);
    findItem.setStockQuantity(stockQuantity);
}

ItemController.class

@PostMapping("item/{itemId}/edit")
public String updateItem(@PathVariable Long itemId, @ModelAttribute("form") BookForm form) {


    //itemService에서 파라미터로 필요한 값들만을 가져옴
    itemService.updateItem(itemId, form.getName(), form.getPrice(), form.getStockQuantity());

    //itemService.saveItem(book);
    return "redirect:items";
}

Dto로 변경할 데이터 명확하게 전달

import lombok.Getter;
import lombok.Setter;

@Getter
@Setter
public class UpdateItemDto {
    private String Name;
    private int price;
    private int stockQuantity;
}

ItemService.class

@Transactional
public void updateItem2(Long itemId, UpdateItemDto itemDto){
    //itemId를 기반으로 실제 DB에 있는 영속성 엔티티를 찾아옴
    Item findItem = itemRepository.findOne(itemId);
    findItem.setName(itemDto.getName());
    findItem.setPrice(itemDto.getPrice());
    findItem.setStockQuantity(itemDto.getStockQuantity());
}

⭕ 업데이트는 단발성으로 set으로 하면 좋지 않다.

addStock이나 change처럼 의미있는 메서드를 만들어야지 set을 막 깔면 좋지 않다. 변경 지점이 엔티티로 다 가기 때문에 set으로 하면 추적이 어렵다.

@Transactional
public void updateItem2(Long itemId, UpdateItemDto itemDto){
    //itemId를 기반으로 실제 DB에 있는 영속성 엔티티를 찾아옴
    Item findItem = itemRepository.findOne(itemId);
    //findItem.setName(itemDto.getName());
    //findItem.setPrice(itemDto.getPrice());
    
    // 이런식으로 해야 어디서 바뀌는지 추적이 쉬움
    findItem.change(price, name, stockQuantity);
}

addStock의 경우 Item 엔티티에서 관리하는 stockQuantity를 변경하는 비즈니스로직을 엔티티에서 처리하자.
서비스 단에서 처리할 수 있지만, 엔티티에서 처리하는 것이 응집도가 높은 설계로 볼 수 있다.

ItemController.class

//파라미터가 아닌 Dto로 변경할 데이터를 명확하게 전달.
@PostMapping("item/{itemId}/edit")
public String updateItem2(@PathVariable Long itemId, UpdateItemDto itemDto) {
    itemService.updateItem2(itemId, itemDto);

    return "redirect:items";
}

---

📖 데이터베이스 스키마 자동 생성

hibernate.hdm2ddl.auto (persistence.xml)에 있음

create : 기존 테이블 삭제 후 다시 생성 (DROP + CREATE)

create-drop : create와 같으나 종료시점에 테이블 DROP

update : 변경분만 반영 (운영 DB에는 사용 안됌) 그리고 지우는 건 안되고 추가만 가능

validate : 엔티티와 테이블이 정상 매핑되었는지만 확인

none : 사용하지 않음

주의점
1) 운영 장비에는 절대 create, create-drop, update 사용 불가
2) 개발 초기 단계는 create or update
3) 테스트 서버는 update or validate
4) 스테이징과 운영 서버는 validate or none

테스트 서버, 운영 서버는 가급적 쓰지 말기 (쓰게 되면 조심해서)

기본키 매핑 잘 이해가 가지 않는다.
나중에 다시 온다.

em.persist 하고나면 항상 id의 값이 들어감, 영속성 상태가 되면 무조건 PK가 세팅되고 영속성이 된다.

Team

public class Team {
    @Id
    @GeneratedValue
    @Column(name = "TEAM_ID")
    private Long id;
    private String name;

    public Long getId() {
        return id;
    }

    public void setId(Long id) {
        this.id = id;
    }

    public String getName() {
        return name;
    }

    public void setName(String name) {
        this.name = name;
    }
}

Member

@Id @GeneratedValue
@Column(name = "MEMBER_ID")
private Long id;

@Column(name = "USERNAME")
private String username;

//@Column(name = "TEAM_ID")
//private Long teamId;

@ManyToOne//일대다 라는 관계로 Member 입장에서 Many, Team 입장에서 One을 줘야 한다.
@JoinColumn(name = "TEAM_ID") //team 이랑 Member 테이블의 FK와 매핑을 해야한다.
private Team team; //에러 생기는 이유는 JPA 에게 둘의 관계가 일대다 인지 다대다인지 이런걸 알려줘야 한다.

public Long getId() {
    return id;
}

public void setId(Long id) {
    this.id = id;
}

public String getUsername() {
    return username;
}

public void setUsername(String username) {
    this.username = username;
}

public Team getTeam() {
	return team;
}

public void setTeam(Team team) {
	this.team = team;
}

---

✏️ 단방향 관계

JpaMain

EntityManagerFactory emf = Persistence.createEntityManagerFactory("hello"); //persistence.xml 에서 정해놓은 "hello"
//EntityManagerFactory를 만드는 순간 데이터베이서와 연결도 다 되고 웬만한게 다 됨

EntityManager em = emf.createEntityManager();
//JPA 에서는 꼭 트랜잭션이라는 단위가 매우 중요하다.
//데이터를 변경하는 모든 작업은 꼭 트랜잭션 안에서 작업을 해야한다.

EntityTransaction tx = em.getTransaction();
tx.begin();
        
try{
	//저장하는 코드
	Team team = new Team();
	team.setName("Team A");
    em.persist(team);

    Member member = new Member();
    member.setUsername("member1");
    member.setTeam(team);
    em.persist(member);

    //영속성 컨텍스트가 아닌 DB에서 가져온 쿼리를 보고싶다면
    em.flush();//flush 해서 영속성 컨텍스트에 있는 걸 DB로 쿼리 날려버려서 싱크 맞추고
    em.clear();//이걸로 영속성을 초기화 시켜버린다.

    //조회일 때
    Member findMember = em.find(Member.class, member.getId());

    Team findTeam = findMember.getTeam();
    System.out.println("findTeam = " + findTeam.getName());

    tx.commit();
}
catch(Exception e){
	tx.rollback(); //문제가 생기면 롤백
}

finally{
	em.close();
    //entityManager가 결국 데이터 커넥션을 물고 동작하기 때문에 꼭 닫는다.
}
emf.close();

getTeamId() 이런 식으로 가져오는 것이 아니라 getTeam() 으로 가져와서 좀 더 객체 지향적으로 가져올 수 있다.
좀 더 이해 필요

팀 이름을 바꾸고 싶다면 DB에 100번 이라는 팀이 있다는 가정 하에
Team newTeam = em.find(Team.class, 100L);
findMember.setTeam(newTeam);
이렇게만 해주면 된다.
setTeam 하면 DB의 외래키 값이 업데이트 된다.

---

✏️ 양방향 관계

@OneToMany(mappedBy = "team") //mappedBy는 지금 일대다 매핑에서 team이랑 연결이 되어있다고 알려주는 것이다.
private List<Member> members = new ArrayList<>();

try{
	Team team = new Team();
	team.setName("Team A");
    em.persist(team);

    Member member = new Member();
    member.setUsername("member1");
    member.setTeam(team);
    em.persist(member);

     //영속성 컨텍스트가 아닌 DB에서 가져온 쿼리를 보고싶다면
     em.flush();//flush 해서 영속성 컨텍스트에 있는 걸 DB로 쿼리 날려버려서 싱크 맞추고
     em.clear();//이걸로 영속성을 초기화 시켜버린다.

     //조회일 때
     Member findMember = em.find(Member.class, member.getId());

     List<Member> members = findMember.getTeam().getMembers();

     for (Member m : members) {
     	System.out.println("m = " + m.getUsername());
     }

     tx.commit();
}
     
catch(Exception e){
	tx.rollback(); //문제가 생기면 롤백
}

finally{
	em.close();
    //entityManager가 결국 데이터 커넥션을 물고 동작하기 때문에 꼭 닫는다.
}
emf.close();

mappedBy

mappedBy는 지금 일대다 매핑에서 team이랑 연결이 되어있다고 알려주는 것이다.

여기서 JoinColumn() 해서 하는 방법이랑 뭐가 차이인지 알기가 어렵다.

양방향 관계부터 알아본다.
객체 연관관계 = 2개로 회원 -> 팀 연관관계 , 팀 -> 회원 연관관계
테이블 연관관계 = 1개로 회원 <-> 팀 연관관계

그런데 양방향 관계라는 것보다 단방향 관계 2개가 있다고 이해하자.
그래서 객체를 양방향으로 참조하려면 단방향 연관관계를 2개 만들어야 한다.

테이블은 외래키 하나로 두 테이블의 연관관계를 관리한다.

---

📖 연관관계 주인

Member의 team 을 업데이트 할지 Team의 List members를 업데이트 할지 결정을 해서 외래키를 업데이트해야 한다. (둘 중 하나로 외래키를 관리해야 한다.)
객체의 두 관계 중 하나를 연관관계의 주인으로 지정한다.
연관관계의 주인만이 외래키를 관리한다.(등록, 수정)
주인이 아닌 쪽은 읽기만 가능하다.
주인은 mappedBy 속성 사용 불가
주인이 아니면 mappedBy 속성으로 주인 지정.
@JoinColumn을 쓰는 쪽의 클래스가 연관관계의 주인이다.

외래키가 있는 곳을 주인으로 정해야 한다.

외래키가 있는 쪽이 항상 n 이고 없는 쪽이 1이다. 그래서 n 쪽이 연관관계 주인이다.
(n 쪽이 @ManyToOne)

결론 ->

위 코드에서 연관관계 주인은 Member 객체에 team 이다.
Team의 List<Member> members 는 객체 관점에서 양방향 연관관계를 구현 하기 위해 추가된 것이다.

주인에게 매핑된 members는 특성상 데이터가 등록, 수정, 삭제 되더라도 DB에 반영이 되지는 않는다.
Member에 team을 변경하면 DB에 반영은 된다.
당연히 팀이 바뀌었으므로 Team 내 members에서 특정 member를 지워주어야 하지만 DB관점에서는 굳이 지워주지 않아도 된다.

왜냐하면 이미 Member가 team을 변경하기만 해도 Member 테이블의 team fk가 변경되었기 때문이다.
Team의 members는 연관관계 주인이 아니기 때문에 members에서 특정 member를 지워도 데이터베이스에는 반영되지 않는다. 결론적으로 객체 관점에서는 팀을 변경한 멤버를 팀 객체의 멤버 목록에서 지워주는 게 맞지만 보통 변경된 데이터를 즉시 사용하는 경우는 드물기에 지워주는 로직을 추가하지 않았다고 보면 된다.

주의 -> 양방향 연관 세팅 시에는 양쪽 모두 값을 세팅 해주어야 한다.

Team team = new Team();
team.setName("Team A");

//team.getMembers().add(member); 주인이 아닌 뱡향 (역방향)만 연관관계 설정
em.persist(team);

Member member = new Member();
member.setUsername("member1");
member.setTeam(team);
em.persist(member);

team.getMembers().add(member); //양쪽 모두 값을 세팅해줌
  
Member findMember = em.find(Member.class, member.getId());
List<Member> members = findMember.getTeam().getMembers();

for (Member m : members) {
	System.out.println("m = " + m.getUsername());
}

tx.commit();

Team team = new Team();
team.setName("Team A");
            //team.getMembers().add(member); 주인이 아닌 뱡향 (역방향)만 연관관계 설정
em.persist(team);

Member member = new Member();
member.setUsername("member1");
member.changeTeam(team);
em.persist(member);
  
Member findMember = em.find(Member.class, member.getId());
List<Member> members = findMember.getTeam().getMembers();

for (Member m : members) {
	System.out.println("m = " + m.getUsername());
}

tx.commit();

Member

public void setTeam(Team team) {
	this.team = team;
    team.getMembers().add(this); //this는 Member 나 자신
}

이렇게도 가능

member.changeTeam(team) //을 주석처리하고 (Member.class 에서도 changeTeam() 주석처리) 
team.addMember(member); //member를 기준으로 팀을 짤지 팀을 기준으로 멤버를 넣을지 결정
  
public void addMember(Member member) {
	member.setTeam(this);
    members.add(member);
} 
//Team.class 에 이거 추가

양방향 매핑 시에도 무한 루프 조심하자.
ex) toString(), lombok, JSON 생성 라이브러리

단방향 매핑만으로도 이미 연관관계 매핑이 완료된다.

양방향 매핑은 반대 방향으로 조회 기능이 추가된 것 분이다.

---

✏️ 연관관계 매핑 시 고려사항 3가지

다중성, 단방향/양방향, 연관관계 주인

실행해보면 Update 쿼리가 추가로 나간다. 이유는
setName("teamA") 부분은 TEAM 테이블에 그냥 넣으면 되서 바로 수정이 된다.
team.getMembers().add(member); 부분에서 team 엔티티를 저장하는데 MEMBER 테이블에 외래키 TEAM_ID를 어떻게 할 방법이 없어 옆 테이블에서 가서 UPDATE를 치는 것이다. 그래서 쿼리가 한번 더 나간다.
그러므로 일대다 관계를 권장하지 않는다. (다대일 권장)
엔티티가 관리하는 외래키가 다른 테이블에 있고 연관관계 관리를 위해 추가로 UPDATE SQL이 실행된다.

JPA에서 상속이라는 관계를 해결할 수 있다. (3가지)
*** class Item은 추상 클래스로 만들어야 한다.

---

✏️ 조인 전략

@Inheritance(strategy = InheritanceType.JOINED)

JOINED 방식은 ALBUM, MOVIE, BOOK 테이블이 Item의 PK를 외래키로 갖는 방식이다.

@DiscriminatorColumn
부모 클래스에 선언하고 부모 클래스에 구분 컬럼을 지정. 하위 클래스를 구분하는 용도로 쓰인다. DTYPE이 무엇인지 알려준다.
명확하게 어느 클래스에 조인했는지 알기 위해서 넣어주자.

@DiscriminatorValue("")
하위 클래스에 선언한다. 엔티티 저장 시 구분 컬럼에 입력할 값을 지정.
"A" 라 하면 부모 클래스에 DTYPE이 A 로 저장된다.

🏷️ 싱글(단일) 테이블 전략

@Inheritance(strategy = InheritanceType.SINGLE_TABLE)

부모 클래스에 자식 테이블의 속성들을 모두 때려박음
ALBUM, MOVIE, BOOK 테이블은 생성되지 않음
굳이 @DiscriminatorColumn 하지 않아도 DTYPE이 들어가있음
-> 하나의 테이블에 다 들어가 있기 때문에 DTYPE이 뭔지 알 수가 없다. 그래서 필수로, 자동으로 생성이 된다.

JpaMain에서 Movie movie에 의해서 데이터 생성하고 persist 하면 쿼리가 한 번만 나간다.
조회도 조인할 필요없이 쿼리가 심플하게 나간다.

구현 클래스마다 테이블 전략

@Inheritance(strategy = InheritanceType.TABLE_PER_CLASS)

Item 테이블이 없다. -> ALBUM, MOVIE, BOOK 테이블만 있다.
거의 쓰지 않음....

상속관계 매핑
관계형 데이터베이스는 상속 관계X
슈퍼타입 서브타입 관계라는 모델링 기법이 객체 상속과 유사
상속관계 매핑 : 객체의 상속과 구조와 DB의 슈퍼타입 서브타입 관계를 매핑

관계형 데이터베이스

슈퍼타입, 서브타입

@MappedSuperclass
다른 클래스에 있는 속성을 같이 쓰고 싶을 때 사용.
즉 공통적으로 사용할 속성에 사용.

상속관계 매핑아니고 엔티티도 아니고 테이블과 매핑하지도 않는다.
상속받는 자식 클래스에 매핑 정보만 제공한다.
직접 생성해서 사용할 일이 없으므로 추상 클래스 권장

---

✏️ 프록시

Member findMember = em.getReference(Member.class, member.getId());
System.out.println("findMember = " + findMember.getClass());

데이터베이스 조회를 미루는 가짜(프록시) 엔티티 객체를 조회한다.

em.find()는 진짜 객체를 조회.
실제 클래스를 상속 받아서 만들어지고 실제 크래스와 겉모양이 같다. (텅 비어있음)

사용하는 입장에서는 진짜 객체인지 프록시 객체인지 구분하지 않고 사용하면 된다.(이론상)

프록시 객체는 실제 객체의 참조를 보관하고 있어 프록시 객체를 호출하면 실제 객체의 메소드를 호출하게 된다.

💎 프록시 객체의 초기화

member.getName() 호출할 때 MemberProxy에 member target의 값이 처음에는 없다. 그러면 JPA가 영속성 컨텍스트에 진짜 멤버 객체를 가져오라는 요청을 한다.

그러면 영속성 컨텍스트가 DB를 조회해서 실제 엔티티 객체를 생성해서 Member에게 준다. 그리고 MemberProxy에 target에 연결시켜준다.
-> 결국 영속성 컨텍스트를 통해서 초기화를 요청하는 것이다. (DB를 통해서 진짜 값을 가지고 와서 진짜 엔티티를 만들어내는 과정!! 이 초기화.)

💎 프록시 특징 (중요!!)

1. 프록시 객체는 처음 사용할 때 한 번만 초기화가 된다. -> 한 번 초기화되면 그걸 계속 사용해야 함.

2. 프록시 객체를 초기화할 때, 프록시 객체가 실제 엔티티로 바뀌는 것은 아니다. 초기화되면 프록시 객체를 통해서 실제 엔티티에 접근 가능한 것이다. -> 객체가 다른 것으로 교체되는 것이 아니고 Proxy 유지, 내부의 target만 값이 채워지는 것이다.

3. 프록시 객체는 원본 엔티티를 상속받는다. 따라서 타입 체크 시 주의해야 한다. -> JPA 에서 내가 Proxy를 쓸지 안 쓸지 모르기 때문에, entity에 대해서 비교할 때는 == 비교 말고 instance of를 사용하자.

Member member1 = new Member();
member1.setUsername("member1");
em.persist(member1);

em.flush();
em.clear();

Member m1 = em.find(Member.class, member1.getId());

System.out.println("m1.getClass() = " + m1.getClass()); //실제 객체

Member reference = em.getReference(Member.class, member1.getId());

System.out.println("reference = " + reference.getClass());
//출력이 두 개 모두 같다고 나옴
//이미 Member를 영속성 컨텍스트에 올렸는데(1차 캐시에 있음) 프록시로 가져와봐야 의미가 없음.

System.out.println("a == a : " + (m1 == reference));

이유 -> 한 영속성 컨텍스트에서 가져왔으면 JPA는 항상 true를 반환한다.

4. 영속성 컨텍스트에 찾는 엔티티가 이미 있으면 em.getReference()를 호출해도 실제 엔티티를 반환한다.

Member refMember = em.getReference(Member.class, member1.getId());
System.out.println("ref = " + refMember.getClass()); //프록시로 나옴

Member findMember = em.find(Member.class, member1.getId());
System.out.println("find = " + findMember.getClass()); //이미 프록시가 되버려서 find해도 프록시가 나온다.
            
System.out.println("ref == find : " + (refMember == findMember));

em.find() 해도 프록시가 나올 수 있다.
중요한 것은 프록시든 아니든 문제 없게 개발하는 것
어떻게든 true가 되도록 맞추면 된다

🏷️ 실무에서 많이 만남

영속성 컨텍스트의 도움을 받을 수 없는 준영속 상태일 때, 프록시를 초기화하면 문제가 발생한다. -> could not initialize proxy (No Session)

Member refMember = em.getReference(Member.class, member1.getId());
System.out.println("ref = " + refMember.getClass()); //프록시로 나옴

em.close(); //그런데 영속성 컨텍스트를 꺼버리면 또는 em.detach(refMember)로 끄집어낼 경우
// em.clear() -> 영속성 컨텍스트 깨끗하게 지움.

refMember.getUsername(); //DB에 쿼리 나가면서 프록시 객체가 초기화 됨

//초기화 요청은 영속성 컨텍스트를 통해서 일어난다.
//close로 영속성을 관리하지 않게 되어 could not initialize proxy 에러가 발생한다.
//즉 영속성 컨텍스트가 없다는 의미(em.clear() 해도 같음)

더이상 refMember는 영속성 컨텍스트의 도움을 못 줌.
트랜잭션 시작하고 끝날 때 영속성 컨텍스트도 시작하고 끝나도록 맞추는데 트랜잭션 끝나고나서 프록시 조회해 보면 no session 하고 에러가 나온다. -> 요거 내용 기억!!!

💎 프록시 확인

프록시 인스턴스의 초기화 여부 확인
getPersistenceUnitUtil().isLoaded(ObjectEntity)

Member refMemebr = em.getReference(Member.class, member1.getId());
System.out.println("refMmeber = " + refMember.getClass()); // Proxy

refMember.getUsername(); // 프록시 초기화 해줌. -> 강제 초기화
System.out.println(emf.getPersistenceUnitUtil().isLoaded(ObjectEntity));

이러면 true가 출력된다.

프록시 클래스 확인 방법
entity.getClass().getName() 출력

🏷️ 지연 로딩 LAZY를 사용해서 프록시로 조회

@ManyToOne(fetch = FetchType.LAZY)
@JoinColumn
private Team team;

team을 프록시 객체로 조회 -> member 클래스 만 DB에서 조회한다는 의미.
이 경우 Member를 거의 쓰고 Team은 거의 쓰지 않는 경우에 유용하다.
그런데 Member와 Team을 같이 쓴다면 LAZY 처럼 Member, Team 쿼리가 2번씩 나가는 건 성능이 효율적이지 않다.

-> 즉시 로딩 Eager 를 사용해서 함께 조회한다.

가급적 지연 로딩만 사용(특히 실무에서)
즉시 로딩을 적용하면 예상하지 못한 SQL이 발생
즉시 로딩은 JPQL에서 N+1 문제를 일으킨다.

@ManyToOne, @OneToOne 은 기본이 즉시 로딩 -> LAZY로 설정
@OneToMany, @ManyToMany(안 쓰지만) 는 기본이 지연 로딩 (LAZY) 설정 필요x

---

✏️ 영속성 전이: CASCADE

영속성 전이는 영속 상태로 만들 때 연관된 엔티티도 함께 영속 상태로 만들고 싶을 때 사용하는 것이다.
부모를 저장할 때 자식도 같이 저장하고 싶을 때 사용, 연관관계나 지연/즉시 로딩과는 아무 관계가 없다.
-> 부모를 저장할 때 연관된 자식도 함께 다 persist로 호출하고 싶을 때 쓴다. (그저 편리함만 제공할 뿐)

정확한 개념은 특정 엔티티를 영속 상태로 만들 때, 연관된 엔티티도 함께 영속 상태로 만들고 싶을 때 사용한다. child 들의 parent 가 하나일 때만 사용한다.

간단하게 persist를 할 때

em.persist(parent);
em.persist(child1);
em.persist(child2);

를 하지 않고 cascade = CascadeType.ALL 을 쓰면 em.persist(parent); 만 써도 자동으로 child1,2 가 모두 persist 된다.

cascade = CascadeType.ALL : 모두 적용
cascade = CascadeType.PERSIST : 영속 (딱 저장할 때만 라이프 사이클 맞추고 나머지는 위험하니 따로 두고 싶을 때)
cascade = CascadeType.REMOVE : 삭제

📣 언제 사용하냐

게시판과 파일 테이블이 있을 때 첨부파일 경로가 있을 경우는 상관없지만 파일을 여러 군데에서 관리하거나 다른 엔티티에서 관리하는 경우에는 사용하면 안된다.
예를 들어 Parent라는 엔티티만 child를 관리하거나 연관한게 있으면 상관없지만 child가 다른 엔티티와 관계가 있는 경우에는 사용하면 안 된다.
Parent라는 엔티티만 child를 소유할 때 사용하고 다른 데서 child를 소유하는 경우에는 사용 X.

---

✏️ 고아 객체 orphanRemoval = true

고아 객체 제거-> 부모 엔티티와 연관이 끊어진 자식 엔티티를 자동으로 삭제.
참조가 제거된 엔티티는 다른 곳에서 참조하지 않는 고아 객체로 보고 삭제하는 기능.
참조하는 곳이 하나이고 특정 엔티티가 개인 소유할 때(부모가 하나.) 사용한다.

@OneToOne, @OneToMany 에서만 사용 가능!!.

특정 엔티티가 개인 소유할 때만 사용.

🏷️ 영속성 전이 + 고아 객체 모두 킬 경우

CascadeType.ALL + orphanRemoval = true
두 옵션을 모두 활성화하면 부모 엔티티를 통해서 자식의 생명주기를 관리할 수 있다.

🏷️ cascade, orphanRemoval 명확한 차이

1. orphanRemoval=true는 관계가 끊어진 child를 자동으로 제거한다.
2. CascadeType.REMOVE는 관계가 끊어진 child를 자동 제거하지 않는다. 관계가 끊어졌다는 것을 제거로 보지 않기 때문이다
   🔗 https://tecoble.techcourse.co.kr/post/2021-08-15-jpa-cascadetype-remove-vs-orphanremoval-true/

💎 참고
부모를 제거하면 자식은 고아가 된다. 따라서 객체 제거 기능을 활성화하면 부모를 제거할 때 자식도 함께 제거가 된다. CascadeType.REMOVE처럼 동작함


부모 엔티티에서 자식 엔티티 제거
CascadeType.REMOVE는 자식 엔티티가 그대로 남아있는 반면, orphanRemoval = true는 자식 엔티티를 제거한다.

✏️ 임베디드 타입(복합 값 타입), 값 타입 컬렉션이 중요

● 기본값 타입 -> String, int, ...
생명주기를 엔티티의 의존
ex) 회원을 삭제하면 이름, 나이 필드도 함께 삭제됨

값 타입은 공유하면 X
ex) 회원 이름 변경 시 다른 회원의 이름도 함께 변경되면 안됨.

● 임베디드 타입(복합 값 타입)
새로운 값 타입을 직접 정의할 수 있음
JPA는 임베디드 타입이라 함
int, String과 같은 값 타입 (엔티티 타입이 아님)

• 기본 생성자 필수
• 임베디드 타입은 엔티티의 값일 뿐이다.
• 임베디드 타입을 사용하기 전과 후에 매핑하는 테이블은 같다.
• 객체와 테이블을 아주 세밀하게(find-grained) 매핑하는 것이 가능
• 잘 설계한 ORM 애플리케이션은 매핑한 테이블의 수보다 클래스의 수가 더 많음

@Embeddable : 값 타입을 정의하는 곳에 표시
@Embedded : 값 타입을 사용하는 곳에 표시

사용 이유

private String city;
private String street;
private String zipcode;

●Address 클래스에 3개의 데이터를 1개의 주소라는 의미의 객체로 표현한다면 훨씬 더 가독성있고 객체 지향적인 코드로 만들 수 있다.

🏷️ AttributeOverride 한 엔티티에서 같은 값 타입을 사용할 때

컬럼명이 중복됨

@Embedded
private Address homeAddress;

//주소
@Embedded
@AttributeOverrides({
@AttributeOverride(name = "city", column = @Column(name = "WORK_CITY")),
            @AttributeOverride(name = "street",
                    column = @Column(name = "WORK_STREET")),
            @AttributeOverride(name = "zipcode",
                    column = @Column(name = "WORK_ZIPCODE")),
    })

private Address WorkAddress; //이렇게 쓰면 중복이 일어나 에러가 발생 -> AttributeOverride 사용

임베디드 타입값이 null이면 매핑한 컬럼값은 모두 null

✏️ 값 타입과 불변 객체

값 타입은 복잡한 객체 세상을 조금이라도 단순화하려고 만든 개념이다.

Address address = new Address("city", "street", "100012");

Member member = new Member();
member.setUsername("member1");
member.setHomeAddress(address);
em.persist(member);

Member member2 = new Member();
member.setUsername("member2");
member.setHomeAddress(address);
em.persist(member2);

member.getHomeAddress().setCity("newCity");

값 타입 공유 참조는 임베디드 타입 같은 값 타입을 여러 엔티티에서 공유하면 부작용이 발생한다. -> 같이 공유해서 사용하고 싶다면 엔티티 값 타입 사용, 아니면 대신 값(인스턴스)를 복사해서 사용.

Address address = new Address("city", "street", "1000");

member1 ~~
member2 ~~

member.getHomeAddress().setCity("newCity");

이렇게 있으면 update 쿼리가 2번 나가서 member1, 2 둘 다 newcity로 수정된다.
이런 걸 사이드 이펙트라고 하는데 이 버그는 진짜 잡기가 어렵다.
그래서 address가 있으면 new address 라는 것을 복사해서 만들어 써야 한다.

Address address = new Address("city", "street", "100012");

Member member = new Member();
member.setUsername("member1");

member.setHomeAddress(address);
em.persist(member);

//이렇게 복사
Address copyAddress = new Address(address.getCity(), address.getStreet(), address.getZipcode());

Member member2 = new Member();
member.setUsername("member2");

member.setHomeAddress(copyAddress);
em.persist(member2);

//첫 번째만 newCity가 되고 두 번째는 city가 된다.
member.getHomeAddress().setCity("newCity"); 

항상 값을 복사해서 사용하면 공유 참조로 인해 발생하는 부작용을 피할 수 있지만 임베디드 타입처럼 직접 정의한 값 타입은 자바의 기본 타입이 아니라 객체 타입이다.

객체 타입은 참조 값을 직접 대입하는 것을 막을 방법이 없다.
객체의 공유 참조는 피할 수 없다.

즉 기본 타입은 값을 복사하지만 객체 타입은 참조(주소 값)를 전달한다. 그래서 객체 둘 다 가 모두 바뀐다.

그래서 객체 타입을 수정할 수 없게 만든다.

---

💟 불변 객체란

생성 시점 이후 절대 값을 변경할 수 없는 객체로 값 타입은 불변 객체로 설계해야한다.
생성자로만 값을 설정하고 수정자(Setter)를 만들지 않으면 된다. (아니면 Setter를 public이 아닌 private 으로 생성해도 됨)

// 수정하고 싶다면
Address newAddress = new Address("New City", address.getStreet(), address.getZipcode());
member.setHomeAddress(newAddress);

값 타입은 깔끔하게 그냥 모두 불변으로 만든다고 생각하자

---

✏️ JPQL

객체 지향 쿼리 언어이다. 테이블이 아닌 엔티티 객체를 대상으로 쿼리한다.
SQL을 추상화해서 특정데이터베이스 SQL에 의존하지 않는다.
결국 SQL로 변환된다.

JPQL 문법 잘 알면 QueryDSL(실무 사용 권장) 잘 사용할 수 있다.
JPA 사용하면서 JDBC 커넥션을 직접 사용하거나 스프링 JdbcTemplate, Mybatis 등을 함께 사용 가능.
● 단 영속성 커텍스트를 적절한 시점에 강제로 flush() 필요.

Member member = new Member();
member.setUsername("member1");
m.persist(member);
  
//flush는 commit 될 때와 query 가 날라갈 때 flush 된다.
em.flush();
dbconn.executeQuery("select ~"); //flush 하지 않으면 DB에 아무것도 없는 상태라 결과가 0이 된다.

🏷️ flush

● 영속성 컨텍스트의 변경 내용을 DB에 반영하는 것이다.
● Transaction commit이 일어날 때 flush가 동작하는데 이 때 쓰기 지연 저장소에 쌓아 놨던 INSERT, UPDATE, DELETE SQL들이 DB에 날라간다.
영속성 컨텍스트가 비워지는 것이 아님

em.persist(member) 할 때는 member 객체가 영속성 컨텍스트에 있고 DB에는 아직 날라가지 않은 상태이다. 그래서 강제로 em.flush()를 해준다.

---

✏️ 값 타입 컬렉션

값 타입을 하나 이상 저장할 때 사용
@ElementCollection, @CollectionTable 사용
데이터베이스는 컬렉션을 같은 테이블에 저장할 수 없다.
->컬렉션들은 일대다 개념이기 때문에 DB안에 컬렉션을 한 테이블에 넣을 방법이 없다.

그래서 일대다의 별도의 테이블을 만들어 내야 한다.
컬렉션을 저장하기 위한 별도의 테이블이 필요함.

Set과 List처럼 컬렉션을 관계형 DB에는 기본적으로 테이블 안에 컬렉션을 담을 수 있는 구조가 없다. 그냥 Value로 값만 가능.
그래서 별도의 테이블을 뽑아야 한다.

예를 들면 addressHistory로 List가 있다고 한다면 ADDRESS 테이블을 따로 뽑아서 Member_id, CITY, STREET, ZIPCODE 컬럼을 만들어야 한다.
favoriteFoods : Set<String>
addressHistory : List<Address>

@ElementCollection
@CollectionTable(name = "FAVORITE_FOOD", joinColumns = @JoinColumn(name = "MEMBER_ID"))
@Column(name = "FOOD_NAME") // 값이 String으로 하나고 Address 처럼 내가 정의한 것이 아니기 때문에 예외적으로 이름 설정 가능.
private Set<String> favoriteFoods = new HashSet<>();

@ElementCollection
@CollectionTable(name = "ADDRESS", joinColumns = @JoinColumn(name = "MEMBER_ID"))
private Set<Adress> addressHistory = new ArrayList<>();

@ElementCollection
해당 필드가 컬렉션 객체임을 JPA에게 알려주는 어노테이션
값 타입 컬렉션을 매핑할 때 사용한다.

● 연관된 부모 Entity 하나에만 연관되어 관리된다. (부모 Entity와 독립적으로 사용이 불가능)
● 항상 부모와 함께 저장되고 삭제되므로 cascade 옵션은 제공X
● 부모 Entity Id와 추가 컬럼(basic or 임베디드)으로 구성됨
● 기본적으로 식별자 개념이 없으므로 컬렉션 값 변경 시, 전체 삭제 후 새로 추가해야한다.

@CollectionTable
값 타입 컬렉션을 매핑할 테이블에 대한 정보를 지정하는 역할을 수행합니다.

값 타입들은 별도로 persist하거나 업데이트 할 게 없다. member에서 값을 바꾸면 자동으로 업데이트 된다.
값 타입 컬렉션은 영속성 전이(Cascade) + 고아 객체 제거 기능을 필수로 가진다고 볼 수 있다
컬렉션들은 지연 로딩이다.
엔티티와 다르게 식별자 개념이 없고 값은 변경하면 추적이 어렵다.

값 타입 컬렉션에 변경 사항이 발생하면, 주인 엔티티와 연관된 모든 데이터를 삭제하고, 값 타입 컬렉션에 있는 현재 값을 모두 다시 저장한다.
값 타입 컬렉션을 매핑하는 테이블은 모든 컬럼을 묶어서 기본 키를 구성해야 한다.
● null 입력도 불가능하고 주옥 저장도 불가능하다.

String을 수정할 때는 별 다른 방법 없이 컬렉션을 사용하는 방법으로 수정.

findMember.getFavoriteFoods().remove("치킨");
findMember.getFavoriteFoods().add("한식");

address의 경우는 Address로 제너릭이기 때문에 불변 객체 할 때처럼 하면 된다.

findMember.getFavoriteFoods().remove(new Address("old_1", "street", "1234"));
findMember.getFavoriteFoods().add(new Address("newCity1", "street", "1234"));

remove() 자체가 기본적으로 equals로 동작하기 때문에 기존에 있는 요소를 찾기 위해서는 equals()를 동작해 객체의 올바른 비교가 필요하다.
(hashcode 필요)

🏷️ 대안

● 실무에서는 상황에 따라 값 타입 컬렉션 대신에 일대다 관계를 고려

● 일대다 관계를 위한 엔티티를 만들고, 여기에서 값 타입을 사용.
일대다로 수정 시 update 쿼리가 나가는 건 어쩔 수 없음
->일대다 단방향 매핑의 경우 다른 테이블에 외래키가 있어 update 쿼리가 나감.

● 진짜 단순한 거 때 값 타입 사용하고 나머지는 그냥 일대다 관계로 엔티티 만든다. (추적할 필요도 없고 update(값이 바뀜) 도 필요없을 때)
예를 들면 셀렉트 박스처럼.

● 영속성 전이 + 고아 객체 제거를 사용해서 값 타입 컬렉션처럼 사용.

AddressEntity를 하나 더 생성

@Entity
@Table(name = "ADDRESS")
public class AddressEntity{
	@Id @GeneratedValue
    private Long id;
    
    private Address address; // 값 타입 컬렉션
    
    public AddressEntity(){}
    
    public AddressEntity(Address address){
    	this.address = address;
    }
    
    public AddressEntity(String city, String street, String zipcode){
    	this.address = new Address(city, street, zipcode);
	}
}

Member.class

@OneToMany(casecade = CascadeType.AlLL, orphanRemoval = true)
@JoinColumn(name = "MEMBER_ID")
private List<AddressEntity> addressHistory = new ArrayList<>();

@OneToMany, @ManyToOne 으로 기본 매핑해서 풀어도 되고 일대다 단방향 매핑으로 해도 된다.

---

✏️ JPQL 문법

select m from **Member** as m where m.**age** > 18
(엔티티 Member 와 속성 age는 대소문자 구분)
테이블 이름이 아닌 엔티티 이름 사용
별칭(as m) 은 필수다. as는 생략 가능

Member member = new Member();
member.setUsername("member1");
member.setAge(10);
em.persist(member);

TypedQuery<Member> query = em.createQuery("select m from Member m", Member.class);

//반환 타입이 명확할 때는 TypedQuery를 사용한다.
/*List<Member> resultList = query.getResultList(); //컬렉션이 반환됨.

for (Member member1 : resultList) {
	System.out.println("member1 = " + member1);
}*/

Member singleResult = query.getSingleResult();
System.out.println("singleResult = " + singleResult);

query.getResultList()
결과가 2개 이상일 때 리스트 반환 , 결과가 없으면 빈 리스트 반환(nullPointerException 걱정 없음)

query.getSingleResult()
결과가 정확하게 한 개 나와야 한다.
결과가 없으면 : javax.persistence.NoResultException

결과가 둘 이상이면 : javax.persistence.NonUniqueResultException 발생

/*TypedQuery<Member> query = em.createQuery("select m from Member m where m.username = :username", Member.class);
query.setParameter("username", "member1");*/

//반환 타입이 명확할 때는 TypedQuery를 사용한다.

//Member singleResult = query.getSingleResult();

//System.out.println("singleResult = " + singleResult.getUsername());

//위 처럼 쓰지 않고 밑에 처럼 간단하게 사용함
Member result = em.createQuery("select m from Member m where m.username = :username", Member.class)
	.setParameter("username", "member1")
    .getSingleResult(); //이름 기준 파라미터 바인딩

위치 기준 바인딩은 되도록 쓰지 않는 것이 좋음 (순서 바뀔 수 있음)

---

✏️ 프로젝션

SELECT 절에 조회할 대상을 지정하는 것
SELECT m FROM Member m -> 엔티티 프로젝션
SELECT m.team FROM Member m -> 엔티티 프로젝션 (명시적으로 join 넣어주는 것이 좋음)

SELECT m.address FROM Member m -> 임베디드 타입 프로젝션
SELECT m.username, m.age FROM Member m -> 스칼라 타입 프로젝션

DISTINCT로 중복 제거

🏷️ 프로젝션 여러 값 조회

1. Query 타입으로 조회
2. Object[] 타입으로 조회
3. new 명령어로 조회
   ● 단순 값을 DTO로 바로 조회

List<MemberDTO> result = em.createQuery("select new jpql.MemberDTO(m.username, m.age) from Member m", MemberDTO.class)
                    .getResultList
  
MemberDTO memberDTO = result.get(0);
System.out.println("memberDTO = " + memberDTO.getUsername());
System.out.println("memberDTO = " + memberDTO.getAge());

●패키지 명을 포함한 전체 클래스명 입력
●순서와 타입이 일치하는 생성자 필요

✏️ 페이징 API

List<Member> result = em.createQuery("select m from Member m order by m.age desc", Member.class)
		.setFirstResult(1)
    	.setMaxResults(10)
    	.getResultList();

.setFirstResult(1)
조회 시작 위치 (0부터 시작)

.setMaxResults(10)
조회할 데이터 수

위 2개만 챙겨서 넣어주면 ?에 추상적으로 생각했던 값을 알아서 다 넣어준다.
->우리는 인덱스, 몇 개 가져올지 이런 것만 신경쓰면 됨.

---

✏️ JOIN: 한 데이터베이스 내의 여러 테이블의 레코드를 조합하여 하나의 열로 표현한 것이다.

내부 조인: SELECT ~~ [INNER] JOIN m.team t
외부 조인: SELECT ~~ LEFT [OUTER] JOIN m.team t

내부 조인과 외부 조인 차이
내부는 키 값이 있는 테이블의 칼럼 값을 비교해서 맞는 값을 가져오는 것이다.
한 마디로 서로 관련된 내용을 검색해 가져오는 방법이라 생각
외부는 여러 테이블 중 한 테이블에만 데이터가 있고 다른 쪽에는 없는 경우, 데이터가 있는 테이블의 내용을 전부 출력하는 방법이다.

---

✏️ 조인 - ON절

1. 조인할 때 미리 대상을 필터링
2. 연관관계 없는 엔티티 외부 조인

String query = "select m from Member m left join Team t on m.username = t.name";

🏷️ 서브 쿼리

WHERE, HAVING 절에서만 서브 쿼리 사용 가능
SELECT 절도 가능
FROM 절의 서브 쿼리는 현재 JPQL에서 불가능
-> 조인으로 풀 수 있으면 풀어서 해결하도록

//패키지 명까지 넣어야 함. -> ADMIN 타입의 유저만 조회함
String query = "select m.username, 'HELLO', true From Member m " +
                    "where m.type = jpql.MemberType.USER"; 


List<Member> result = em.createQuery(query)
                    .getResultList();

🏷️ CASE 식

String query = "select " + 
	"case when m.age <= 10 then '학생요금' " +
    "when m.age >= 60 then '경로요금' " +
    "else '일반요금' " +
    "end " +
    "from Member m";

List<String> result = em.createQuery(query, String.class)
	.getResultList();

coalesce : 하나씩 조회해서 null이 아니면 반환

String query = "select coalesce(m.username, '이름 없는 회원') as username " + 
	"from Member m ";

List<String> result = em.createQuery(query, String.class)
	.getResultList();
// 결과는 s = 이름 없는 회원

nullif: 두 값이 같으면 null반환, 다르면 첫 번째 값 반환

String query = "select nullif(m.username, '관리자') as username " +
	"from Member m ";

List<String> result = em.createQuery(query, String.class)
	.getResultList();
//s = null

---

✏️ JPQL 기본 함수

• CONCAT
  • 문자 더해줌
• SUBSTRING
  • ~부터 ~까지 문자열 뽑아냄
• TRIM
  • 공백 제거
• LOWER, UPPER
  • 대소문자
• LENGTH
  문자열길이
• LOCATE
  • 위치 찾아줌 -> locate('de', 'abcdegf')
  • s = 4가 나옴
• ABS, SQRT, MOD
  • 절대값, ,
• SIZE
  • size는 컬렉션 크기를 구함.
    한 줄로 출력

---

✏️ 경로 표현식

.(점)을 찍어 객체 그래프를 탐색하는 것
select m.username -> 상태 필드
from Member m join m.team t -> 단일 값 연관 필드
m.orders o -> 컬렉션 값 연관 필드

필드 3가지 (권장X -> 묵시적 조인은 위험하다.)
상태 필드 : 단순히 값을 저장하기 위한 필드, 경로 탐색의 끝으로 탐색이 불가능하다.
ex) m.username 이라할 때 m.username.~~ 로 더 탐색이 불가능하다.

연관 필드 : 연관관계를 위한 필드
● 단일 값 : @ManyToOne, @OneToOne, 대상이 엔티티 (ex m.team)
묵시적 내부 조인 발생, 탐색O
묵시적 내부 조인 발생 -> 객체 입장에서는 m.team 이런 식으로 하면 되지만 DB입장에서는 조인이 일어나야 한다.

웬만하면 묵시적 내부 조인은 사용X
● 컬렉션 값 : @OneToMany, @ManyToMany, 대상이 컬렉션 (ex m.orders)
묵시적 내부 조인 발생, 탐색X

명시적 조인 join 키워드를 직접 사용한다. (이걸 사용 권장)
ex) select m from Member m join m.team t

---

✏️ 페치 조인(fetch join) 매우 중요

JPQL에서 성능 최적화를 위해 제공하는 기능
연관된 엔티티나 컬렉션을 SQL로 한 번에 함께 조회하는 기능
ex) 회원을 조회하고 싶은데 회원을 조회하면서 연관된 팀도 함께 조회된다.(SQL 한 번에)
그러면 select m from Member m join fetch m.team 하면 된다.
SQL 에서는
SELECT M.*, T.* FROM MEMBER M INNER JOIN TEAM T ON M.TEAM_ID = T.ID
쿼리로 내가 원하는대로 어떤 객체 그래프를 한 번에 조회할 거라는 것을 직접 명시적으로, 동적으로 나타낸다.

---

✏️ @ManyToOne 페치조인

Team teamA = new Team();
teamA.setName("팀A");
em.persist(teamA);

Team teamB = new Team();
teamB.setName("팀B");
em.persist(teamB);

Member member1 = new Member();
member1.setUsername("회원 1");
member1.setTeam(teamA);
em.persist(member1);

Member member2 = new Member();
member2.setUsername("회원 2");
member2.setTeam(teamA); //소속된 팀
em.persist(member2);

Member member3 = new Member();
member3.setUsername("회원 3");
member3.setTeam(teamB); //소속된 팀
em.persist(member3);
  
String query = "select m From Member m ";
List<Member> result = em.createQuery(query, Member.class)
	.getResultList();

for (Member member : result) {
	System.out.println("member = " + member.getUsername() + ", " + member.getTeam().getName());
            
}
tx.commit();

회원1, 팀A를 SQL 쿼리로 가저옴 -> 영속성 컨텍스트에 없기 때문에 SQL.

회원2, 팀A(1차 캐시)
회원3, 팀B(SQL) 영속성 컨텍스트에 없기 때문에 SQL 쿼리 날려서 영속성에 올리고 결과를 반환.

이러면 회원 100명이 다 다른 팀이면 쿼리가 100 + 1 (N+1) 번 나간다.
그래서 이 문제는 페치 조인으로 푼다.

String query = "select m From Member m join fetch m.team";

이때 get.Team()은 프록시가 아니다.
이미 member와 team의 데이터를 조인해서 다 가져왔고 쿼리가 날라가서 result에 담기는 시점에 Team은 프록시가 아닌 실제 데이터가 담기게 된다.

---

✏️ 컬렉션 페치 조인 (@ManyToOne 과 반대로 Team 으로부터 조인)

String query = "select t From Team t join fetch t.members";

List<Team> result = em.createQuery(query, Team.class)
                    .getResultList();

for (Team team : result) {
	System.out.println("Team = " + team.getName() + "| members : " + team.getMembers().size());
}

tx.commit();

Team = 팀A | members : 2
Team = 팀A | members : 2
Team = 팀B | members : 1
팀A에 회원이 2명 있기 때문에 2번 출력이 된 것이다.

join fetch를 하게 되면 일대다 관계 때문에 뻥튀기 되서 result.size() 를 출력하면 3이 된다
-> (다대일은 뻥튀기 안됨.)

해결 -> select distinct t
SQL에 distinct 추가해도 데이터가 다르면 SQL 결과에서 중복 제거가 실패한다.
그래서 JPA에서 distinct가 추가로 애플리케이션에서 중복 제거를 시도한다.
그러면서 같은 식별자를 가진 Team 엔티티를 제거한다. -> 중복이 제거된 team 결과 리스트를 반환한다.

✏️ 페치 조인 한계

• 페치 조인 대상에는 별칭(as) 를 줄 수 없다. (원칙적으로)
• 둘 이상의 컬렉션은 페치 조인 할 수 없다.
• 컬렉션을 페치 조인하면 페이징 API(setFirstResult, setMaxResults)를 할 수 없다.

● 일대일, 다대일 같은 단일 값 연관 필드들은 페치 조인해도 페이징 가능하다.
일대다 관계인 컬렉션에서는 데이터 뻥튀기가 되기 때문에 사용하면 위험한 것이다.


ex) TEAM에서 팀A를 조회할 때 MEMBER가 2명 조회가 된다고 했을 때 페이지 사이즈 1에 데이터를 한 건만 가져온다고 한다면 팀A는 회원 하나만 가지고 있다는 식이 되어 버린다.

🔥 문제 해결

• 일대다가 아닌 "다대일"의 형태로 쿼리를 수정해준다.
• N+1 문제 해결에는 페치 조인도 있지만 컬렉션은 해결 불가능하므로 BatchSize를 사용한다.

@BatchSize(size = 100)
@OneToMany(mappedBy = "team")
private List<Member> getMembers() {
	return members;
}

이런 식으로 쓸 수 있지만 글로벌 세팅으로 가져가도 무관(실무에서는 글로벌 세팅으로 깔고 감)

persistence.xml 에서 <property name="hibernate.default_batch_fetch_size" value="100" />

그러면 쿼리가 N+1이 아닌 테이블 수만큼 딱 맞춰서 가져가게 됨

1. 엔티티에 직접 적용하는 글로벌 로딩 전략보다 우선시 된다.
   @OneToMany(fetch = FetchType.LAZY) => 글로벌 전략
2. 실무에서 글로벌 로딩 전략은 모두 지연 로딩으로 한다.
3. 최적확가 필요한 곳에만 페치 조인을 적용한다.

여러 테이블을 조인해서 엔티티가 가진 모양이 아닌 전혀 다른 결과를 내야한다면 페치 조인 보다는 일반 조인을 사용하고 필요한 데이터들만 조회해서 DTO로 반환하는 것이 효과적이다.

● 3가지 방법이 있다.
1. 엔티티들을 페치 조인 써서 엔티티들을 조회해 온다.
2. 페치 조인 해서 애플리케이션에서 DTO로 바꿔서 화면에 반환한다.
3. 처음 JPQL 짤 때부터 아예 new operation으로 DTO로 스위칭해서 가져온다.

---

✏️ 엔티티 직접 사용

JPQL에서 엔티티를 직접 사용하면 SQL에서 해당 엔티티의 기본 키 값을 사용
즉 select count(m.id) 가 아닌 count(m) 을 사용함 (둘이 결과가 같음)
해당 엔티티의 기본 키 값을 사용하기 때문에

엔티티 직접 사용 -기본키

String query = "select m From Member m where m.id = :memberId";
Member findMember = em.createQuery(query, Member.class)
		.setParameter("memberId", member1.getId())
        .getSingleResult();
        
System.out.println("findMember = " + findMember);

결과

where ember0_. id=?
findMember = Member{id=3, username='회원1', age=0}

엔티티 직접 사용 -외래키

String query = "select m From Member m where m.team = :team";

List<Member> members = em.createQuery(query, Member.class)
		.setParameter("team", teamA)
        .getResultList();
for (Member member : members) {
	System.out.println("member = " + member);
}

결과

where member0_.TEAM_ID=?
member = Member{id=3, username='회원 1', age=0}
member = Member{id=4, username='회원 2', age=0}

Named 쿼리(@Entity 밑에 씀)

• 미리 정의해서 쿼리에 이름을 부여 -> @NamedQuery

정적 쿼리만 가능
매우 큰 장점 2가지
● 애플리케이션 로딩 시점에 초기화 후 재사용 -> 변하지 않는 정적쿼리를 애플리케이션 로딩 시점에 SQL로 파싱한다.

● 애플리케이션 로딩 시점에 쿼리를 검증 -> 즉 query 문법이나 문자가 맞게 입력이 되었는지 검증을 한다.

---

✏️ 벌크 연산

SQL의 UPDATE, DELETE와 같다고 보면 됨
영속성 컨텍스트를 무시하고 데이터베이스에 직접 쿼리

2 가지 방법 중 선택
● 벌크 연산을 먼저 수행
● 벌크 연산 수행 후 영속성 컨텍스트 초기화(권장)

int resultCount = em.createQuery("update Member m set m.age = 20")
       .executeUpdate();
Member findMember = em.find(Member.class, member1.getId());
System.out.println("findMember = " + findMember);

벌크 연산 시 DB에는 영향을 주지만 영속성 컨텍스트에는 반영이 되지 않는다.
그래서 초기화로 em.clear() 를 사용한다.

---

✏️ OSIV 전략

기본적으로 JPA가 언제 DB 커넥션을 가지고 오고 언제 DB 커넥션을 DB에 반환할까??

일단 영속성 컨텍스트는 동작을 하려면 DB 커넥션을 내부적으로 사용을 해야 LAZY 로딩을 하기 때문에 영속성 컨텍스트와 DB 커넥션을 굉장히 밀접하게 매칭이 되어 있다.

기본적으로 DB 트랜잭션을 시작할 때 연속성 컨텍스트가 DB 커넥션을 가져온다.

그러면 서비스 계층에서 트랜잭션을 시작하는 시점에 커넥션을 가져오고 이제 DB에다 돌려줘야 하는데 일단 spring.jpa.open-in-view 로 default로 켜져있다.
이 때 반환은 @Transaction 트랜잭션을 끝내고 밖에 나갈 때까지 반환을 하지 않는다.
이유 : LAZY 로딩 일어날 때 프록시 객체를 DB에서 데이터를 가져와서 채우든 프록시를 초기화하든 해야 하기 때문에 영속성 컨텍스트가 DB 커넥션을 물고 살아 있어야 한다.

'밖'의 의미
밖이라는 것은 트랜잭션의 범위를 벗어난 지점으로 @Transactional 메서드가 끝나고 트랜잭션이 종료되는 시점을 의미합니다. 스프링에서는 @Transactional 어노테이션을 사용하면 해당 메서드가 실행되는 동안 트랜잭션이 유지됩니다. 트랜잭션이 완료되면(메서드 종료) 데이터베이스 커넥션이 반환됩니다.

OSIV는 이 트랜잭션이 끝나도 이 영속성 컨텍스트를 끝까지 살려둔다. (API라면 유저한테 반환할 때까지)

화면인 경우는 뷰 템플릿 가지고 렌더링 할 때까지 유저에게 response가 나갈 때까지 DB 커넥션을 물고 있다.
결론 -> 영속성 컨텍스트랑 DB 커넥션이 끝까지 살아있다.

🏷️ OSIV 장단점

• 장점
  • View Template이나 API 컨트롤러에서 지연 로딩이 가능한 것 처럼 영속성 컨텍스트와 DB 커넥션 유지가 큰 장점이다.
    
    
• 치명적인 단점
  • 너무 오랫동안 커넥션을 물고 있음.
  • 실시간 트래픽이 중요한 애플리케이션에서는 잘못하면 커넥션이 말라버린다.
    • 즉 컨트롤러에서 외부 API를 호출하면 외부 API 대기 시간만큼 커넥션 리소스를 반환하지 못하고 유지하게 된다.

그러면 spring.jpa.open-in-view: false로 해서 OSIV 종료하면 트랜잭션을 시작하고 끝날 때까지만 DB 커넥션을 유지한다.
그래서 어떤 로직, 외부 API 호출해도 DB 커넥션 안 가지고 있기 때문에 딱 반환해서 트래픽이 많거나 사용자 요청이 많은 경우에는 훨씬 더 커넥션을 유연하게 쓸 수 있다.

🏷️ OSIV 껐을 때의 단점

지연 로딩을 하려면 영속성 컨텍스트가 살아 있어야 한다.
트랜잭션 끝났다고 영속성 컨텍스트가 없어져버리면 모든 지연 로딩을 트랜잭션 안에서 처리해야 한다.
(위 그림에서 영속성 컨텍스트 생존 범위에서 모두 끝내야 함.)

결론 -> 트랜잭션이 끝나기 전에 지연로딩을 강제로 호출해야 한다.

• 서비스 계층이나 패치 조인을 사용하거나 해서 다 로딩 된 것을 가져와야 한다.

🏷️ open-in-view: false

이것을 해주면 LazyInitializationException 이 발생한다.
Member가 proxy인데 초기화를 못한다.

그림에서 보면 Controller에서 영속성 컨텍스트가 없기 때문에 에러가 발생한 것이다.
트랜잭션 안에서 다 로딩해 놓거나 fetchJoin을 사용해서 해결하면 된다.
-> 트랜잭션 안으로 가져가는 것!!

🏷️ 실무에서는 OSIV를 끈 상ㅌ태로 복잡성을 관리하는 좋은 방법이 있다.

커맨드와 쿼리를 분리하면 된다.
https://en.wikipedia.org/wiki/Command-query_separation

개발할 때 한 레포지토리나 한 서비스에 쿼리용이나 핵심 비즈니스용을 같이 녹여놓으면 복잡한 조회용이 20~30개 일 때 유지보수가 어려워진다.

• 라이프 사이클이 다르다
• 대부분 화면에 맞추는 API나 화면용 기능들은 정말 자주 바뀐다 -> 라이프 사이클이 빠름
• 핵심 비즈니스 로직은 그런 비즈니스 로직이나 정책들이 있는 서비스 클래스는 잘 변경되지 않는다.
  • 이 둘 사이의 라이프 사이클이 다르다.

Service 에서 ~~Service(핵심 비즈니스 로직)와 ~~QueryService(화면이나 API에 맞춘 서비스로 주로 읽기 전용 트랜잭션 사용)로 나누어서 개발하는 것이 바람직하다.

결정

고객 서비스 기반의 트래픽이 많은 실시간 API들을 많이 제공해야 하는 API 서버는 off-session-inview 끄기
서비스 API 트래픽이 정말 많다면 끄기


ADMIN 처럼 커넥션을 많이 사용하지 않는 곳에서는 OSIV 켜기.
커넥션을 몇 개 안 쓰기 때문에.


기본적으로는 키는 것이 좋긴 한데 성능이 이슈가 되면 끄는 것이 좋다.