지식 줍줍 🐿️

JPQL (Java Persistence Query Language)

설명

테이블 대상으로 한 언어가 아닌, 엔티티 객체 대상으로 쿼리한 것.
SQL을 추상화하여 특정 데이터베이스 SQL에 의존하지 않음.
JPQL → SQL 으로 변환함
객체지향SQL

특징

-- 일반 SQL 문
select * from Member as m where m.username = 'coffee' -- 별칭(m)은 필수다.

-- JPQL 문
/**
@Entity(name="memeber")
class Memeber {
  ...
  private String username;
}
*/
select m from memeber as m where m.username = 'coffee'
-- → 엔티티명(member)으로 조회해야한다.
-- → 그렇지 않으면 클래스명(Member)을 기본으로 사용한다. (클래스명 추천)
-- → 대소문자를 구분한다.

select m.username from member as m 
-- → username 을 조회 한다면, 별칭(m)은 필수로 사용해야함.

결과값을 받을 때 (createQuery 사용 시)

• TypeQuery: 반환타입(메소드 리턴타입)을 명확하게 지정할 수 있는 경우 사용.
• Query: 반환타입(메소드 리턴타입)을 명확하게 지정할 수 없는 경우 사용.

결과 조회 API

• query.getResultList(): 결과가 하나 이상일때 리스트 반환
• query.getSingleResult(): 결과가 정확히 하나, 단일 객체 반환.

JPQL 조인

• 내부 조인과 외부조인

-- 내부 조인 (INNER JOIN, INNER 생략 가능)
select m from Member m inner join m.team t where t.name = :teamName


-- 외부 조인 (LEFT OUTER JOIN, OUTER 생략 가능)
select m from Member m left join m.team t


-- 세타조인 (연관관계 없는데 조인하고 싶은 경우!!)
select count(m) from Member m, Team t where m.username = t.name

• 컬렉션 조인
  → 일대다 or 다대일 관계 처럼 컬렉션을 사용하는 곳에 조인하는 것. 
  → 일대다(=다의 연관필드 사용) or 다대일(=일의 연관필드 사용)
 
• 세타 조인
  → where 절 사용하여 조인 (select count(m) from Memeber m, Team t where m.username = t.name)

• JOIN ON 절 (JPA 2.1 부터 사용 가능)
  → 외부조인에서만 사용.

• 페치 조인 (FETCH JOIN)
  → JPQL에서 성능 최적화를 위해 제공하는 기능. 연관된 엔티티나 컬렉션을 한번에 같이 조회하는 기능. join fetch 으로 사용.
  → 페치조인 사용시, SQL 한번으로 연관된 엔티티들을 함께 조회할 수 있어, SQL 조회 횟수를 줄여 성능 최적화가 가능하다.
  → 지연로딩 사용 및  fetch join 적용하는것이 효율적.
  → 페치조인은 alias 사용을 못하며, 둘 이상의 컬렉션을 페치할 수 없다. 그리고 페이징 API을 사용할 수 없다...헉 
  → 페치조인은 객체 그래프 유지할때 사용하면 효과적!
  → 특정 데이터만 표현해야 한다면 구지 페치 조인을 사용할 필요는 없다.

-- fetch join 을 사용하는 경우, m 및 m.team 모두 조회됨.
-- >> JPQL 식
select m from Member m join fetch m.team where m.name = 'AA'

-- >> SQL 식 
select
  m.*, t.*
from Member m join Team t on m.team_id = t.id
where m.name = 'AA'




-- fetch join 이 아닌 일반 join 을 하는 경우는 SQL 에서 이렇게 나옴
-- >> JPQL 식
select m from Member m join m.team

-- >> SQL 식 
select
  m.*
from Member m join Team t on m.team_id = t.id

• 묵시적 조인
  → join 키워드 직접 사용 (select ~~ from Member m join m.team t)
  → 조인이 일어나는 상황,,을 한눈에 알아보기 어렵다,,?

• 명시적 조인 (추천⭐️)
  → 경로 표현식에 의해 묵시적으로 SQL 조인 발생 (내부 조인만 가능) (select m.team from Member m)

서브쿼리

where, having 절에서만 사용 가능하며, select, from 절에서는 사용 불가능! (ㅠㅠ)
• EXISTS(결과 존재시 참) → select ~~ where exsist (select t from ~~)
• ALL(모두 만족 참) → select ~~ where o.number > ALL (select b from ~~)
• ANY(조건이 하나라도 만족시 참=SOME) → select ~~ where a.tesm = ANY(select c from ~~) 
• IN(서브쿼리 결과 중 하나라도 같은 값이 있으면 참) select ~~ where a.count in (select d from ~~)

CASE 식

