JPA에 관하여✨

YaR Lab·2024년 7월 26일
0

TIL✨

목록 보기
127/135
post-thumbnail

[DB Engine, DBMS(Database Management System) 차이점‼️]
DB-Engines Ranking 이 사이트를 참고하면 연도별 DB Engin 랭킹을 참고할 수 있다.
DB Engine은 DBMS내에서 데이터의 CRUD와 같은 기본작업을 수행한다. 하나의 DBMS내에서 여러 DB엔진을 사용하여 관리할 수 있다. 따라서 DBMS가 조금 더 큰 개념이지만 요즘에는 DBMS와 DB엔진을 같은 선상에 놓고 부른다고 한다.

[조회와 검색의 차이점‼️]
조회는 이미 알고 있는 데이터나 식별 가능한 데이터를 얻기 위해 사용하는 작업이다.

검색

[정규화를 하는 이유가 뭘까❓]
데이터, 데이터의 관계를 세분화 하는 것
현업에서는 많아야 3정규화 까지 한다.

[반정규화 하는 이유가 뭘까❓]

[JDBC❓]
java와 DB를 연결해주는 API

[자바 세상 DB 세상 뭐가 다른거야?]

[JPA JDBC 가지고 있나요?]
JDBC 가지고 있다 JPA가

[Entity가 뭐야?]
의미 있는 개체
데이터를 갖고 있는 개체
RequestEntity
ResponseEntity

[드라이버]
MySql을 사용하려면 드라이버가 필요하다.

[JPA != Spring Data JPA]
Spring이 JPA를 조금 더 편하게 쓸 수 있도록 여러 기능을 추가해놓은 것이 Spring Data JPA

[JDBC가 뭘까❓]
application.properies 에서spring.datasource 라고 하면서 터널링 설정을 한다. datasource객체가 터널링을 대신 해준다.

datasource 객체가 틀렸다고 알리는 방법

datasource객체는 spring 빈이다. spring은 어떻게 알고 datasource 객체를 만드는 것인가? application.properties에 datasource 객체의 field를 설정함
(@AutoConfiguration 이 자동으로 해줌)

application.yml은 그냥 표현방식의 차이다.

[EoFException]
socket, connection 끊어질때
mysql은 8시간 뒤에 연결이 끊김(default)
port 다를때
권한 없을때

[docker inbound outbound port number]

[DB API들의 구현체 내 주요 객체❓]

JDBC - 구현체(Hikari), 주요 일꾼(DataSource)
JPA - 구현체(hibernate), 주요 일꾼(EntityManager)
SpringData JPA

[Connection Pool이 무엇인가❓]

[EntityManager at persistence]
external library -> persistence에 있음

[JPA가 어떻게 영속화를 해줄까?]
Entity: 난, 영속화되고 싶은/된 객체
@Entity: 어노테이션 달아주면 Entity Context(영속화가 될/된 객체 공간)에 들어가고 싶어!
EntityManager 는 persist()로 EntityContext에 Entity를 모아둠 + 테이블에 저장

[@Entity 는 왜 꼭 id가 필요한가?]
Entity Context에서 들어온 Entity들을 식별하기 위해서

[트랜젝션이 필요하다고 하고 있음]
@Transactional
자바에서 제공, 스프링에서 제공(2가지를 제공)

[Entity Manager]
DB에 먼저 데이터를 만들고
PK를 가져와서 Entity Context에서 id를 취급해서 객체를 저장해줌

@Entity

persist(): EntityContext에 추가 DB에 저장까지 해줘
= 영속화한다

ex) 스프링에서는 @Component -> ApplicationContext

@Transactional

@Id

find()

find() 메서드를 해도 DB에서 꺼내온 객체를 Context를 들렸다 옴

remove()

createQuery() ('자바스러운' 쿼리)

JPA는 자바 - 디비 패러다임 '대신' 일치 목적
=> 자바는 자바스럽게, 디비는 디비스럽게

JPQL(쓸때마다 찾아서 쓰면 됨 외울필요 없음)
자바스럽게 쿼리 짜면 -> JPA가 알아서 SQL로 바꿔서 쓸게!
ex)
SELECT *(컬럼) FROM (테이블명);
SELECT (필드) FROM (클래스명) AS(별칭)

clear()

clear 메서드는 영속성 컨텍스트의 모든 엔티티를 초기화하는 역할을 함