• COALESCE: 하나씩 조회해서 null 이 아니면 반환
• NULLIF: 두 값이 같으면 null 반환, 다르면 첫번째 값 반환

사용자 정의 함수

select function('group_concat', name) from ~~
→ 사용 전 group_concat을 사용한다는 정의를 해야 함. (DB방언 상속 받고, 사용자 정의 함수 등록 필요)

참고

- 책: https://www.coupang.com/vp/products/20488571?itemId=80660090&vendorItemId=3314421212&src=1042503&spec=10304982&addtag=400&ctag=20488571&lptag=10304982I80660090&itime=20220302010946&pageType=PRODUCT&pageValue=20488571&wPcid=16461509863931582782572&wRef=&wTime=20220302010946&redirect=landing&gclid=CjwKCAiApfeQBhAUEiwA7K_UHxuELLbyb9IhdrRf5inlJZLtN8-t8cUswFHeV6fFp-Yd4RThtzZvHxoCPFsQAvD_BwE&campaignid=12207438463&adgroupid=115720946583&isAddedCart= 

연관관계 매핑

테이블을 기준으로 하면, 외래키를 사용하여 테이블끼리 연관을 맺는것 or 객체라면 참조(주소)을 사용하여 연관을 맺는것.

연관관계 방향 (Direction)

‣ 단반향 연관관계
    → 한쪽만 참조하는것
    → 객체 관계

‣ 양방향 연관관계 
    → 서로 참조하는것
    → mappedBy 속성 사용
    → 테이블 끼리 연관관계 맺기 (외래키 이용) = 서로 다른 단방향 관계 2개

다중성 (Multiplicity)

‣ 다대일 (N:1)
    → 단방향, 양방향
    → @ManyToOne 으로 표현
    → N 에 외래키 존재 = 연관관계 주인
    → @ManyToOne 기본 페치전략: 즉시로딩 (EAGER)


‣ 일대다 (1:N)
    → 단방향(@JoinColumn 명시 필요), 양방향(=존재하지 않음. 다대일 양방향 매핑을 사용해야함)
    → @OneToMay 으로 표현
    → N 에 외래키 존재 = 연관관계 주인
    → @OneToMany 기본 페치전략: 지연로딩 (LAZY)
    → 일대다 단방향 매핑보단, 다대일 양방향 매핑을 사용하도록 하자! (외래키 관리하기 힘들기 때문이다.)

‣ 일대일 (1:1)
    → 주테이블 or 대상테이블 에서 외래키 가질 수 있음.
    → @OneToOne 으로 표현
    → @OneToOne 기본 페치전략: 즉시로딩 (EAGER)

‣ 다대다 (N:N)
    → 단방향, 양방향 (다대다 양방향은 일대다 양방향과 같음)
    → @ManyToMany 으로 표현
    → N:N 사이 중간 테이블을 추가하여 사용.
    → 식별관계와 비식별관계가 있다.
    → @ManyToMany 기본 페치전략: 지연로딩 (LAZY)

연관관계 매핑 관련 어노테이션

@ManyToOne(optional="false 리면 연관된 엔티티가 항상 있어야 한다. 기본값: true", 
           fetch="글로벌 페치 전략(EAGER, LAZY)", 
           cascade="영속성 전이 기능 사용", targetEntity="연관된 엔티티의 타입 정보 설정(거의사용안함).")
           
           
@OneToMany(mappedBy = "order", cascade = CascadeType.ALL)

@ManyToOne(fetch = FetchType.LAZY)

@ManyToMany(mappedBy = "items")

@JoinColumn(name="매핑할 외래 키 이름", 
            referencedColumnName="외래키가 참조하는 대상 테이블의 컬럼명", 
            foreignKey="외래키제약조건을 직접 지정할 수 있다. 이 속성은 테이블을 생성할 때만 사용한다.")
/**
- 그외속성
unique, nullable, insertable, updatable, columnDefinition, table..
*/

@JoinTable(name = "category_item",
        joinColumns = @JoinColumn(name = "category_id"),
        inverseJoinColumns = @JoinColumn(name="item_id")
)

// 부모 객체에 설정
@Inheritance(strategy = InheritanceType.SINGLE_TABLE) // 한테이블에 컬럼 다 때려박음
@DiscriminatorColumn(name = "dtype") // 하위 자식테이블들 타입..

// 자식객체에다가 설정
@DiscriminatorValue("A")

@Enumerated(EnumType.STRING)

@Embedded

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

연관관계 주인 (Owner) vs 주인이 아닌쪽

‣ 연관관계의 주인
    → 데이터 베이스 연관관계와 매핑되고 외래키를 관리(등록,수정,삭제)를 할수있다.
    → mappedBy 속성을 사용하지 않는다.
    → 외래키 관리자를 선택 하는것이다.
    → 외래키의 위치와 관련해서 정해야하고, 비지니스 중요도로 접근하면 안됨
‣ 주인이 아닌 쪽
    → 읽기만 가능하다.
    → mappedBy 속성을 사용 하여 속성의 값으로 연관관계의 주인을 지정할 수 있다.

프록시

연관된 객체를 처음부터 데이터베이스에서 조회하는것이 아니라, 실제 사용하는 시점에 데이터베이스에서 조회할 수 있음

프록시 객체

‣ 데이터베이스 조회를 지연할 수 있는 가짜 객체(지연로딩에서 사용). 실제 엔티티 클래스를 상속받아 만들어져있음.
‣ 진짜객체인지, 프록시 객체인지 구분하지 않고 사용 가능
‣ EntityManager.getReference(): 조회를 미루고 싶을때 사용. 이를 사용하면 프록시 객체를 반환
‣ 처음 사용할때 한번만 초기화 → 초기화되면 프록시 객체를 통해 실제 엔티티에 접근 가능.
‣ 영속성 컨텍스트에 찾는 엔티티가 이미 있으면, 데이터베이스를 조회할 필요가 없으므로
em.getReference()을 호출해도 프록시가 아닌 실제 엔티티를 반환함.

즉시로딩(FetchType.EAGER) 과 지연로딩(FetchType.LAZY) 

‣ 즉시로딩(FetchType.EAGER)
    → 엔티티를 조회할 때 연관된 엔티티도 함께 조회
    → 하이버네이트는 가능하면 SQL 조인을 사용해서 한 번에 조회
    → 연관된 엔티티가 하나면 즉시로딩 사용


‣ 지연로딩(FetchType.LAZY)
    → 연관된 엔티티를 실제 사용할 때 조회
    → 프록시를 실제 사용할 때 초기화하면서 데이터베이스를 조회
    → 연관된 엔티티가 컬렉션이면 지연로딩 사용

✰ 지연로딩을 사용하도록 하자. (N+1문제 방지)
✰ 컬렉션은 필드에서 바로 초기화를 하도록 하자. (ex. Apple apple = new Apple();)
✰ 만약 엔티티조회시, 연관된 엔티티를 조회해야한다면 fetch join을 사용하자. 

참고

- 책: http://www.kyobobook.co.kr/product/detailViewKor.laf?mallGb=KOR&ejkGb=KOR&barcode=9788960777330 

- 링크: https://velog.io/@lsj8367/JPA-%ED%94%84%EB%A1%9D%EC%8B%9C

변경감지 (Dirty Checking)

‣ 변경된 엔티티 내용을 데이터베이스에 자동으로 반영해주는 기능.

em.save() 을 호출하지 않았는데 데이터베이스에 저장이 되었다.

‣ 트랜잭션 커밋 후, flush (데이터베이스 동기화) 하면서 username 변경됨 → 데이터베이스 반영 

참고

- 링크: https://cornarong.tistory.com/m/63

JPA (Java Persistence API)

자바 진영에서 만든 ORM 기술 표준

사용하는 이유

소프트웨어 개발자가 SQL 에 의존하는 개발을 피할 수 있다.
개발자 입장에서 쿼리문을 다루지 않고 객체지향 중심으로 개발을 할 수 있도록 되어있기에, 생산성 및 유지보수에 효율적
객체와 관계형 DB의 차이를 중간에서 해결해주기 때문에 데이터베이스를 교체하더라도 유지보수 영향도가 크지 않음.
    → mysql,, oracle 바꿔 사용하더라도 쿼리 변경없이 사용 가능

JPA 가 제공하는 기능

‣ 엔티티 와 테이블을 매핑하는 설계 부분
‣ 매핑한 엔티티를 실제 사용하는 부분.

✢ 엔티티 ? 
정보를 표현하는 단위이기도하며
JPA 에서는 관계형 데이터베이스에 영속화 해야할 자바 객체 (데이터 베이스 테이블로 표현)를 나타냄.

영속성 관리

프로세스가 생성이 되었지만, 별개로 유지되는 상태의 특징중 하나.
이를 별도의 기억장치에 보존 및 관리하는것.

엔티티 매니저는 트랜잭션이 실행될때 커넥션을 얻음

엔티티 매니저 팩토리

EntityManagerFactory emf = Persistence.createEntityManagerFactory("test");

‣ JPA 을 사용할 수 있게함.
‣ JPA 동작 위해 기반 객체를 만들고 커넥션풀을 생성함 → 비용이 크다.
‣ 어플리케이션에서 딱 한번 생성 후 공유해서 사용해야 함.

엔티티 매니저

EntityManager em = emf.createEntityManager();