영속성 컨텍스트에 캐시된 모든 엔티티를 제거하고, 1차 캐시를 비우는 역할을 수행

clear 메서드는 트랜잭션 범위 내에서 사용할 수 있다.

close()

close 메서드는 영속성 컨텍스트를 종료하고 관련 리소스를 해제하는 역할을 한다.

close 메서드를 호출하면 영속성 컨텍스트는 완전히 닫히고, 관련된 데이터베이스 연결, 캐시 등의 리소스가 해제된다.

영속성 컨텍스트가 닫힌 후에는 엔티티를 로딩하거나 변경할 수 없다.

flush()

영속성 컨텍스트와 DB 동기화 작업
ditach 메서드는 안씀

[JPA와 SpringDataJPA 차이를 잘 구별해야 함]

[@Qualifier, @Primary]

[Test 코드 작성 ]

커맨드 N + test
@Test 메서드위에 어노테이션
테스트는 프레임워크에 의존하면 안된다!!!
JPA
@SpringBootTest 테스트에 스프링이 관여하게 한다.

[연관 관계란❓]
ERD와 객체의 연관관계는 다르다.

ERD에서는 Join을 할때 PK이든 FK이든 상관없이 기준을 잡을 수 있기 때문에 방향이 없다고 볼 수 있다.

객체에서는 연관관계에 방향이 있다. 아래의 코드를 보면 Child만 Parent에 접근이 가능하기 때문에 단방향이라고 볼 수 있다.

class Parent {
	String id;
    String name;
}

class Child {
	int id;
    String name;
    Parent parent;
}

아래의 코드는 서로 객체를 알고 있기 때문에 양방향이라고 볼 수 있다. 정확히는 서로 단방향인 구조이다.

class Parent {
	String id;
    String name;
    Child child
}

class Child {
	int id;
    String name;
    Parent parent;
}

[1:N, N:1 순서가 중요할까❓]
단방향
1. N:1 다객체가 일객체를 참조할 때 @ManyToOne, @JoinColumn("FK 컬럼명")
2. 1:N 일객체가 다객체를 참조할 때
서로 단방향
1. N:1 다객체가 연관관계 주인일 때 @ManyToOne, @JoinColumn("FK 컬럼명"), OneToMany(mappedBy="연관 관계 주인객체가 해당 객체를 참조할 때 쓰는 필드명")
2. 1:N 일객체가 연관관계 주인일 때

[연관 관계의 주인이란❓]
DB FK를 관리(수정, 삭제 등)할 수 있는 객체를 주인이라고 한다.

단방향일 경우 참조 객체 필드 가진 객체가 주인
양방향 객체끼리는 서로 참조 가능 주인이 누구인지 ERD 보고 확인

[JPA에서 테이블의 연관 관계 어떻게 설정해야 할까❓]

[지연 로딩은 하나의 세션 단위로 동작한다!]
즉시 로딩

[즉시 로딩 vs 지연 로딩]
@ManyToOne : FK를 가질 수 있고, 연관 관계 주인
즉시 로딩

@OneToMany:
지연 로딩

[JpaRepository]
모든 메서드에 대한 트랜젝션을 처리해줌

[QueryByExampleExecutor ?]
쿼리와 메서드를 만들어주는 객체
findByName(같은 애들을 만들수 있음)
Name은 객체의 필드명으로 사용됨

[jpa 얼마나 똑똑한대?]
accountName account_name 같은것도 매핑해줌
[jackson은 얼마나 똑똑한대?]
accountName account_name 같은것은 매핑해주지 않음
불일치를 일치시키는 패러다임과는 다름

[@Table, @Column]
어노테이션 객체 DB
@Table 클래스명 테이블명
@Column 필드명 컬럼명

[@Table은 언제 쓸까?]
예약어로 사용중일 경우
Order <-> Orders(예약어)
단수 <-> 복수

[연관관계 객체에서 무한참조가 일어날 때 해결 방법]
1. getter 선택적 사용
2. DTO로 필드를 선택적 사용
3. 최선책 :: 서로 단방향이 문제 => 단방향&연관관계 주인 맵핑 "양방향이 절대 안된다는 뜻은 아니다!"
4. @JsonIgnoreProperties("연관 관계 주인객체가 해당 객체를 참조할 때 쓰는 필드명")

[OneToMany 써야하는가?]
쓰면 안좋지만 (안정성) 편하고 빠른 방법이다.

0개의 댓글