‣ JPA 기능을 제공. 이를 이용하여 CRUD가 가능함.
‣ 엔티티를 영속성 컨텍스트에 저장해주는 역할을 함. (관리자)
‣ 트랜잭션을 커밋하기 직전까지 데이터베이스에 엔티티를 저장하지 않고 내부 쿼리 저장소(쓰기지연 SQL 저장소)에 쿼리를 모아두도록 함.
    → 트랜잭션 커밋시 모아둔 쿼리를 데이터베이스에 보냄=플러시 (쓰기지연)
    → 트랜잭션 커밋까지 되어야 데이터베이스 변경내용 반영이 됨
‣ 내부에 데이터 소스를 유지하면서 (커넥션 유지) 데이터베이스와 통신함.
‣ 개발자 입장에선 데이터베이스로 생각할 수 있음.
‣ 데이터베이스 커넥션과 밀접한 관계가 있으므로 스레드간에 공유하거나 재사용하면 안됨. (동시성 문제)
‣ 생성 비용이 크진 않음.
‣ 엔티티매니저를 사용할 때 마다 실제로 영속성 컨텍스트와 상호 작용을 함.

영속성 컨텍스트 (persistence context)

‣ 엔티티를 영구 저장하는 환경 
‣ 엔티티 매니저를 사용하여 엔티티를 영속성 컨텍스트에 저장
‣ 엔티티 매니저로 엔티티를 저장하거나 조회하면 엔티티매니저는 영속성 컨텍스트에 엔티티를 보관하고 관리 (엔티티 매니저의 수명주기 관리)
‣ 1차캐시, 동일성보장(identity), 쓰기지연, 변경감지(Dirty Checking), 지연로딩(Lazy Loading) 됨

✢ 1차 캐시 ? 
영속성 컨텍스트 내 캐시를 가지고 있는 것. 
영속상태의 엔티티는 모두 이곳에 저장됨.
Map 형태이고 [key: @Id로 매핑한 식별자, value: 엔티티 인스턴스] 이다

엔티티 생명주기

‣ 비영속 (new/transient): 영속성 컨텍스트와 전혀 관계가 없는 상태
    → 엔티티를 영속성 컨텍스트에 저장하지 않은 상태.
    → 객체만 생성한 상태 
‣ 영속 (managed): 영속성 컨텍스트에 저장된 상태 (영속상태)
‣ 준영속 (detached): 영속성 컨텍스트에 저장 되었다가 분리된 상태 
   → 영속성 컨텍스트가 제공하는 기능을 사용할 수 없다.
   → 1차 캐시에서 사라짐..
   → 지연로딩(LAZY LOADING) 할 수 없다.
   → 영속성 컨텍스트가 제공하는 기능을 사용할 수 없다.
   → 식별자값을 가지고 있고 거의 비영속 상태임.
   → 다시 영속 상태로 만드려면 merge() 하면 됨. (준영속 상태의 엔티티를 받아 다시 영속 상태로 만듬)
‣ 삭제 (removed): 삭제 

엔티티 저장 (insert)

‣ 쓰기지연(transactional write-behind)
    → 트랜잭션 커밋 직전까지 데이터베이스에 엔티티를 저장하지 않고,
        내부 쿼리 저장소에 INSERT 쿼리를 모아두고 커밋시 데이터베이스에 보내는 상태 (보내는 작업=flush)

엔티티 조회 (read)

‣ 동일성이 보장된다!

변경 감지 (dirty checking) - 수정

‣ 엔티티의 변경사항을 데이터베이스에 자동으로 반영하는 기능
‣ 엔티티를 조회하여 변경부분 파악 후 업데이트
‣ 영속성 컨텍스트가 관리하는 영속 상태의 엔티티에만 적용
☞ 변경 감지 관련 상황 (링크)

플러시 (flush)

‣ 영속성 컨텍스트의 변경 내용을 데이터베이스에 동기화하는 작업. 
    → 직접 호출: em.flush() 직접 호출
    → 트랜잭션 커밋 시 플러시 자동 호출: 기본설정..
    → JPQL 쿼리 실행시 플러시 자동 호출

참고

- 책: http://www.kyobobook.co.kr/product/detailViewKor.laf?mallGb=KOR&ejkGb=KOR&barcode=9788960777330 

- 링크: https://ko.wikipedia.org/wiki/%EC%A7%80%EC%86%8D%EC%84%B1

- 링크: https://www.baeldung.com/jpa-entities

- 링크: https://cupping.tistory.com/2

- 링크: https://openjpa.apache.org/builds/1.2.3/apache-openjpa/docs/jpa_overview_emfactory_perscontext.html

- 링크: https://www.baeldung.com/jpa-hibernate-persistence-context

- 강의: https://www.youtube.com/playlist?list=PL9mhQYIlKEhfpMVndI23RwWTL9-VL-B7U