무럭무럭 성장일기

[JPA] 자바 ORM 표준 JPA 프로그래밍 #11

지니(jineey) — Sun, 17 Nov 2024 23:29:44 +0900

개요

엔티티의 연관관계를 매핑할 때는 다음 3가지를 고려 필요

다중성
단방향, 양방향
- 단방향: 객체 관계에서 한 쪽만 참조하는 것
- 양방향: 양쪽이 서로 참조하는 것
연관관계의 주인
- 외래 키를 가진 테이블과 매핑한 엔티티가 연관관계의 주인
- 연관관계의 주인이 아닐 경우, mappedBy 속성을 사용하여 연관관계의 주인 필드 이름을 값으로 입력
- 연관관계의 다중성
  - 다대일 (@ManyToOne)
  - 일대다 (@OneToMany)
  - 일대일 (@OneToOne)
  - 다대다 (@ManyToMany)

다대일

데이터베이스 테이블의 일(1), 다(N) 관계에서 외래 키는 항상 다(N)쪽에 있음 ➡️ 객체 양방향 관계에서 연관관계의 주인은 항상 다쪽!

1. 다대일 단방향[N:1]

@Entity
public class Member {
    @Id @GeneratedValue
    @Column (name="MEMBER_ID")
    private Long id;
    
    private String username;
    
    @ManyToOne
    @JoinColumn(name="TEAM_ID")
    private Team team;
    ...
}

➡️ 회원은 Member.team 으로 팀 엔티티를 참조할 수 있지만 반대로 팀은 회원을 참조하는 필드가 없기 때문에 다대일 단방향 연관관계

2. 다대일 양방향[N:1, 1:N]

양방향은 외래 키가 있는 쪽이 연관관계의 주인
- JPA는 외래 키를 관리할 때 연관관계의 주인만 사용
- 주인이 아닌 경우는 조회을 위한 JPQL이나 객체 그래프를 탐색할 때 사용
양방향 연관관계는 항상 서로를 참조
- 어느 한 쪽만 참조하면 양방향 연관관계가 성립하지 않음
- 항상 서로를 참조하게 할 때는 '연관관계 편의 메소드'를 작성하는 것이 좋으나,
  편의 메소드를 한 곳에만 작성하는 것이 아닌 양쪽 다 작성 시 무한루프에 빠지는 것을 주의해야 함

일대다

일대다 관계는 다대일 관계의 반대 방향.

일대다 관계는 엔티티를 하나 이상 참조할 수 있으므로 자바 컬렉션인 Collection, List, Set, Map 중에서 하나를 사용

1. 일대다 단방향[1:N]

하나의 팀은 여러 회원을 참조 가능할 때 일대다 관계라고 칭하고,

팀은 회원들을 참조하지만 반대로 회원은 팀을 참조하지 않으면 둘의 관계는 단방향이다

일대다 단방향 팀 엔티티

@Entity
public class Team {
    @Id @GeneratedValue
    @Column(name="TEAM_ID")
    private Long id;
    
    private String name;
    
    @OneToMany
    @JoinCloumn(name="TEAM_ID") //Member 테이블의 TEAM_ID (FK)
    private List<Member> members = new ArrayList<Member>();
    ...
}

일대다 단방향 회원 엔티티

@Entity
public class Member {
    @Id @GeneratedValue
    @Column(name="MEMBER_ID")
    private Long id;
    
    private String username;
    ...
}

➡️ 일대다 단방향 관계를 매핑할 때는 @JoinColumn 명시해야 함. 사용하지 않을 시 JPA는 연결 테이블을 중간에 두고 연관관계를 관리하는 조인 테이블 전략을 기본으로 사용하여 매핑함

일대다 단방향 매핑 단점
- 매핑한 객체가 관리하는 외래 키가 다른 테이블에 있음
- 다른 테이블에 외래 키가 있으면 연관관계 처리를 위해서 INSERT SQL 실행 이후, UPDATE SQL을 추가로 실행 필요
다대일 양방향 매핑 권장
- 일대다 단방향 매핑 사용 시 엔티티를 매핑한 테이블이 아닌 다른 테이블의 외래 키를 관리 필요
- 성능 문제 및 관리의 어려움 발생
- 다대일 양방향 매핑을 사용하여 관리해야 하는 외래 키가 본인 테이블에 있도록 하면 문제 해결됨

2. 일대다 양방향[1:N, N:1]

왼쪽을 연관관계의 주인으로 설정했을 때, 일대다 양방향 매핑은 존재하지 않으며 다대일 양방향 매핑을 사용해야 함

일대다 양방향 매핑을 해야 할 경우에는 일대다 단방향 매핑 반대편에 같은 외래 키를 사용하는 다대일 단방향 매핑을 읽기 전용으로 추가

@Entity
public class Member {
    @Id @GeneratedValue
    @Column(name="MEMBER_ID")
    private Long id;
    private String username;
    
    @ManyToOne
    @JoinColumn(name="TEAM_ID", insertable=false, updatable=false)
    private Team team;
    
    ...
}

➡️ insertable = false, updatable = false 를 통해 읽기만 가능하도록 설정

일대일 [1:1]

일대일 관계는 양쪽이 서로 하나의 관계만 가짐

일대일 관계는 주 테이블이나 대상 테이블 중에 누가 외래 키를 가질지 선택 필요

주 테이블의 외래 키
- 주 테이블에 외래 키를 두고 대상 테이블을 참조
- 외래 키를 객체 참조와 비슷하게 사용할 수 있기 때문에 객체지향 개발자들이 선호하는 방법
- 주 테이블이 외래 키를 가지고 있으므로 주 테이블만 확인해도 대상 테이블과의 연관관계를 알 수 있음
대상 테이블에 외래 키
- 전통적인 데이터베이스 개발자들이 선호하는 방법
- 테이블 관계를 일대일에서 일대다로 변경할 때 테이블 구조를 그대로 유지 가능
- 단방향 vs 양방향
  - 단방향
    - 단방향 관계를 JPA 에서 지원하지 않음
  - 양방향
    - 일대일 매핑에서 대상 테이블에 외래 키를 두고 싶으면 양방향으로 매핑
- 프록시를 사용할 때 외래 키를 직접 관리하지 않는 일대일 관계는 지연 로딩으로 설정해도 즉시 로딩됨

다대다 [N:N]

1. 단방향

관계형 데이터베이스는 정규화된 테이블 2개로 다대다 관계를 표현할 수 없기 때문에 다대다 관계를 일대다, 다대일 관계로 풀어내는 연결 테이블을 사용하지만 객체는 테이블과 다르게 객체 2개로 다대다 관계를 만들 수 있음

@Entity
public class Member {
    @Id @Column(name="MEMBER_ID")
    private String id;
    
    private String username;
    
    @ManyToMany
    @JoinTable(name="MEMBER_PRODUCT", 
               JoinTable = @JoinColumn(name="MEMBER_ID"),
               inverseJoinColumns = @JoinColumn(name="PRODUCT_ID"))
    private List<Product> products = new ArrayList<Product>();
    ...
}

@JoinTable.name
연결 테이블을 지정
@JoinTable.joinColumns
현재 방향인 회원과 매핑할 조인 컬럼 정보 지정
@JoinTable.inverseJoinColumn
반대 방향인 상품과 매핑할 조인 컬럼 정보를 지정

➡️ @ManyToMany로 매핑 시, 다대다 관계를 사용할 때 연결 테이블을 신경쓰지 않아도 되기 때문에 복잡한 다대다 관계를 애플리케이션에서는 아주 단순하게 사용 가능

2. 양방향

역방향 추가

@Entity
public class Product {
    @Id
    private String id;
    
    @ManyToMany(mappedBy = "products") //역방향 추가
    private List<Member> members;
    ...
}

역방향 탐색

public void findInverse(){
    Product product = em.find(Product.class, "productA");
    List<Member> members = product.getMembers();
    for(Member member : members){
        System.out.println("member = " + member.getUsername());
    }
}

3. 다대다: 매핑의 한계와 극복, 연결 엔티티 사용

@ManyToMany를 사용하면 연결 테이블을 자동으로 처리해주기 때문에 도메인 모델이 단순해지고 편리해진다

하지만 컬럼이 추가되면 더는 @ManyToMany를 사용할 수 없다

결국, 연결 테이블을 매핑하는 연결 엔티티를 만들고 이곳에 추가한 컬럼들을 매핑해야 함

복합 기본키 사용
- @Id : 기본 키를 매핑
- @JoinColumn : 외래 키를 매핑
- @Id + @JoinColumn 을 동시에 사용하여 기본키 + 외래 키 한번에 매핑
- @IdClass : 복합 기본키 매핑
JPA에서 복합 키 사용 시 별도의 식별자 클래스 생성 필요
- 복합 키는 별도의 식별자 클래스로 만들어야 함
- Serializable 구현 필요
- equals와 hashCode 메소드 구현 필요
- 기본 생성자 필요
- 식별자 클래스는 public 이어야 함
- @IdClass를 사용하는 방법 외에 @EmbeddedId 사용하는 방법도 있음
식별관계
- 부모 테이블의 기본 키를 받아서 자신의 기본 키 + 외래 키로 사용하는 것
- 데이터베이스 용어

4. 다대다: 새로운 기본 키 사용

데이터베이스에서 자동으로 생성해주는 대리 키를 Long 값으로 사용하는 것을 기본 키 생성 전략으로 추천함

장점
- 간편함
- 거의 영구히 사용 가능
- 비즈니스에 의존하지 않음
- ORM 매핑 시 복합 키를 만들지 않아도 되므로 간단히 매핑 완성 가능

5. 다대다 연관관계 정리

식별관계
- 받아온 식별자를 기본 키 + 외래 키로 사용
- 부모 테이블의 기본 키를 받아서 자식 테이블의 기본 키 + 외래 키로 사용하는 것
비식별관계
- 받아온 식별자는 외래 키로만 사용
- 새로운 식별자 추가
- 단순히 외래 키로만 사용하는 것
비식별 관계를 추천함

[PyCon] PyCon 2024 후기

지니(jineey) — Sun, 17 Nov 2024 18:59:13 +0900

파이콘 10주년 기념

소개

파이콘(PyCon)

https://2024.pycon.kr/

파이콘 한국 2024

2024.pycon.kr

날짜: 2024년 10월 26일 - 27일
장소: 수원 컨벤션센터 3층

세션 시간표

1일차

2일차

인증샷1

인증샷2

같은 날 수원 컨벤션센터에서는 펫축제가 열리고 있어서 많은 강아지들이 가득가득

눈으로 귀여움을 잔뜩 담고 3층으로 이동하니, 접수처와 많은 후원사 부스들이 있었다.

접수처에서는 이름표와 많은 굿즈들을 주었고 티켓 구매 했을 때 함께 구매한 티셔츠도 함께 수령할 수 있었다.

그리고 옆에서는 티셔츠, 후드집업 등 다양한 굿즈들을 추가 판매하고 있었는데 후드 집업이 너무 예뻐서 바로 구매!

후드집업 인증샷

토스, 크림, 두레이 등 다양한 후원사 부스에서 이벤트 참여하고 선물도 많이 받아왔다.

추가적으로 커뮤니티에서도 다양한 행사들을 홍보해서 나중에 참여해보려고 안내 책자들도 잔뜩 받아와서 두손 가득 짐을 들고 행사에 참여했다.

행사는 동일한 시간에 3개의 홀에서 각각 다른 세션을 발표하는 방식으로 진행됐다.

미리 공개된 세션 발표 주제를 보고, 본인이 흥미있고 궁금한 세션을 들으러 가면 된다.

나는 양일 모두 참석했고, 다음과 같은 세션에 참석하였다.

주니어이자, 자바 개발자인 나는 모르는 내용이 가득했지만 모두가 눈이 반짝반짝한 채로 열정 가득히 발표를 하고 세션을 경청하는 모습에 덩달아 기분 좋은 자극이 되었고 파이썬이 어떠한 언어이고, 어떻게 쓰이는 지에 대해 조금이나마 이해할 수 있는 계기가 되었다.

1일차

⌜S⌟SDLC - Integrating AI for Proactive Security in Python Development

️ 심의팅 / Noflag

1. The Power of code security & AI

OWASP TOP 10 ISSUE

2. Insecure Coding in Python

Unsafe programming - RCE, SQLI, Pickle module unsafely deserializes objects, unexpected behavior

3. Leveraging AI for Vulnerability Detection

Baking a generative AI Application
About fine-tune
Cloud Setting
About RAG
Choosing a method for training your model
Safety filtering per request
Local RAG with Gemma: 7B

4. Importance of SSDLC an Closing Remarks

when will the information security vuln be fixed?
Risk level
- High : Lower probability. Higher risk if it occurs
- Low: Low probability and low risk
- Critical: High probability and High risk of impact
- Medium: High probability but low risk
Creating a secure program development cycle: gatekeeping at every step ..

FastAPI with Dependency Injector

️ 한바름

1. 의존성 주입, 의존성 주입 프레임워크

의존성 주입
- 소프트웨어 개발에서 중요한 디자인 패턴
- 객체 지향 프로그램에서 객체 간의 의존성을 관리하는 방법
- 객체는 자신이 필요한 의존성을 외부에서 주입 받을 수 있음
- 코드의 재사용성이 높아지고, 테스트 가능성과 유지보수성이 크게 향상
도우미 함수(helper function)
- def bbbb (aaaa: Callable = xxxx) -> …
파이썬은 함수도 객체이기 때문에, 클래스 외에도 함수에 의존성 주입도 가능
- 하나의 함수로 다양한 세션 적용 가능
- 재사용/관리 가능
의존성 주입 도입 결과
- 의존성 객체가 어떻게 생성되는지 몰라도 됨
- 의존성 객체 변경이 클라이언트 객체에 영향이 없음 (=결합도 낮아짐)
- 의존성 객체의 라이프 사이클이 클라이언트 객체와 분리
- 의존성이 변하는 케이스 대응
  - 클래스 생성자 Args 변경
    - Engine() → Engin(fule_type=”Gasoline”)
  - 클래스 타입의 변경

2. 의존성 주입 시 달라지는 점

의존성 외부에서 관리 (기존: 클라이언트 객체 생성만 하면, 의존성은 내부에서 생성)
의존성 객체 라이프 사이클 관리 (기존: 클라이언트 객체 스코프에 의존성 객체 라이프사이클 종속)
도우미 함수 필요 (선택)

3. 의존성 주입 프레임워크란?

의존성 주입 편의성 지원
의존성 생성 관리(초기화 정보들, 의존성 생성타입)
의존성 및 의존성이 주입된 객체 생성 역할

4. FastAPI의 의존성 주입

Depends()
- 개념
  - 의존성 생성 함수 등록
  - 의존성 필요 시 의존성 생성 함수 호출
  - Caching 지원
  - 요청 처리 시 중복 로직 처리
- 단점
  - FastAPI 종속
  - Depends 사용한 의존성 주입만 교체 지원
Dependency Injector
- 장점
  - 상세한 문서
  - 의존성 주입 다양한 케이스 지원
  - FastAPI 비종속
- 단점
  - 러닝커브 존재
  - 에러 지원 빈약
  - FastAPI Depends() 완전한 대체는 아님

5. 적용후기 및 정리

이슈
- 완전한 프레임워크는 아님
- 컨테이너 사용하는 모듈간 순환 참조 가능성
- closure function 함수 주입은 안됨
- 문서대로 해도 동작 안하는 경우도 있음

SpringBoot 하던 사람이 Django 찍먹 해 봄 : 저의 적응기를 공유합니다

️ 이지훈

1. 소개

주요 기술
- JAVA
- Spring/SpringBoot
- JPA
10년차
JAVA 개발자

2. 계기

이직 → 파이썬 주 언어 회사
Flask 로 되어 있던 웹 프레임워크를 Django 전환할 필요성을 팀 내에서 합의
팀 전체 러닝커브를 줄이기 위해 Django 튜토리얼 가이드의 작성 필요성
Django 토이 프로젝트 시작
- 기능: 질문 / 답변 / 회원가입 / 로그인(토큰 발급) / 추천(질문&답변)

3. 개발

개발 프로젝트 셋업
- Django 사용 시
  - Django 문서와 팀 동료 도움
  - 공식 문서의 ‘시작하기’ 페이지 활용
  - 유저 가입 기능 → Django Admin 기능 활용
  - user 앱 추가 후 setting.py 기본 사용자 모델 커스터마이징
  - user 모델 추가, UserAdmin 모델 추가
  - 장고 기본 설정인 BasicTokenAuth를 그대로 사용
- SpringBoot 사용 시
  - Spring 공식 문서 참고
  - SpringSecurity 선택
  - 라이브러리 Dependency SpringSecurity 업데이트
  - SecurityConfing로 Security 설정 초기화
    - UserDetailService 초기화
    - PasswordEncoder 초기화
  - 순환참조 오류 발생…..
    - 원인: configureGlobal 메서드와 filterChain 메서드에서 서로 PasswordEncoder를 참조하려고 하면서 순환 참조 오류 발생
    - 해결: Lombok 을 활용해 @ Lazy 를 사용하여 configureGlobal 메서드의 PasswordEncoder 에 작성 → 지연 초기화 혹은 configureGlobal를 제거하고 USerDetailService를 상속받는 클래스를 직접 구현
토큰 발급 API
- Django 사용 시
  - view 단을 앱별로 모아서 관리하기 위해 API 앱 구현
    - 관심사 분리
    - 유지보수성과 가독성 향상
  - User 폴더 추가
  - serializers 추가
    - 직렬화, 역직렬화
  - view에 function view 방식으로 ObtainTokenView 구현
    - 로그인 성공 시 토큰 발급, 로그아웃 시 토큰 삭제
  - Serializer 와 view 에 대해 단위 테스트 코드 작성
- SpringBoot 사용 시
  - Spring MVC 패턴에 따라 Controller/Service/Repository/DTO/Entity 계층별로 클래스 구성
  - 테스트 필수 계층 테스트 코드 작성
    - Controller
    - Service
  - 나머지 계층에도 테스트 코드가 필요하다면 해당 부분에 추가 작성
  - 하나의 API를 완성하기 위해 작성된 파일 총 10개, 총 라인 400줄, 글자수 1000자 이상
- URL 및 접근 권한 관리
  - Django 사용 시
    - 프로젝트 내의 urls.py 파일만 찾아다니면 어떤 URL로 구성되어 있는 지 한눈에 파악 가능
    - api 접근 권한은 api 별로 구현단에서 직접 지정할 수 있도록 함
    - 특정 리소스에 대한 일괄 접근 제한은 따로 구성해보지 않음
  - SpringBoot 사용 시
    - 각 Controller에 작성된 api에 URL 지정
    - 전체를 한눈에 파악하려면 외부 툴(swagger)이나 IDE의 도움 필요
    - api별로 접근 제한 설정
      - @PreAuthorize(”hasRole(’ADMIN’)”)
    - 특정 리소스에 대한 일괄 접근 제한은 Security에서 구성 가능
    - 우선순위는 Security가 우선 적용됨.

4. SUMMARY

프로젝트 셋업과 구조
- Django
  - 단일 urls.py 파일을 통해 URL을 중앙에서 관리
  - 접근 권한을 각 API에서 직접 제어 가능
  - 유지보수성과 가독성이 높음
- SpringBoot
  - 각 컨트롤러에서 URL 지정
  - Security 설정에서 일괄 접근 제어 및 각각의 엔드포인트에서도 접근 제어 가능
  - 다양한 요구사항에 맞춘 세밀한 제어 가능
API 구현과 테스트
- Django
  - 프로젝트 구조가 간결
  - serializers와 view를 통해 효율적인 API 구현 가능
- SpringBoot
  - 계층화된 구조로 인해 더 많은 파일과 코드 라인 필요 → 유연성과 확장성 뛰어남
  - 테스트 코드 작성에서도 SpringBoot는 더 많은 계층에 대해 테스트 필요

Django의 DB Connection과 Transaction 관리

️ 명세균

1. 소개

토스 백엔드 개발 6년차
장고로 첫 개발 시작

2. Django의 DB Connection 관리

QuerySet 실행 과정
Connections 이란?
- BaseConnectionHandler
  - 장고 DB Connection은 스레드/코루틴 task 단위로 DB_ALIAS별로 생성될 수 있음.
- ConnectionHandler
  - BaseConnectionHandler 상속받음
  - 간단한 세팅함수와 현재 설정된 DB

3. DB Connection 종료

request_started, request_finished 의 시그널에 close_old_connections 함수
DatabaseWrapper 인스턴스에 할당된 close_at에 시간보다 현재시간이 크면 종료
close_at 은 설정 가능 (CONN_MAX_AGE = 0: / = n: / = None: )

4. DB Connection 유의점

MySQL server has gone away
- 원인
  - wait_timeout 보다 더 긴 시간동안 커넥션 쿼리가 발생하지 않으면 커넥션 종료
  - Django 서버가 그 사실을 모르고 종료된 커넥션에 쿼리를 호출하면 에러 발생
- 해결방법
  - CONN_MAX_AGE 는 DB 서버의 wait_timeout 보다 짧게 설정해야 DB 서버가 끊은 커넥션에 쿼리를 날리는 불상사 예방 가능
- 예외
  - CONN_MAX_AGE 값에 의해서 커넥션이 종료되는 시점은 request_started, request_finished 시점
종종 만나는 커넥션 문제
- 상황
  - 요청이 아닌 오래 걸리는 배치에서 쿼리가 나가는 상황
  - 요청이 아닌 오랫동안 실행되는 컨슈머, 워커에서 쿼리가 나가는 상황
  - CONN_MAX_AGE보다 요청이 오래 걸리는 상황
- 해결방법
  - Health_check_enabled
  - CONN_HEALTH_CHECKS → 매번 ping을 날리게 되어 오버헤드 있음.
장고의 CONN_MAX_AGE 개선
- self.close_if_unusable_or_obsolete()
  - cursor를 반환할 때 CONN_HEALTH_CHECKS를 사용하지 않고 CONN_MAX_AGE가 더 잘 동작하도록 가능
  - cursor 반환 전에self.close_if_unusable_or_obsolete()코드 추가
Aborted connection xxx to db
- graceful하게 커넥션을 정리하고 서버가 내려가지 않음
- CONN_MAX_AGE를 wait_timeout 보다 짧게 설정하더라도 CONN_MAX_AGE가 지난 시점에 딱 커넥션을 종료해주지 않음

5. Transaction 관리 방법

using
savepoint
- default 값이 True이기 때문에, 기본적으로 트랜잭션 블록이 중첩되면 savepoint를 찍게 됨
- 내부 트랜잭션에서 발생하는 에러를 제어하지 않으면 외부 트랜잭션까지 에러가 전파 되어서 전부 롤백이 되기 때문에 에러를 잘 핸들링하지 않으면 savepoint가 무의미해짐.
attribute → 현재 커넥션의 트랜잭션 상태 제어 가능

6. Transaction 이슈 경험 공유

savepoint 이슈
- MySQL의 events_statements_summary_ … 테이블

7. 결론

CONN_MAX_AGE
쓰레드/코루틴 task 단위
savepoint

거의 모든 파이썬 이용자를 위한 거대언어모델(LLM)의 활용

️ 박상현(David)

1. LLM이란?

Large Language Model
- Language
  - 자연어, 프로그래밍 언어, …
- Model
  - 규칙 혹은 문법에 맞게 배열된 데이터들
모델에 입력한 토큰들로 다음 토큰 예측
- 아주 거대해서 성능이 좋은, 입력 토큰들의 다음 토큰을 예측하는 함수.
- 파이썬의 랭체인

2. LLM과 대화하기

대화의 개념은 없음
이전의 대화(prompt)를 넣어줘서 대화의 형식을 유도 → prompt을 쌓아감.
- 메모리 크기 관리 필요
이미 기존에 쌓인 메모리 활용?
- 기존 대화 이어가기
- RAG
  - 검색 → DB → 정보 → context

3. LLM과 일하기

할루시네이션(Hallucination) 문제
- 다음 토큰을 예측하여 글을 작성하는 능력만 있을 뿐, 정확하거나 올바른 데이터가 나오는 건 아님.
String(알고 있는 문자열) → LLM → String → 모르는 문자열 → 문자열 처리 → 원하는 문자열
- 입력값 외에 정확히 알거나 컨트롤 가능한 문자열이 없음.
- String(알고 있는 문자열)에 알고 있는 문자열+알고 싶은 문자열 템플릿 제공
- 예시
  - 역할 암시: 너는 인공지능 챗봇이야.
  - 답변 구조: CoT (LLM이 던지는 작은 의문(생각을 곱씹는 과정)을 토대로 결과를 도출하도록 생성)
  - 도구이름, 도구 입력
    - 도구: 인간이 미리 짜놓은 함수 (= 파이썬 함수)
    - 현실에서 존재하는 실제 함수(지식)를 사용. (학습한 내용에서 벗어남)
LLM은 다음 토큰을 재귀적으로 호출
해당 과정은 랭체인의 Agent에 구현되어 있음.

4. 랭체인(LangChain)

함수의 이름, 입력값의 형태, docstring 등의 정보를 문자열로 반환
LLM 응답의 JSON 형식 문자열을 파싱하는 파서 구성
생성을 중단할 stop word 설정
LLM이 사용할 도구 이름들 설정
- 함수의 이름을 신중하고 상세하게 선정
Context를 담은 프롬프팅에 사용할 메모리 설정
LangChain Hub
- 여러 템플릿 참고 가능

2일차

자동화된 파이썬 웹 프레임워크 API Schema 제작기: The long way around

️ 조규진

1. 소개

레블업 주식회사
백엔드 개발자
RestAPI, DB 설계, 컨테이너 설계 등 담당

2. API 문서 자동화: 도입 배경

Backend.AI는 REST API 및 GraphQL API를 병행하여 사용
그동안 Backend.AI의 API 문서는 구현을 담당한 사람이 별개의 문서 파일을 임의로 채워 넣음
- 많은 부분을 놓침

3. 그동안 문제가 되지 않았던 경우

서드파티 API 호출 수요 부재
- 대부분의 고객들은 Backend.AI의 퍼스트 파티 프론트엔드인 WebUI 사용
- 고객이 직접 API를 이용하여 Backend.AI의 기능에 접근할 일이 없었음
작은 개발팀의 규모
- 대부분의 개발팀이 그동안의 API 히스토리를 이해하고 있었음
- 타 부서에서 백엔드 개발자에게 물어보면 되는 정도로 충분했음

4. 새롭게 등장한 과제들

API 연동 수요 증가
- Backend.AI가 제공하는 API를 가공하여 새로운 형태의 제품을 만들고자 하는 고객 등장
- 기존 고객의 API 수요 심화
  - 모니터링, 빌링 연동 등등…
사람이 늘어나고 코드 베이스가 방대해지면서 기존의 소통 방식으로는 한계에 봉착

⇒ 비대면 소통(비동기 소통)을 가능하게 만들기 위해 문서화가 필요하다는 결론이 나옴.

5. 요구사항

모든 RESP API Route에 대해 OpenAPI 형식의 API Schema 출력
- 기존의 API Handler에 손대지 않고도 문서화 가능해야 함

6. FastAPI를 선택하지 않은 이유

FastAPI를 선택하지 않은 이유

FastAPI를 사용하기에는 11만줄의 코드 베이스를 가지고 있음
10년이 넘은 레거시 소스임.
OpenAPI Spec
- REST API를 구조화하여 표현하기 위해 등장한 개념
- API의 메서드, 리소스, 인증방식 등의 다양한 스펙 정의 가능
- JSON Schema에 REST API에 득화된 독자 정의 추가하여 탄생
- 3.1은 JSON Schema와 100% 호환

7. 구현

정적분석
- 분석
  - Backend.AI Magager의 API Handler 정의 코드는 형식이 정형화 되어 있음
  - 그러니 ast 모듈을 이용해서 정적분석 시도
  - 소스코드 예시: Tech Stack
  - Python ast Module
    - 파이썬의 빌트 인 라이브러리
    - 파이썬 코드를 Abstract Syntax Tree 형식으로 해석하거나, 반대로 구조화된 AST를 파이썬 코드로 변환하는 기능 제공
    - 짜여진 파이썬 코드를 정적 분석 가능
- 실행
  - 모든 API Handler가 담긴 소스 코드를 AST로 변환
  - Tree Traversal을 위해 AST → XML 로 재변환
  - 정형화된 XML Path를 따라 모든 Handler의 구조를 순회하여 함수명, Request body 형식 수집
- 장점
  - API 구현체가 의존하는 외부 패키지 설치 필요 없음
  - 빠름
- 단점
  - 노가다에 가까운 경로 설정
    - 유지보수 불가능
    - 상대적 경로 (XML Path)
    - API Handler의 선언 형식이 바뀌면 대응이 어려움
    - 한없이 낮아지는 코드 가독성
  - code base에 도배되게 됨
동적 분석
- 분석
  - 모든 API Handler들의 entrypoint
  - aiohttp Application 객체의 내용을 동적으로 분석
  - aiohttp.web.Application
    - entrypoint
      - 모든 Handelr 들이 이 객체 안에서 정리됨
- 실행
  - web.Application 객체의 router.routes() 메서드를 이용해 등록된 모든 Route Handler 를 순회
    - 함수명 등의 정보 가져옴
  - set_handler_atttr(wrapped, “request_schema”, checker)
- 장점
  - 사람의 언어로 쓰여진 Spec generator를 만들 수 있음
- 단점
  - Backend.AI의 의존성 설치 필요
    - aiohttp, aiodocker ..
- Trafaret 한계
  - OpenAPI 스펙으로의 자동 변환 미지원
  - primitive type이 어떤 API 형식으로 정의되는 지를 모두 정의 필요
  - 응답 데이터에 대한 타입 정의를 추가 필요
    - pydantic 도입
      - Trafaret에 비해 Python typing 친화적
      - 추가적인 구현 없이도 Open Spec 변환 가능
      - typnig.get_type_hints() 함수를 사용하여 파이썬 객체의 타입 힌트 정보를 동적으로 가져올 수 있음

8. 결론

보완필요한 점
- 다양한 Response Code 정보를 알려줄 필요가 있음
- 모든 API Hander를 Pydantic으로 변환 필요
레거시가 많지 않다면 FastAPI 권장

Python ASGI 서버 구현기 with Pyo3

️ 민태인

1. 소개

NavyTree CTO
- 배우들 오디션 숏폼 제작
장고로 입문
PyCon 2019년 ~

2. 프로젝트 소개

grais-asgi
- Rust Asyncronous Server Gateway Interface의 두문자 에너그램
- Python asyncio 생태계와 잘 호환되면서 높은 성능이 높음
- grais
  - Rust 기반의 ASGI 서버 구현체
    - Uvicorn, hypercorn과 동일한 역할
프로젝트를 시작하게 된 계기
- 짐 캘런
  - “본질을 이해하는 사람들은 극소수다.”
- [low level] 드라이버 - 운영체제 - 네트워크 프로토콜 - ASGI - 애플리케이션 [high level]
  - 네트워크 프로토콜, ASGI에 지식이 부족함을 느낌
  - 부족함을 채우고자 프로젝트 진행
- 한국에서 오픈소스가 나왔으면 좋겠다는 희망
  - 새로 만들고, 써보고, 피드백을 요구하는 Pycon 강연들이 많아지길 바람.
  - 본인이 먼저 행동하게 됨.

3. 사전지식

Rust
- 시스템 프로그래밍이 주 목적
- 타입 시스템으로 컴파일 시간에 메모리 안정성을 보장
  - 변수의 수명(lifetime) 추척
  - 예외 처리대신 에러 반환
- 어려운 난이도
바인딩
- 프로그래밍 언어가 해당 언어에 네이티브하지 않는 외부 라이브러리나 운영 체제 서비스를 사용할 수 있도록 만들어주는 글루 코드를 제공하는 API
- Pyo3
  - 가장 많이 쓰이는 Python-Rust 바인딩
  - Pydantic 등에 사용 많이 됨

4. 시행착오

[구현기1] asyncio.Protocol를 Rust로
- 이유
  - 속도를 최대로 하기 위함
- 단점
  - 무수한 lifetime 에러로 컴파일되지 않음
  - Python 호출 코드가 많아짐
  - Python으로 일부를 옮기고자 함.
[구현기2] HTTP 프로토콜과 asyncio.Porotcol 구현 분리
- Rust는 HTTP 프로토콜에만 집중
- 데이터 송수신, 흐름 제어는 파이썬으로
- 상태머신 기반
- 장점
  - Lifetime 문제 해결
- 단점
  - pyo3 한계상 코드가 살짝 난해하고 지저분함
[구현기3] 복잡한 단일 구현 나누기
- 너무나 비대해진 Http11Connection
- ASGI 순서에 따라 단계 나눔
- scope 처리
[구현기4] 사용성
- 핫 리로드, 앱 예외처리, graceful-shutdown …
- 편리함을 위한 CLI 인터페이스
- 문서화

5. 느낀 점

직접적으로 상관없는 애플리케이션을 개발할 때도 이해도가 올라간 느낌
도전을 응원하고 발표하는 기회를 많이 가졌으면 함.
- 새로운 웹 프레임워크, DI 프레임워크 (개인적으로 추천!)

6. QnA

Q. CTO 병행하면서 어떻게 구현을 했는지? 그리고 어느 시간에 주로 작업했는지?

A. 초기 시작 때엔 CTO가 아니었음.

한 달~ 한달 반정도 작업, 주로 밤~새벽에 작업함, 3~4시간씩 작업함.

Python Backend에 클라우드를 더하다

️ 황정식 / Huston

1. 소개

백엔드 엔지니어
장고 메인
SecondSyndrome 회사에서 Kotlin 등 사용

2. DRF 백엔드 개발의 장/단점

장점
- 장고와 함께 Django Integration을 지원하는 여러 라이브러리 활용
- 빠른 웹 서비스 비즈니스 로직 개발 가능
- 협업하기에 좋음
단점
- 빠르게 개발을 할 순 있지만 성능에 대한 챌린지가 많음
- 대량 트래픽 발생에 약한 모습을 보여줌
  - Gunicorn - workers : 성능은 코어수 * 4개까지 가능
  - GIL 등..
DRF Backend 개발의 단점
- 단일 트랜잭션으로 보면 DRF도 크게 떨어지지 않음
- 글로벌 기업에서도 Python을 활용하여 백엔드 개발 가능성을 봄.

⇒ 클라우드를 사용하여 단점 극복하려 함. (성능 개선, 가용성 높임, 파이썬의 장점 유지)

3. 모빌리티 서비스

(차량 대여/반납 오버헤드 이슈와 해결)

설명
- 초소형 전기차 대여 서비스
- 앱: 회원/예약/대여/차량제어/반납
- On-Board-Diagnostics(차량 자가 진단 장치) - Provider Server(외부 서버) - OPEN/CLOSE
- 서비스: 유저관리 / 차량관리 / 결제관리 / 대여관리 .. 등
  - 주로 DB에 데이터를 넣고 빼는 기능
이슈
- 차량 관리/제어에서 성능 이슈가 생김 (메인 기능 ㅠㅠ)

이미지1

문제사항
- 응답 대기상태 (응답에 30s 소요)

이미지2

➡️ 응답 대기상태에서 신규 응답이 생기면 앱이 동작하지 않음

비동기 처리
- Celery & Beat
  - 불확실성을 AWS의 Lamda 사용하여 해결
  - 속도 개선
    - Lamda 사용 전(기존)

이미지3

Lamda 사용 후

이미지4

결과
- 응답 시간 단축 (약 8~9s)

이미지5

4. 파이썬 장점

빠른 구현
- 불확실한 요소가 많지만 고민하는 시가능ㄹ 아껴 빠르게 구현 시작 가능
상각하는 대로
- 파이썬 백엔드에게 친숙한 파이썬 스크립트를 개발해서 창의력이 생김
문제 해결
- 문제를 쉽고 빠르게 해결할 수 있는 장점

5. 메시징 서비스 개발

AS-IS 분석하여 TO-BE 요구사항 확인
- 요구사항
  - 메시지별 다른 서비스
    - Push: Firebase
    - SMS: N사
    - KAKAO: I사
  - 스케줄링 이슈
    - 즉시발송, 예약발송 필요
    - 고객별 메시지 내역 기록
  - 이미 있는 코드 활용
    - 발송 스크립트를 활용하여 개발 기간 최소화
- 결론
  - 기존 코드를 최대한 활용하여 스케줄링 기능 추가
    - 특정 서비스로 모두 이관하여 개발 불가능
    - 서비스에서 제공하는 스케줄링 활용 불가능
    - 레거시 파이썬 스크립트는 최대한 수정없이 사용
  - 개발 요구사항에 스케줄러도 추가
    - AWS에서 EventBridge 스케줄러 사용
아키텍처 구성 전, PoC 작성
- One-time schedule 가능한 지, 얼마나 걸리는 지 검토
- 가능성이 보여 진행하기로 결정
아키텍처

이미지6

6. 결론

파이썬은 다음과 같은 자신의 성격과 잘 맞아서 좋음.
- 상상하는대로 재밌는 것을 구현하고 싶음
- 빨리 구현해서 사용해보고 싶음
- 어떤 새로운 걸 활용하고 싶음
파이썬과 클라우드를 활용하여 한계를 극복하는 경험 가졌으면 좋겠음

오픈소스 프로젝트 - 코드 0줄부터 스타 1.3k까지

️ 김동규

1. 소개

AutoRAG CEO (Co-Founder)
RAG 연구원
디지털 노마드
2번의 창업 경험 (이번이 3번째)

2. AutoRAG란?

Star History 에서 참고 가능 (1월 오픈 ~ 현재 1.9k까지 성장함)
RAG란?
- Perplexity 에서 질의응답 시, 최신의 정보가 없어서 정확한 정보를 답변하지 못한 GPT와 달리 정확한 대답을 함.
  - Perplexity : RAG 사용하여 ChatGPT와 동일한 기능을 함.
- 정확한 정보를 넣어주는 기술
  - LLM이 알았으면 하는 문서를 RAG에 넣어주면, 질문에 따라 알맞은 문서를 RAG가 찾아 LLM에 제공
  - private하거나 domaintic한 정보를 LLM이 활용할 수 있도록 하는 기술
- 문서 더미에서 필요한 정보를 검색하여 LLM이 가지고 있던 정보를 전달함.
RAG를 만들 때 큰 문제
- 데이터셋을 만들 때마다 달라짐.
  - 모든 문서에 좋은 방법이 없음
  - 각 문서마다 성능이 드라마틱하게 다름
  - 각각 적합한 방법을 찾아서 적용해야 함
- 적합한 방법론이 무궁무진하게 많음
  - 랭체인 혹은 라마인덱스에 구현되어 있는 것들은 빙산의 일각
  - 모든 것을 직접 구현하고 성능을 측정해서 최적화하기엔 너무나 많은 시간 소요
AutoRAG이란?
- RAG 자동 최적화 툴
- 수많은 RAG 실험을 효율적으로 편하게 하도록 자동화
- YAML 설정파일만으로 여러 RAG 모듈을 자동 최적화
- 문서로부터 평가 데이터셋 자동 생성
- 직접 구현하지 않아도 최적의 RAG 조합을 찾음

3. 어떻게 오픈소스 프로젝트를 성장시켰는가?

오픈소스 홍보 방법
- 커뮤니티 등에 홍보
  - 한달동안의 최소한의 기능 구현 후 런칭
  - 긱뉴스, 레딧, 아카라이브, 해커뉴스 등
    - 긱뉴스, 레딧에서 좋은 반응 → 200개 정도의 스타를 받음.
    - 기대했던 해커뉴스에는 좋은 반응을 얻지 못함.
- 링크드인 활동 시작
  - 링크드인으로 관련 업계 사람들에게 쉽게 도달 가능
  - 최초에는 짧은 글을 올림 (단순 홍보)
  - 요즘에는 개발 블로그를 작성 후, 해당 블로그의 짧은 요약과 함께 공유
  - 라마인덱스 CEO에게 DM 및 일촌 신청
    - 라마인덱스를 사용하여 개발중임을 Git Link와 함께 DM을 보냄
    - 라마인덱스 SNS에 AutoRAG가 홍보된 것이 결정적인 계기
  - 최근에 또 다른 관계자에게 홍보가 되어 1.7k → 1.9k 로 성장
- 직접 발표하기
  - Open-Source Gen AI Tools Demo Day에서 발표 → 스타 900개
  - AI 전문 유튜버 테디노트님의 라이브 참여
    - 한국 RAG 커뮤니티에서 알려지게 됨
    - 스타 1k 달성
  - 이후 링크드인, 컨퍼런스, 개발 블로그 꾸준히 하고 있음
- 홍보에는 왕도가 없음을 알게 됨
  - 일회성이 아닌 꾸준히 유입될 수 있는 컨텐츠를 늘리는 것이 중요
  - 자신의 속도에 맞춰서 천천히 하지만 꾸준히 홍보 필요

4. 오픈소스를 하면서 힘들 때

반복되는 문서화
- 오픈소스는 문서화가 생명
  - 불특정 다수가 보는 문서
  - 문서가 없으면 오픈소스를 활용 불가능
사용자 파악이 어려움
- 누가 얼마나 쓰는지 파악이 어려움
- 깃허브 스타가 곧 사용을 의미하지 않음
- Contribute나 디스코드 질문 등만으로 사용자 파악 가능
- 전체 사용자 중에 일부만 볼 수 있는 기분 때문에 허무할 때가 있음
반복되는 질문에 지침
- FAQ 등을 만들어두어도 반복되는 질문들이 있음
- 문서화 및 코드 로직 수정 등으로 고치려고 노력중
수익화 되지 않음
- 현재는 사업화 진행중(일부 기능 유료화)

5. 오픈소스를 하는 이유

개발자는 ‘오픈소스’를 좋아하기 때문
- 오픈소스 홍보는 ‘홍보가’ 아닌 ‘정보 공유’ 같이 받아들여지기 때문
- 부담없이 프로젝트 정보가 퍼질 수 있음
외부 기여
- 현재 Full-time 개발팀 인원은 3명
- 이슈와 생각하지 못한 버그에 대응 가능
- 오픈소스이기에 버그를 리포트 받을 수 있음
- 외부PR을 적극적으로 수용 가능
- 사례
  - 후쿠오카 개발자가 Full-Request 요청
  - 모든 프롬프트를 일본어로 번역
  - 2개국어(영어, 한국어) 지원 → 3개국어(영어, 한국어, 일본어) 지원으로 확대
시작하기 쉬움
- 오픈소스의 퀄리티 요구는 생각보다 낮아 최소 기능으로 검증 가능
  - 검증: 깃허브 레포 만드는 것.
- 최초에 12개의 모듈 → 현재 50개의 기능으로 확대함

6. 정리

다양한 분야의 오픈소스가 활성화되었으면 좋겠음

해커의 관점에서 바라본 Django Framework

️ 윤석찬

1. 소개

경희대 컴공과
Python / Django Security Contributor

2. Django가 제공하는 기본적인 보안 기능

XXS Protection
- Cross-Site-Scripting 웹사이트에 악성 스크립트를 삽입하는 공격 방법
- 주로 HTML, JS 같은 언어를 이용해 악성 스크립트 삽입
- 사용자로 하여금 의도하지 않은 행위를 하게 만드는 위험 있음
SQL Injection Protection
- DB 쿼리에 악성 SQL 코드를 삽입하여 데이터를 조작하거나 탈취하는 공격 방법
- Django ORM 기능으로 SQL Injection 보호
- 버전에 따라 지원 안될 수 있음
CSRF Protection
- CSRF: 사용자가 자신의 의지와는 무관하게 악의적인 요청을 보내도록 만드는 웹 보안 취약점
Clickjacking Protection
- X-Frame-Options에 ‘DENY’ 설정
Password Cracking Protecction
- 디폴트로 ‘PBKDF2Passworldhasher’ 사용
- SHA256 알고리즘을 720,000번 반복 → 해커들이 쉽게 크랙하지 못하도록 함

3. 발견된 취약점

1-Day Vulnerabilities
- 1-day: 취약점에 대한 정보가 공개되고, 패치 버전이 존재하는 취약점
- 취약점 목록
  - 입력받은 값을 검증받지 않고 쿼리에 바로 넣고 실행이 되어 악의적인 쿼리 호출 가능
  - 복잡한 정규식 사용, 입력길이 제한 없음, 반복적인 패턴 → 과도한 CPU 사용으로 DoS 유발 가능
    - 강연자가 발견한 취약점!
- Conclusion
  - 최근 공개된 보안 이슈는 발생 가능성낮음
  - SQL Injection
    - 잘 사용되지 않는 기능을 사용해 트리거 됨
  - DoS
    - 비정상적으로 큰 입력값이 있어야 가능
  - 결론
    - Django는 여전히 안전하다고 확신함

4. 개발 시 주의해야할 점

XXS
- 응답 시, HttpResponse()를 사용하는 경우
  - 장고의 템플릿 필터를 사용하지 않기 때문임.
  - 사용자가 입력한 값이 코드에 삽입됨
- 템블릿 필터 ‘safe’를 사용하는 경우
  - 데이터가 안전하다고 가정하고 진행하기 때문에 악의적인 사용 가능
- 템블릿 필터에서 ‘autoescape off’ 사용
- URL 형식 검증이 없는 경우
  - 허용된 프로토콜만 사용 가능하도록 제한 필요
SQL Injection
- Raw SQL 이용 시 안전하지 않은 방법으로 사용자 입력이 포함되는 경우
  - String Concatenation, Format String, …
  - Order by 구문 사용 시 주의 필요
- 장고를 2022년 이후 업데이트를 하지 않은 경우
Third Party Library
- Exploitable Third-party Modules
  - Django-rest-framework, etc …
    - 강연자가 Django-rest-framework 에서 중급 정도의 취약점 발견
- 정기적으로 라이브러리 업데이트 필요
- 보안 문서 및 코드 리뷰 확인 필요
Regular Expression Denial of Service
- 백트래킹을 많이 유발하는 복잡한 정규표현식 패턴 사용
SSRF
- 공격자가 의도하지 않은 대상에 서버 측 요청을 할 수 있도록 허용하는 취약점
- 내부 리소스에 대한 무단 액세스로 이어짐
  - 서버를 프록시처럼 사용하여 접근 가능
- 엄격한 방화벽 규칙 사용 필요
SECRET_KEY Leakage
- 외부 노출 시 문제가 생김
  - 세션 하이재킹
  - CSRF 토큰 위조
  - 암호화된 데이터 복호화
  - 서명된 데이터 위조
  - 애플리케이션 전체 장악
- 실제 발생한 보안 문제 발생한 사례가 많음
- PicklesSerializer와 결합하여 더 큰 문제 발생

5. 결론

Django는 안전해지고 있다
그럼에도 만능이 아니기 때문에 보안성 유의 필요
꾸준한 업데이트 필수적

6. QnA

Q. 웹개발 시 보안에 관심이 많은데, 소개해주신 패턴 말고도 최근에 있었던 이슈나 놓치기 좋은 포인트 소개 부탁

A. 최근에 프레임워크가 고도화되고 보안 취약점이 사라지고 있어서 DoS 취약점에 관심을 가지고 있음

예전에 비해 Http 파싱 등과 같이 보안 취약점이 발생하는 경우가 많음

최신 업데이트를 하는 것이 가장 중요하고 좋은 예방책임

Q. 취약점 발견은 테스트와 코드 분석 중 어떤 방법으로 발견?

A. 코드를 통해 발견함. 코드를 한두달씩 봄

Q. 코드를 어떤 방법으로 보는지? (위에서부터 차례로? 아니면 한 모듈을 잡고 보는지?)

A. 취약점이 많이 발생하는 유형이 있기 때문에, 관련 코어부터 점검함

험난한 암호화폐 세상을 여행하려는 Python 유저들을 위한 안내서

️ 이왕원

1. 소개

AI 스타트업 코디미에서 CTO
AI, Web, Blockchain 등 공부 중

2. 암호화폐 생태계 순환 원리

검증자, 빌더(개발자 등), 유저
검증자
- 블록체인 노드 유지
- 물리적인 인프라에 기여
- 해당 체인의 가상화폐를 얻음
빌더
- DApp 개발
- 프로젝트 개발 및 운영에 기여
- DApp 사용 수수료, 추가화폐 발행 등 다양한 수익모델을 얻음
사용자
- DApp 및 생태계 이용
- 가상화폐 사용을 기여함
- DApp 및 생태계 이용을 얻음
서로 상호보완적인 역할이기 때문에 생태계 유지 및 성장 가능
역설적으로는, 이 생태계가 완성되기 전까지는 이 선순환구조가 성립될 수 없다는 치명적인 문제가 있음

3. 암호화폐 에어드랍

에어드랍(Airdrop)?
- 생태계에 기여한 실유저/빌더에게 암호화폐를 주는 정책
- 재단 측에서는 초기 생태계 구성원을 끌어들이기 위해 암호화폐 에어드랍을 적극적으로 시행
에어드랍 헌터
- 에어드랍 작업만 전문적으로 함
- 생태계에 장기적으로 좋지 않은 영향을 줌
- 결국 프로젝트 측에서는 이를 악성 시빌(sybil) 공격으로 규정하기에 이름
  - 한 개인이 다수의 계정이나 노드, 컴퓨터를 구성해 네트워크를 공격하는 기법 중 하나

4. 현상금 사냥꾼

LayerZero
- 여러 체인의 자산을 통합하는 크로스체인 플랫폼
- 초기부터 꾸준하게 사용한 유저들에게 에어드랍 약속
- 시간이 흘러 자체 코인을 발행하는 시점에서 총 지갑 수가 250만 개에 육박
- 현상금 사냥꾼 제도 출범
  - 시빌공격하는 사람을 잡으면 15% 제공
대부분 여러 개의 계정을 가지고 있는 게 디폴트였기 때문에 문제가 됨
서로 제보하고 신상캐고 공개저격하는 문제가 생김

5. 파이썬을 활용한 온체인 데이터 분석/수집

현상금 사냥꾼 —> 데이터 분석과 동일함
각 트랜잭션 해시값을 비롯한 분석에 필요한 데이터 제공 (.csv)
table 데이터이기 때문에 파이썬 데이터분석 유저가 다루기 좋은 형태
- 범용적인 데이터 분석 툴(numpy, pandas 등) 사용 가능
아이디어 예시
- 실유저는 장기 이용, Sybiler들은 단기 사용했을 것이다
  - 월 별로 평균 등 디테일한 분석 필요
  - Seaborn으로 사용기간 히스토그램 시각화
- Sybil 지갑이라면 에어드랍 스냅샷 이후에 자금을 전부 회수했을 것이고, 실사용 지갑이면 계속 쓸테니 돈이 들어있지 않을까?
  - 명확하게 판별하는 기준을 이야기할 수 있으면, 어떤 수단과 방법을 동원해도 괜찮음
  - 주어진 데이터로만 분석하지 않아도 됨
  - 주어진 데이터에는 지갑 잔액 정보가 없기 때문에 web3.py로 직접 수집
    - 이더리움 호환 블록체인과 상호작용할 수 있게 해주는 파이썬 모듈
- Sybil 지갑이라면 에어드랍 스냅샷 이후에는 지갑을 사용하지 않았을 것이고, 실사용지갑이면 계속 쓸테니 트랜잭션이 계쏙 발생했을 것이다
  - 각 지갑별 트랜잭션 데이터를 집계
  - block explorer 사용하여 분석
  - requests와 같은 모듈을 사용하여 RestAPI로 직접 호출

6. 정리

24.06.15 기준, 공식 발표에 대한 Sybil 기준은 아래와 같음
- 브릿지 금액이 1달러 미만
- 대량의 지갑 사이에 일정한 트랜잭션(tx) 기록이 있는지
- 서비스 오픈 12달 이내 3번 미만의 트랜잭션 유무
- 스냅샷 이후의 트랜잭션 기록이 없는지
확실한 기준을 정립하기 어려움
- 여러 조건이 겹쳤을 때 판별하는 것으로 보완
이 과정이 유의미한 이유
- 타 도메인의 데이터분석과 크게 다르지 않음
- 난이도가 높지 않음
- 가설 및 접근 전략을 세우기 위해 도메인 지식 중요

[JPA] 자바 ORM 표준 JPA 프로그래밍 #10

지니(jineey) — Fri, 15 Nov 2024 22:10:06 +0900

개요

뱡향(Direction)
- 단방향: 관계에서 둘 중 한 쪽만 참조하는 것
- 양방향: 양쪽 모두 서로 참조하는 것
다중성(Multiplicity)
- 다대일(N:1), 일대다(1:N), 일대일(1:1), 다대다(N:M)
연관관계의 주인(Owner)
- 객체를 양방향 연관관계로 만들면 연관관계의 주인을 정해야 함

단방향 연관관계

다대일(N:1) 단방향 관계 이해가 가장 우선시 되어야 함

➡️ 회원과 팀이 있고, 회원은 하나의 팀에만 소속될 수 있을 때 회원과 팀은 다대일 관계

객체 연관관계
- 회원 객체는 Member.team 필드(멤버변수)로 팀 객체와 연관관계를 맺음
- 회원 객체와 팀 객체는 단방향 관계
- 회원은 Member.team 필드를 통해서 팀을 알 수 있지만 반대로 팀은 회원을 알 수 없음
  (방법: member.getTeam())
테이블 연관관계
- 회원 테이블은 TEAM_ID 외래 키로 팀 테이블과 연관관계를 맺음
- 회원 테이블과 팀 테이블은 양방향 관계
- 회원 테이블의 TEAM_ID 외래 키를 통해서 회원과 팀을 조인 할 수 있고, 반대로 팀과 회원도 조인할 수 있음
객체 연관관계 vs 테이블 연관관계 차이
- 참조를 통한 연관관계는 언제나 단방향
- 객체간에 연관관계를 양방향으로 하기 위해서는 반대쪽에도 필드를 추가하여 참조를 보관해야 함
  (➡️ 이는 정확히 말하면 양방향 관계가 아닌 서로 다른 단방향 관계 2개임)
- 객체는 참조(주소)로 연관관계를 맺고, 테이블은 외래 키로 연관관계를 맺음

순수한 객체 연관관계 방법

public class Member {
    private String id;
    private String username;
    
    private Team team; //팀의 참조를 보관
    
    public void setTeam(Team team){
    	this.team = team;
    }
    
}

public class Team {
    private String id;
    private String name;
}

테이블 연관관계

CREATE TABLE MEMBER (
    MEMBER_ID VARCHAR(225) NOT NULL,
    TEAM_ID VARCHAR(225),
    USERNAME VARCHAR(225),
    PRIMARY KEY (MEMBER_ID)
}

CREATE TABLE TEAM (
    TEAM_ID VARCHAR(225) NOT NULL,
    NAME VARCHAR(225),
    PRIMARY KEY (TEAM_ID)
}

ALTER TABLE MEMBER ADD CONSTRAINT FK_MEMBER_TEAM
     FOREIGN KEY (TEAM_ID) REFERENCE TEAM

객체관계 매핑

@Entity
public class Member {
    @Id
    @Column(name="MEMBER_ID")
    private String id;
    
    //연관관계 매핑
    @ManyToOne
    @JoinColumn(name="TEAM_ID")
    private Team team;
    
    //연관관계 설정
    public void setTeam(Team team){
    	this.team = team;
    }
}

✅ @ManyToOne

다대일 관계에서 사용하는 어노테이션

속성	기능	기본값
optional	false로 설정하면 연관된 엔티티가 항상 있어야 함	true
fetch	글로벌 페치 전략 설정	@ManyToOne=FetchType.EAGER @OneToMany=FetchType.LAZY
cascade	영속성 전이 기능 사용
targetEntity	연관된 엔티티의 타입 정보 설정 이 기능은 거의 사용하지 않음 컬렉션을 사용해도 제네릭으로 타입 정보를 알 수 있음

✅ @JoinColumn

외래 키를 매핑할 때 사용하는 어노테이션

생략 시 외래 키를 찾을 때 기본값 사용함 ➡️ 필드명(team) + 언더바( _ ) + 참조하는 테이블의 컬럼명(TEAM_ID) = team_TEAM_ID

속성	기능	기본값
name	매핑할 외래 키 이름	필드명+ 언더바(_) + 참조하는 테이블의 기본 키 컬럼명
referencedColumnName	외래키가 참조하는 대상 테이블의 컬럼명	참조하는 테이블의 기본 키 컬럼명
foreignKey(DDL)	외래 키 제약조건을 직접 지정 가능 테이블을 생성할 때만 사용됨
unique nullable insertable updatable columnDefinition table	@Column 속성과 동일

연관관계 사용

1. 저장

public void testSave() {

    //팀1 저장
    Team team1 = new Team("team1", "팀1");
    em.persist(team1);
    
    //회원1 저장
    Member member1 = new Member("member1", "회원1");
    member1.setTeam(team1); //회원 -> 팀 참조
    em.persist(member1);
}

2. 조회

객체 그래프 탐색
객체지향 쿼리 사용

//객체 그래프 탐색
Member member = em.find(Member.class, "member1");
Team team = memver.getTeam(); //객체 그래프 탐색
System.out.println("팀 이름 = " + team.getName()); //출력결과: 팀 이름 = 팀1

//객체지향 쿼리 사용(JPQL)
private static void queryLogicJoin(EntityManager em){
    String jpql = "select m from Member m join m.team t "
    				+ "where t.name=:teamName";
    
    List<Member> resultList = em.createQuery(jpql, Member.class)
                                .setParameter("teamName", "팀1");
                                .getResultList();
                                
    for (Member member : resultList){
    	System.out.println("[query] member.username= " + member.getUsername());
        //출력결과
        //[query] member.username= 회원1
    }
}

:teamName
- : 로 시작하는 것은 파라미터를 바인딩 받는 문법

3. 수정

private static void update (EntityManager em) {

    //새로운 팀2
    Team team2 = new Team("team2", "팀2");
    em.persist(team2);
    
    //회원1에 새로운 팀2 설정
    Member member = em.find(Member.class, "member1");
    member.setTeam(team2);
 }

4. 연관관계 제거

private static void delete (EntityManager em){
    Member member1 = em.find(Member.class, "member1");
	member.setTeam(null); //연관관계 제거
}

UPDATE
	MEMBER
SET
	TEAM_ID = null
WHERE
	ID='member1'

5. 연관된 엔티티 삭제

기존에 있던 연관관계를 먼저 제거 후 삭제 해야 함

member1.setTeam(null); //회원1 연관관계 제거
member2.setTeam(null); //회원2 연관관계 제거
em.remove(team); //팀 삭제

양방향 연관관계

회원->팀: 다대일 관계, 팀->회원: 일대다 관계
일대다 관계는 여러 건과 연관관계를 맺을 수 있으므로 컬렉션을 사용해야 함
➡️ JPA는 List, Collection, Set, Map 등의 컬렉션 지원
데이터베이스 테이블은 외래 키 하나로 양방향 조회 가능
무한 루프에 빠지지 않게 조심해야 함

1. 양방향 연관관계 매핑

@Entity
public class Team {
    @Id
    @Column(name="TEAM_ID")
    private String id;
    
    @OneToMany(mappedBy="team")
    private List<Member> members = new ArrayList<Member>();
}

일대다 관계이기 때문에 팀 엔티티에 컬렉션인 List를 사용
일대다 관계를 매핑하기 위해 @OneToMany 매핑 정보 사용
mappedBy 속성은 양방향 매핑일 때, 반대쪽 매핑의 필드 이름을 값으로 설정

2. 일대다 컬렉션 조회

public void biDireaction(){
    Team team = em.find(Team.class, "team1");
    List<Member> members = team.getMembers(); //팀->회원, 객체그래프 탐색
    
    for(Member member : members){
    	System.out.println("member.username = " + member.getUsername());
    }
}

//출력결과
//member.username = 회원1

연관관계의 주인

테이블은 외래 키 하나로 두 테이블의 연관관계를 관리
- 엔티티를 단방향으로 매핑하면 참조를 하나만 사용하므로 이 참조로 외래 키 관리 가능
- 엔티티를 양방향으로 매핑 시 두 곳에서 서로를 참조하여, 객체의 연관관계를 관리하는 포인트가 2곳으로 늘어남
엔티티를 양방향 연관관계로 설정 시, 객체의 참조는 둘인데 외래 키는 하나여서 차이가 발생
JPA에서는 두 객체의 연관관계 중 하나를 정해서 테이블의 외래 키를 관리하기 위해 연관관계의 주인을 사용

양방향 연관관계 저장

양방향 연관관계는 연과노간계의 주인이 외래 키를 관리하기 때문에 주인이 아닌 방향은 값을 설정하지 않아도

데이터베이스에 외래 키 값이 정상 입력된다.

➡️ 주인이 아닌 곳에 입력된 값은 외래 키에 영향을 주지 않기 때문에 데이터베이스에 저장할 때 무시된다

양방향 연관관계의 주의점

1. 연관관계의 주인에 값 미입력

연관관계의 주인에는 값을 입력하지 않고, 주인이 아닌 곳에만 값을 입력하는 실수를 하면

데이터베이스에 외래 키 값이 정상적으로 저장되지 않음

public void test() {
    //회원1 저장
    Member member1 = new Member("member1", "회원1");
    em.persist(member1);
    
    //회원2 저장
    Member member2 = new Member("member2", "회원2");
    em.persist(member2);
    
    Team team1 = new Team("team1", "팀1");
    //주인이 아닌 곳만 연관관계 설정
    team1.getMembers().add(member1);
    team1.getMembers().add(member2);
    
    em.persist(team1);
}

조회결과
MEMBER_ID	USERNAME	TEAM_ID
member1	회원1	null
member2	회원2	null

2. 순수한 객체까지 고려한 양방향 연관관계

객체 관점에서 양쪽 방향에 모두 값을 입력해주는 것이 가장 안전함

public void test(){
    //팀1
    Team team1 = new Team("team1", "팀1");
    Member member1 = new Member("member1", "회원1");
    
    member1.setTeam(team1); //연관관계 설정: member1 -> team1
    team1.getMembers().add(member1); //연관관계 설정: team1 -> member1
    
    List<Member> members = team1.getMembers();
    System.out.println("members.size = " + members.size()); //출력결과: members.size = 1

3. 연관관계 편의 메소드

양방향 관계에서 양쪽 방향에 모두 값을 입력해주는 것을 하나의 코드인 것처럼 사용하는 것이 안전함

연관관계를 변경할 때는 기존의 연관관계를 제거하는 코드가 필요함

public class Member {
    private Team team;
    
    public void setTeam(Team team){
    
        //기존 팀과 관계를 제거
        if(this.team != null){
            this.team.getMembers().remove(this);
        }
    
        this.team = team;
        team.getMembers().add(this);
    }
    ...
}

정리

단방향 매핑만으로 테이블과 객체의 연관관계 매핑은 이미 완료
단방향을 양방향으로 만들면 반대방향으로 객체 그래프 탐색 기능이 추가됨
양방향 연관관계를 매핑하려면 객체에서 양쪽 방향을 모두 관리해야 함

[JPA] 자바 ORM 표준 JPA 프로그래밍 #9

지니(jineey) — Tue, 12 Nov 2024 22:04:14 +0900

@Column

객체 필드를 테이블 컬럼에 매핑한다

속성 중 name, nullable이 주로 사용되고 나머지는 잘 사용되지 않는 편이다

속성	기능	기본값
name	필드와 매핑할 테이블의 컬럼 이름	객체의 필드 이름
nullable	null 값의 허용 여부를 설정 false로 설정하면 DDL 생성 시에 not null 제약조건이 붙음	true
unique	@Table의 uniqueConstraint와 같지만 한 칼럼에 간단히 유니크 제약조건을 걸 때 사용한다. 만약 두 컬럼 이상을 사용해서 유니크 제약조건을 사용하러며녀 클래스 레벨에서 @Table.uniqueConstraints를 사용해야 한다
columnDefinition	데이터베이스 칼럼 정보를 직접 줄 수 있음	필드의 자바 타입과 방언 정보를 사용해서 적절한 컬럼 타입을 생성한다
length	문자 길이 제약조건, String 타입에만 사용한다	255
precision, scale	BigDecimal 타입에서 사용한다 precision은 소수점을 포함한 전체 자릿수를, scale은 소수의 자릿수다 (double, float 타입에는 적용되지 않음. 아주 큰 숫자나 정밀한 소수를 다루어야 할 때만 사용한다)	precision=19, scale=2
table (거의 사용하지 않음)	하나의 엔티티를 두 개 이상의 테이블에 매핑할 때 사용한다 지정한 필드를 다른 테이블에 매핑할 수 있다	현재 클래스가 매핑된 테이블
insertable (거의 사용하지 않음)	엔티티 저장 시 이 필드도 같이 저장한다 false로 설정 시 이 필드는 데이터베이스에 저장하지 않음 (=읽기 전용)	true
updatable (거의 사용하지 않음)	엔티티 수정 시 이 필드도 같이 수정한다 false로 설정 시 이 필드는 데이터베이스에 수정하지 않음 (= 읽기 전용)	true

//nullable
@Column(nullable=false)
private Strign data;
=> data varchar(255) not null

//unique
@Column(unique=true)
private String username;
=> alter table Tablename add constraint UK_Xxx unique(uesrname)

//columnDefinition
@Column(columnDefinition="varchar(100) default 'EMPTY'")
private String data;
=> DDL: datda varchar(100) default 'EMPTY'

//length
@Column(length=400)
private String data;
=> DDL: data varchar(400)

@Column 생략

생략 시 대부분 @Column 속성의 기본값이 적용되는데, 자바 기본 타입일 때는 nullable 속성에 예외가 있음

자바 기본 타입(ex. int)에는 NULL 값을 입력할 수 없음
- 자바 기본 타입을 DDL로 생성 시 not null 제약 조건을 추가하는 것이 안전함
객체 타입(ex. Integer)에는 NULL값이 허용

@Enumerated

자바의 enum 타입을 매핑할 때 사용한다.

속성	기능	기본값
value	EnumType.ORDINAL: enum 순서를 데이터베이스에 저장	EnumType.ORDINAL
value	EnumType.STRING: enum 이름을 데이터베이스에 저장	EnumType.ORDINAL

enum RoleType{
	ADMIN, USER
}

//enum 이름으로 매핑
@Enumerated(EnumType.STRING)
private RoleType roleType;

//사용법
member.setRoleType(RoleType.ADMIN)

EnumType.ORDINAL : enum에 정의된 순서대로 0부터 값이 데이터베이스에 저장됨
- 장점: 데이터베이스에 저장되는 데이터 크기가 작다
- 단점: 이미 저장된 enum의 순서를 변경할 수 없음
EnumType.STRING : enum 이름 그대로의 문자가 데이터베이스에 저장됨
- 장점: 저장된 enum의 순서가 바뀌거나 enum이 추가되어도 안전함
- 단점: 데이터베이스에 저장되는 데이터 크기가 ORDINAL에 비해서 큼

@Temporal

날짜타입을 매핑할 때 사용한다.

속성	기능	기본값
value	TemporalType.DATE 날짜, 데이터베이스 date 타입과 매핑 (예: 2024-11-12)	TemporalType은 필수로 지정해야 함
	TemporalType.TIME 시간, 데이터베이스 time 타입과 매핑 (예: 11:11:11)
	TemporalType.TIMESTAMP 날짜와 시간, 데이터베이스 timestamp 타입과 매핑 (예: 2024-11-12 11:11:11)

datetime: MySQL
timestamp: H2, Oracle, PostgreSQL

@Lob

데이터베이스 BLOB, CLOB 타입과 매핑한다

지정할 수 있는 속성이 없음. 대신 매핑하는 필드 타입이 문자면 CLOB, 나머지는 BLOB로 매핑한다

CLOB: String, char[], java.sql.CLOB
BLOB: byte[], java.sql.BLOB

@Transient

이 필드는 매핑하지 않기 때문에 데이터베이스에 저장하지 않고 조회하지도 않음

객체에 임시로 어떤 값을 보관하고 싶을 때 사용

@ Access

JPA가 엔티티 데이터에 접근하는 방식을 지정한다

@Access를 설정하지 않으면 @Id의 위치를 기준으로 접근 방식이 설정됨

필드 접근
- AccessType.FIELD
- 필드에 직접 접근하며, 필드 접근 권한이 private여도 접근 가능
프로퍼티 접근
- AccessType.PROPERTY
- 접근자(Getter)를 사용
필드 접근 방식 + 프로퍼티 접근 방식

@Entity
public class Member{
    @Id
   	private String id;
    
    @Access(AccessType.PROPERTY)
    public String getFullName(){
    	return firstNmae + lastName;
    }
}

@Id가 필드에 있으므로 기본은 필드 접근 방식 사용
getFullName()만 프로퍼티 접근 방식 사용

정리

분류	매핑 어노테이션	설명
필드와 컬럼 매핑	@Column	컬럼을 매핑한다
	@Enumerated	자바의 enum 타입을 매핑한다
	@Temporal	날짜 타입을 매핑한다
	@Lob	BLOB, CLOB 타입을 매핑한다
	@Transient	특정 필드를 데이터베이스에 매핑하지 않는다
기타	@Access	JPA가 엔티티에 접근하는 방식을 지정한다

[JPA] 자바 ORM 표준 JPA 프로그래밍 #8

지니(jineey) — Mon, 11 Nov 2024 23:52:13 +0900

데이터베이스 기본 키 생성 전략

직접 할당
- 기본 키를 애플리케이션에서 직접 할당
- @Id 사용
자동 생성 (=대리 키 사용 방식)
- @Id + @GeneratedValue
- IDENTITY : 기본 키 생성을 데이터베이스에 위임
- SEQUENCE : 데이터베이스 시퀀스를 사용해서 기본 키를 할당
- TABLE : 키 생성 테이블을 사용

기본 키 직접 할당 전략

매핑 방법
- @Id 로 매핑

@Id
@Column(name = "id")
private String id;

적용 가능한 자바 타입
- 자바 기본형
- 자바 래퍼(Wrapper)형
- String
- java.util.Date
- java.sql.Date
- java.math.BigDecimal
- java.math.BigInteger
persist()로 엔티티를 저장하기 전에 애플리케이션에서 기본 키를 직접 할당하는 방법

IDENTITY 전략

기본 키 생성을 데이터베이스에 위임하는 전략
사용 가능한 데이터베이스
- MySQL, PostgreSQL, SQL Server, DB2
데이터베이스에 값을 저장하고 나서야 기본 키 값을 구할 수 있을 때 사용
매핑 코드

@Entity
public class Board {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;
    ...
}

IDENTITY 전략과 최적화
- 데이터를 데이터베이스에 INSERT한 후에 기본 키 값을 조회 가능
  ➡️ 엔티티에 식별자 값을 할당하려면 JPA는 추가로 데이터베이스를 조회해야 함
- JDBC3에 추가된 Statement.getGeneratedKeys()를 사용하면 데이터를 저장하면서 동시에 생성된 기본 키 값도 얻을 수 있음
트랜잭션을 지원하는 쓰기 지연이 동작하지 않음
- 엔티티가 영속 상태가 되려면 식별자가 반드시 필요
- IDENTITY 식별자 생성 전략은 엔티티를 데이터베이스에 저장해야 식별자를 구할 수 있으므로 persist()를 호출하는
  즉시 INSERT SQL이 데이터베이스에 전달됨

SEQUENCE 전략

시퀀스를 사용해서 기본 키를 생성
사용 가능한 데이터베이스
- 오라클, PostgreSQL, DB2, H2 데이터베이스
매핑 코드

@Entity
@SequenceGenerator (
    name = "BOARD_SEQ_GENERATOR",
    sequenceName = "BOARD_SEQ",	//매핑할 데이터베이스 시퀀스 이름
    initialValue = 1, allocationSize = 1)
public class Board {
    @Id
    @GeneratedValue(strategy = GenerationType.SEQUENCE,
    				generator = "BOARD_SEQ_GENERATOR")
    private Long id;
    ...
}

persist() 호출 시 먼저 데이터베이스 시퀀스를 사용해서 식별자 조회
➡️ 조회한 식별자를 엔티티에 할당한 후에 엔티티를 영속성 컨텍스트에 저장

@SequenceGenerator

속성	기능	기본값
name	식별자 생성기 이름	필수
sequenceName	데이터베이스에 등록되어 있는 시퀀스 이름	hibernate_sequence
initialValue	DDL 생성 시에만 사용됨. 시퀀스 DDL을 생성할 때 처음 시작하는 수를 지정	1
allocationSize	시퀀스 한 번 호추렝 증가하는 수 (성능 최적화에 사용됨)	50
catalog, schema	데이터베이스 catalog, schema 이름

TABLE 전략

키 생성 전용 테이블을 하나 만들고 여기에 이름과 값으로 사용할 컬럼을 만들어 데이터베이스 시퀀스를 흉내내는 전략
모든 데이터베이스에 적용 가능
코드 매핑

@Entity
@TableGenerator(
    name = "BOARD_SEQ_GENERATOR",
    table = "MY_SEQUENCES",
    pkCloumnValue = "BOARD_SEQ", allocationSize = 1)
public class Board {
    @Id
    @GeneratedValue(strategy = GenerationType.TABLE,
    				generator = "BOARD_SEQ_GENERATOR")
    private Long id;
    ...
}

TABLE 전략은 시퀀스 대신에 테이블을 사용한다는 것만 제외하면 SEQUENCE 전략과 내부 동작방식이 같음
테이블에 값이 없으면 JPA가 값을 INSERT하면서 초기화하므로 값을 미리 넣어둘 필요는 없음

@TableGenerator

속성	기능	기본값
name	식별자 생성기 이름	필수
table	키생성 테이블명	hibernate_sequences
pkColumnName	시퀀스 컬럼명	sequence_name
valueColumnName	시퀀스 값 컬럼명	next_val
pkCoumnValue	키로 사용할 값 이름	엔티티 이름
initialValue	초기 값, 마지막으로 생성된 값이 기준	0
allocationSize	시퀀스 한 번 호출에 증가하는 수 (성능 최적화에 사용됨)	50
catalog, schema	데이터베이스 catalog, schema 이름
uniqueConstraints(DDL)	유니크 제약 조건 지정 가능

TABLE 전략과 최적화
- 값을 조회하면서 SELECT 쿼리를 사용하고 다음 값으로 증가시키기 위해 UPDATE 쿼리 사용
- 이 전략을 SEQUENCE 전략과 비교해서 데이터베이스와 한 번 더 통신하는 단점 있음
- 최적화하려면 @TableGenerator.allocationSize 사용 ➡️ SEQUENCE 전략과 방법은 가능

AUTO 전략

데이터베이스 방언에 따라 IDENTITY, SEQUENCE, TABLE 전략 중 하나를 자동으로 선택
데이터베이스를 변경해도 코드를 수정할 필요가 없다는 장점
스키마 자동 생성 기능을 사용 시 하이버네이트가 기본값을 사용해서 적절한 시퀀스나 키 생성용 테이블을 만들어 줌

기본 키 매핑 정리

직접 할당
persist()를 호출하기 전에 애플리케이션에서 직접 식별자 값을 할당해야 함
식별자 값이 없으면 예외가 발생
SEQUENCE
데이터베이스 시퀀스에서 식별자 값을 획득한 후 영속성 컨텍스트에 저장
TABLE
데이터베이스 시퀀스 생성용 테이블에서 식별자 값을 획득한 후 영속성 컨텍스트에 저장
IDENTITY
데이터베이스에 엔티티를 저장해서 식별자 값을 획득한 후 영속성 컨텍스트에 저장
(IDENTITY 전략은 테이블에 데이터를 저장해서 식별자 값을 획득할 수 있음)

권장하는 식별자 선택 전략

기본 키 조건 충족 필요

NULL값 허용하지 않음
유일해야 함
변해서는 안됨

기본 키를 선택하는 전략

자연 키(natural Key) : 비즈니스에 의미가 있는 키
대리 키(surrogate key) : 비즈니스와 관련 없는 임의로 만들어진 키, 대체 키로도 불림

[JPA] 자바 ORM 표준 JPA 프로그래밍 #7

지니(jineey) — Sun, 10 Nov 2024 22:41:54 +0900

속성
- name
  - JPA에서 사용할 엔티티 이름 지정
  - 보통 기본값인 클래스 이름 사용
  - 다른 패키지에 이름이 같은 엔티티 클래스가 있다면 이름을 지정해서 충돌하지 않도록 수정 필요
  - 기본값을 설정하지 않으면 클래스 이름을 그대로 사용
주의사항

1. 기본 생성자는 필수(파라미터가 없는 public 또는 protected 생성자)
➡️ 생성자를 하나 이상 만들면 자바는 기본 생성자를 자동으로 만들지 않기 때문에, 기본 생성자를 직접 만들어야 함

public Member(){} //직접 만든 기본 생성자

//임의의 생성자
public Member(String name){
	this.name = name
}

2. fianl 클래스, enum, interface, inner 클래스에는 사용 불가능

3. 저장할 필드에 final을 사용하면 안됨

@Table

엔티티와 매핑할 테이블을 지정하고, 생략 시 매핑한 엔티티 이름을 테이블 이름으로 사용

속성
- name
  - 매핑할 테이블의 이름
  - 엔티티 이름을 사용
- catalog
  - catalog 기능이 있는 데이터베이스에서 catalog를 매핑
- schema
  - schema 기능이 있는 데이터베이스에서 schema를 매핑
- uniqueConstraints(DDL)
  - DDL 생성 시에 유니크 제약 조건 생성
  - 2개 이상의 복합 유니크 제약조건도 만들 수 있음
  - 스키마 자동 생성 기능을 사용해서 DDL을 만들 때만 사용

다양한 매핑 사용

@Entity
@Table(name="MEMBER")
public class Member{
	@Enumerated(EnumType.STRING)
    private RoleType roleType;
    
    @Temporal(TemporalType.TIMESTAMP)
    private Date createdDate;
    
    @Lob
    private String description;
    
    ...
}

자바의 enum을 사용하려면 @Eunmerated 어노테이션으로 매핑 필요
자바의 날짜 타입은 @Temporal을 사용하여 매핑
길이 제한이 없는 필드는 데이터베이스의 VARCHAR 타입 대신에 CLOB 타입으로 저장 필요
- @Lob 사용 시 CLOB, BLOB 타입 매핑 가능

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

JPA는 데이터베이스 스키마를 자동으로 생성하는 기능을 지원하며,

클래스의 매핑 정보를 보면 어떤 테이블에 어떤 컬럼을 사용했는지 확인 가능

➡️ 이 매핑정보와 데이터베이스 방언을 사용해서 데이터베이스 스키마를 생성

스키마 자동 생성 기능 사용법

persistence.xml에 다음 속성 추가

<property name="hibernate.hbm2ddl.auto" value="create" />

애플리케이션 실행 시점에 데이터베이스 테이블을 자동으로 생성
hibernate.show_sql속성을 true 설정 시 콘솔에 실행되는 테이블 생성 DDL을 출력 가능

hibernate.hbm2ddl.auto 속성

create	기존 테이블을 삭제하고 새로 생성 (DROP + CREATE)
create-drop	create 속성에 추가로 애플리케이션을 종료할 때 생성한 DDL을 제거 (DROP + CREATE + DROP)
update	데이터베이스 테이블과 엔티티 매핑정보를 비교해서 변경 사항만 수정
validate	데이터베이스 테이블과 엔티티 매핑정보를 비교해서 차이가 있으면 경고를 넘기고 애프리케이션을 실행하지 않음. 이 설정은 DDL을 수정하지 않음
none	자동 생성 기능을 사용하지 않으면 hibernate.hbm2ddl.auto속성 자체를 삭제하거나 유효하지 않은 옵션 값을 주면 됨 (참고로 none은 유효하지 않은 옵션임)

주의사항
- create, create-drop, update처럼 DDL을 수정하는 옵션은 오직 개발 서버나 개발 단계에서만 사용해야 함
참고사항
- JPA는 2.1부터 스키마 자동 생성 기능을 표준으로 지원
- 자바는 카멜 표기법 사용, 데이터베이스는 언더스코어(_)를 사용

DDL 생성기능

@Entity
@Table(name="MEMBER")
public class Member{
	@Id
    @Column(name="ID")
    private Strign id;
    
    @Column(name="NAME", nullable = false, length = 10)
    private String username;
    ...
}

@Colunm 매핑 정보
- nullabe 속성 값 설정
  - DDL에 NOT NULL 제약조건 추가 가능
- length 속성 값 설정
  - DDL에 문자의 크기 지정 가능

✅ 이런 기능들은 단지 DDL을 자동 생성할 때만 사용되고 JPA의 실행 로직에는 영향을 주지 않음

[JPA] 자바 ORM 표준 JPA 프로그래밍 #6

지니(jineey) — Sat, 9 Nov 2024 22:35:21 +0900

영속성 컨텍스트의 변경 내용을 데이터베이스에 반영
플러시는 영속성 컨텍스트에 보관된 엔티티를 지우는 것이 아니라, 영속성 컨텍스트의 변경 내용을 데이터베이스에 동기화
실행 과정
- 변경 감지가 동작해서 영속성 컨텍스트에 있는 모든 엔티티를 스냅샷과 비교하여 수정된 엔티티를 찾음
- 수정된 엔티티는 수정 쿼리를 만들어 쓰기 지연 SQL 저장소에 등록
- 쓰기 지연 SQL 저장소의 쿼리를 데이터베이스에 전송
영속성 컨텍스트 플러시 방법
- flush()를 직접 호출
  - 테스트나 다름 프레임워크와 JPA를 함께 사용할 때 제외하고 거의 사용하지 않음
- 트랜잭션 커밋 시 플러시 자동 호출
  - 데이터베이스에 변경 내용을 SQL로 전달하지 않고 트랜잭션만 커밋 시 데이터베이스에 반영되지 않음
  - 트랜잭션을 커밋 시 플래시를 자동 호출하여 해당 문제 해결
- JPQL 쿼리 실행 시 플러시가 자동 호출
  - JPQL이나 Criteria 같은 객체지향 쿼리를 호출할 때도 플러시 자동 실행
  - 쿼리 실행 직전에 영속성 컨텍스트를 플러시해서 변경 내용을 데이터베이스에 반영해야 하는 문제를 예방하기 위함
플러시 모드 옵션
- 직접 지정 시, javax.persistence.FlustModeType 사용
  - FlustModType.AUTO : 커밋이나 쿼리를 실행할 때 플러시(기본값)
  - FlustModeType.COMMIT : 커밋할 때만 플러시 ➡️ 성능 최적화를 위해 사용

준영속

영속성 컨텍스트가 관리하는 영속 상태의 엔티티가 영속성 컨텍스트에서 분리된 것
준영속 상태의 엔티티는 영속성 컨텍스트가 제공하는 기능을 사용할 수 없음
준영속 상태로 만드는 방법
- detach(entity) : 특정 엔티티만 준영속 상태로 전환
  - 이 메서드를 호출하는 순간, 1차 캐시부터 쓰기 지연 SQL 저장소까지 해당 엔티티를 관리하기 위한 모든 정보 제거
  - 영속성 컨텍스트가 지원하는 어떤 기능도 동작하지 않음
- clear() : 영속성 컨텍스트를 완전히 초기화
  - 영속성 컨텍스트를 초기화해서 해당 영속성 컨텍스트의 모든 엔티티를 준영속 상태로 전환
  - 영속성 컨텍스트가 제공하는 변경 감지는 동작하지 않음
- close() : 영속성 컨텍스트를 종료
  - 해당 영속성 컨텍스트가 관리하던 영속 상태의 엔티티가 모두 준영속 상태로 전환
영속 상태의 엔티티는 주로 영속성 컨텍스트가 종료되면서 준영속 상태가 되기 때문에,
개발자가 직접 준영속 상태로 만드는 일은 드물다
준영속 상태의 특징
- 거의 비영속에 가까움: 영속성 컨텍스트가 제공하는 어떠한 기능도 동작하지 않음
- 식별자 값을 가지고 있음: 이미 한 번 영속 상태였으므로 반드시 식별자 값을 가지고 있음
- 지연 로딩 불가능: 지연 로딩은 실제 객체 대신 프록시 객체를 로딩해두고 해당 객체를 실제 사용할 때 영속성 컨텍스트를 통해 데이터를 불러오는 방법이나, 영속 상태는 영속성 컨텍스트가 더는 관리하지 않기 때문에 지연 로딩 시 문제 발생
준영속 병합
- 준영속 상태의 엔티티를 다시 영속 상태로 변경
- merge()
  - 준영속 상태의 엔티티를 받아서 그 정보로 새로운 영속 상태의 엔티티를 반환
  - 동작 방식

[그림1] 준영속 병합 - merge() 동작 방식

merge() 를 실행
파라미터로 넘어온 준영속 엔티티의 식별자 값으로 1차 캐시에서 엔티티 조회
- 만약 1차 캐시에 엔티티가 없으면 데이터베이스에서 엔티티를 조회하고 1차 캐시에 저장
조회한 영속 엔티티에 member 엔티티의 값을 채워 넣음
- member 엔티티의 모든 값을 mergeMember에 밀어 넣음
- 이때 mergeMember의 "회원1" 라는 이름이 "회원명변경"으로 수정
mergeMember 반환

비영속 병합
- 병합은 준영속, 비영속을 신경쓰지 않음
- 식별자 값으로 엔티티를 조회할 수 있으면 불러서 병합
- 조회가 불가능하면 새로 생성해서 병합 ➡️ save or update 기능 수행

정리

엔티티 매니저
1. 엔티티 매니저 팩토리에서 생성
2. 엔티티 매니저의 내부에 영속성 컨텍스트도 함께 만들어 짐
3. 영속성 컨텍스트는 엔티티 매니저를 통해 접근 가능
영속성 컨텍스트
1. 애플리케이션과 데이터베이스 사이에 객체를 보관하는 가상의 데이터베이스 같은 역할
2. 1차 캐시, 동일성 보장, 트랜잭션을 지원하는 쓰기 지연, 변경 감지, 지연 로딩 기능 등 사용 가능
플러시
1. 영속성 컨텍스트에 저장한 엔티티가 데이터베이스에 반영되는 것
2. 트랜잭션을 커밋 시 영속성 컨텍스트가 플러시 됨
영속/준영속 상태의 엔티티
1. 영속성 컨텍스트가 관리하는 엔티티
2. 영속성 컨텍스트가 관리하지 않는 엔티티는 준영속 상태의 엔티티
3. 준영속 상태의 엔티티는 영속성 컨텍스트가 제공하는 기능들(2-2 참고) 사용 불가능
엔티티 매니저와 영속성 컨텍스트는 매핑한 엔티티를 실제 사용하는 동적인 부분에 해당

[JPA] 자바 ORM 표준 JPA 프로그래밍 #5

지니(jineey) — Fri, 8 Nov 2024 21:21:01 +0900

JPA 제공 기능
- 엔티티와 테이블을 매핑하는 설계 부분
- 매핑한 엔티티를 실제 사용하는 부분
엔티티 매니저(Entity Manager)
- 엔티티를 저장하는 가상의 데이터베이스
- 생성하는 비용이 거의 들지 않음
- 여러 스레드가 동시에 접근하면 동시성 문제가 발생 ➡️ 스레드 간에 절대 공유하면 안됨
엔티티 매니저 팩토리(Entity Manager Factory)
- 엔티티 매니저를 만듦
- 데이터베이스를 하나만 사용하는 애플리케이션은 일본적으로 EntityManagerFactory를 하나만 생성
- 비용이 아주 많이 들기 때문에 한 개만 만들어서 애플리케이션 전체에 공유하도록 설계
- 여러 스레드가 동시에 접근해도 안전 ➡️ 서로 다른 스레드 간에 공유 가능

커넥션 획득 시기

[그림1] 일반적인 웹 애플리케이션

엔티티 매니저는 데이터베이스 연결이 꼭 필요한 시점까지 커넥션을 얻지 않음
커넥션풀
- 하이버네이트를 포함한 JPA 구현체들은 엔티티 매니저 팩토리를 생성할 때 만듦
- J2SE 환경에서 사용하는 방법

영속성 컨텍스트란?

영속성 컨텍스트(Persistence context)
- 엔티티를 영구 저장하는 환경
- 엔티티 매니저를 생성할 때 하나 만들어짐
- persist() 메서드 : 엔티티 매니저를 사용해서 엔티티를 영속성 컨텍스트에 저장
- 엔티티 매니저를 통해서 영속성 컨텍스트에 접근할 수 있고, 영속성 컨텍스트 관리 가능

엔티티 생명주기

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

✅ 비영속

엔티티 객체를 생성했지만 순수한 객체 상태이며 아직 저장되지 않음

영속성 컨텍스트나 데이터베이스와는 전혀 관련이 없음

✅ 영속

엔티티 매니저를 통해서 엔티티를 영속성 컨텍스트에 저장

영속성 컨텍스트가 관리하는 엔티티를 영속 상태라 함

즉, 영속 상태라는 것은 영속성 컨텍스트에 의해 관리된다는 뜻

✅ 준영속

영속성 컨텍스트가 관리하던 영속 상태의 엔티티를 영속성 컨텍스트가 관리하지 않는 상태

준영속성 상태로 만들기 위한 방법

detach()
close() : 영속성 컨텍스트 닫기
clear() : 영속성 컨텍스트 초기화

✅ 삭제

영속성 컨텍스트와 데이터베이스에서 삭제

remove()

영속성 컨텍스트의 특징

영속성 컨텍스트의 특징
- 엔티티를 식별자로 구분
- 영속 상태는 식별자의 값이 반드시 필요
- 플러시(flush)
  - JPA는 보통 트랜잭션을 커밋하는 순간 영속성 컨텍스트에 새로 저장한 엔티티를 데이터베이스에 반영
영속성 컨텍스트가 엔티티를 관리할 때의 장점
- 1차 캐시
- 동일성 보장
- 트랜잭션을 지원하는 쓰기 지연
- 변경 감지
- 지연 로딩

엔티티 조회

1차 캐시
- 영속성 컨텍스트가 내부에 가지고 있는 캐시
- 영속 상태의 엔티티는 모두 1차 캐시에 저장됨
영속성 컨텍스트 내부의 Map
- 키: @Id로 매핑한 식별자
- 값: 엔티티 인스턴스
persist()를 하면 1차 캐시에 해당 엔티티를 저장할 뿐, 아직 데이터베이스에 저장되지 않음
영속성 컨텍스트에 데이터를 저장하고 조회하는 모든 기준은 데이터베이스 기본 키 값

✅ 1차 캐시에서 조회

[그림2] 1차 캐시에서 조회

find()를 호출하면 우선 1차 캐시에서 식별자 값으로 엔티티를 찾음
찾는 엔티티가 있으면 데이터베이스를 조회하지 않고 메모리에 있는 1차 캐시에서 엔티티 조회

✅ 데이터베이스에서 조회

[그림3] 1차 캐시에 없어 데이터베이스 조회

1차 캐시에 없으면 엔티티 매니저는 데이터베이스를 조회해서 엔티티 생성
1차 캐시에 저장한 후에 영속 상태의 엔티티를 반환

분석

find()를 실행
1차 캐시에 없으므로 데이터베이스에서 조회
조회한 데이터로 엔티티를 생성해서 1차 캐시에 저장(=영속 상태)
조회한 엔티티를 반환

➡️ 엔티티 인스턴스가 1차 캐시에 있을 경우, 이 엔티티를 조회하면 메모리에 있는 1차 캐시에서 바로 불러옴.

➡️ 성능상 이점을 누릴 수 있음

➡️ 반복해서 find()를 호출해도 영속성 컨텍스트는 1차 캐시에 있는 같은 엔티티 인스턴스를 반환하기 때문에
엔티티의 동일성을 보장함

엔티티 등록

쓰기 지연(transactioanl write-behind)
- 엔티티 매니저는 트랜잭션을 커밋하기 직전까지 데이터베이스에 엔티티를 저장하지 않고 내부 쿼리 저장소에 모음
- 트랜잭션 커밋 시 모아둔 쿼리를 데이터베이스에 내보냄

➡️ 데이터베이스에 쿼리를 한 번에 전달해서 성능을 최적화

플러시
- 트랜잭션을 커밋하면 엔티티 매니저는 우선 영속성 컨텍스트 플러시
- 플러시란 영속성 컨텍스트의 변경 내용을 데이터베이스에 동기화하는 작업
- 등록, 수정, 삭제한 엔티티를 데이터베이스에 반영

엔티티 수정

변경 감지(dirty checking)
- 엔티티의 변경사항을 데이터베이스에 자동으로 반영하는 기능
변경 감지 순서
- 트랜잭션을 커밋 시 엔티티 매니저 내부에서 플러시 호출
- 엔티티와 스냅샷을 비교해서 변경된 엔티티를 찾음
  - 스냅샷: 엔티티를 영속성 컨텍스트에 보관할 때, 최초 상태를 복사해서 저장해둠
- 변경된 엔티티가 있으면 수정 쿼리를 생성해서 쓰기 지연 SQL 저장소에 보냄
- 쓰기 지연 저장소의 SQL을 데이터베이스에 보냄
- 데이터베이스 트랜잭션을 커밋

➡️ 변경 감지는 영속성 컨텍스트가 관리하는 영속 상태의 엔티티에만 적용됨

엔티티의 모든 필드를 업데이트
- 장점
  - 모든 필드를 사용하면 수정 쿼리가 항상 같음
  - 데이터베이스에 동일한 쿼리를 보내면 데이터베이스는 이전에 한 번 파싱된 쿼리 재사용 가능
- 단점
  - 모든 필드 사용 시 데이터베이스에 보내는 데이터 전송량이 증가
- 필드가 많거나 저장된 내용이 너무 크면 수정된 데이터만 사용해서 동적으로 UPDATE SQL을 생성하는 전략 선택
  ➡️ 하이버네이트 확장 기능 사용

엔티티 삭제

remove()에 삭제 대상 엔티티를 넘겨주면 엔티티를 삭제
삭제 쿼리를 쓰기 지연 SQL 저장소에 등록 ➡️ 커밋해서 플러시 호출 시 실제 데이터베이스에 삭제 쿼리 전달
remove()를 호출하는 순간 영속성 컨텍스트에서 제거
삭제된 엔티티는 재사용하지 말고 자연스럽게 가비지 컬렉션 대상이 되도록 두는 것이 좋음

[JPA] 자바 ORM 표준 JPA 프로그래밍 #4

지니(jineey) — Thu, 7 Nov 2024 22:53:22 +0900

Maven을 사용하여 필요한 라이브러리 관리 ➡️ pom.xml에 사용할 라이브러리를 적어주면 라이브러리를 자동으로 내려받아서 관리
프로젝트 구조
- src/main
  - java
    - jpabook/start
      - JpaMain.java (실행 클래스)
      - Member.java (회원 엔티티)
  - resources
    - META-INF
      - persistence.xml (JPA 설정 정보)
- pom.xml

객체 매핑 시작

매핑 정보	회원 객체	회원 테이블
클래스와 테이블	Member	MEMBER
기본 키	id	ID
필드와 컬럼	username	NAME
필드와 컬럼	age	AGE

//회원 클래스에 JPA가 제공하는 매핑 어노테이션 추가
package jpabook.start;

import javax.persistence.*;

@Entity
@Table(name="MEMBER")
public class Member{
	@Id
    @Column(name="ID")
    private String id;
    
    @Column(name="NAME")
    private String username;
    
    //매핑 정보가 없는 필드
    pirvate Integer age;
    ...
}

@Entity
- 클래스를 테이블과 매핑한다고 JPA에게 알려주는 역할
- 엔티티 클래스라 칭함
@Table
- 엔티티 클래스에 매핑할 테이블 정보 알려줌
- 이 어노테이션을 생략하면 클래스 이름을 테이블 이름으로 매핑함 (더 정확히는 엔티티 이름을 사용함)
@Id
- 엔티티 클래스의 필드를 데이틀의 기본 키(PK)에 매핑
@Column
- 필드를 컬럼에 매핑
매핑 정보가 없는 필드
- 매핑 어노테이션을 생략하면 필드명을 사용해서 컬럼명으로 매핑

persistence.xml 설정

JPA는 persistence.xml을 사용해서 필요한 설정 정보를 관리
이 설정 파일이 META-INF/persistence.xml 클래스 패스 경로에 있으면 별도의 설정 없이 JPA가 인식 가능

<?xml version="1.0" encoding="UTF-8">
<persistence xmlns="http://xmlns.jcp.org/xml/ns/persistence"
	version="2.1">
    <persistence-unit name="jpabook">
    	<properties>
        ..
        </properties>
    </persistence-unit>
</persistence>

영속성 유닛(persistence-unit): 일반적으로 연결할 데이터베이스당 하나의 영속성 유닛을 등록
고유한 이름을 부여해야 하고, 여기서는 'jpabook'이라는 이름 사용
JPA 표준 속성
- javax.persistence.jdbc.driver: JDBC 드라이버
- javax.persistence.jdbc.user: 데이터베이스 접속 아이디
- javax.persistence.jdbc.password: 데이터베이스 접속 비밀번호
- javax.persistence.jdbc.url: 데이터베이스 접속 URL
하이버네이트 속성
- hibernate.dialect: 데이터베이스 방언 설정

데이터베이스 방언

데이터 타입: 가변 문자 타입으로 MySQL은 VARCHAR, 오라클은 VARCHAR2를 사용
다른 함수명: 문자열을 자르는 함수로 SQL 표준은 SUBSTRING()를 사용하지만 오라클은 SUBSTR() 사용
페이징 처리: MySQL은 LIMIT를 사용하지만 오라클은 ROWNUM을 사용

애플리케이션 개발

엔티티 매니저 팩토리 생성
- JPA를 시작하기 위해, persistence.xml의 설정 정보를 사용해서 엔티티 매니저 팩토리 생성
- 엔티티 매니저 팩토리는 애플리케이션 전체에서 딱 한 번만 생성하고 공유해서 사용
엔티티 매니저 생성
- 엔티티 매니저 팩토리에서 엔티티 매니저 생성
- JPA 기능의 대부분은 이 엔티티 매니저가 제공
- 엔티티 매니저를 사용해서 엔티티를 데이터베이스에 CRUD 가능
- 엔티티 매니저는 데이터베이스 커넥션과 밀접한 관계가 있으므로 스레드 간 공유하거나 재사용하면 안됨
종료
- 엔티티 매니저 종료: em.close();
- 엔티티 매니저 팩토리 종료: emf.close();
트랜잭션 관리
- JPA를 사용하려면 항상 트랜잭션 안에서 데이터 변경
- 트랜젝션 없이 데이터를 변경하면 예외 발생
비즈니스 로직
- 등록: persist() 메소드에 저장할 엔티티 넘겨주기
- 수정: 엔티티의 값 변경 ➡️ JPA는 어떤 엔티티가 변경되었는지 추적하는 기능을 갖추고 있음
- 삭제: remove() 메소드에 삭제하려는 엔티티 넘겨주기
- 한 건 조회: 조회할 엔티티 타입과 @Id로 데이터베이스 테이블의 기본 키와 매핑한 식별자 값으로 엔티티 하나를 조회
- JPQL: 필요한 데이터만 데이터베이스에서 불러오려면 결국 검색조건이 포함된 SQL 사용해야 하는데 이때 JPQL 사용
  - JPQL = Java Persistence Query Language
    - JPQL: 엔티티 객체를 대상으로 쿼리
    - SQL: 데이터베이스 테이블을 대상으로 쿼리
  - select m from Member m
    - from Member는 회원 엔티티 객체를 말하는 것이지, Member 테이블이 아님
    - JPQL은 데이터베이스 테이블을 전혀 알지 못함.
  - JPQL은 대소문자를 명확하게 구분하지만, SQL은 관례상 대소문자를 구분하지 않고 사용하는 경우가 많음

[JPA] 자바 ORM 표준 JPA 프로그래밍 #3

지니(jineey) — Wed, 6 Nov 2024 22:50:45 +0900

어느 정도 성숙한 객체지향 언어에는 대부분 ORM 프레임워크들의 있는데 각 프레임워크의 성숙도에 따라 단순 CRUD 기능만 제공하는 것부터 패러다임 불일치 문제를 대부분 해결해주는 ORM 프레임워크도 존재
자바 진영에서는 하이버네이트 프레임워크를 가장 많이 사용

JPA 소개

엔터프라이즈 자바 빈즈(EJB) 3.0에서 하이버네이트를 기반으로 새로운 자바 ORM 기술 표준이 만들어졌는데 이것이 바로 JPA다.
JPA는 자바 ORM 기술에 대한 API 표준 명세, 즉 인터페이스를 모아놓은 것이다.

[사진3] JPA 표준 인터페이스와 구현체

해당 교재에서는 JPA 2.1 버전의 구현 프레임워크로 하이버네이트 사용
JPA 버전별 특징
- JPA 1.0(JSR 220) 2006년: 초기버전. 복합 키와 연관관계 기능 부족
- JPA 2.0(JSR 317) 2009년: 대부분의 ORM 기능을 포함하고 JPA Criteria가 추가됨
- JPA 2.1(JSR 338) 2013년: 스토어드 프로시저 접근, 컨버터(Converter), 엔티티 그래프 기능 추가

JPA 를 사용해야 하는 이유

생산성
- SQL과 JDBC API 사용을 반복적으로 개발자가 직접 작성하지 않아도 됨
- DDL문을 자동 생성 기능 존재
- 데이터베이스 설계 중심의 패러다임을 객체 설계 중심으로 역전 가능
유지보수
- JPA가 JDBC API 코드 변경과 같은 일을 대신 처리해주므로 필드를 추가하거나 삭제해도 수정해야 할 코드가 줄어듦
- 유지보수해야 하는 코드의 수가 줄어듦
패러다임 불일치 해결
- 상속, 연관관계, 객체 그래프 탐색, 비교하기와 같은 패러다임의 불일치 문제 해결
성능
- 애플리케이션과 데이터베이스 사이에서 다양한 성능 최적화 기회 제공
- 같은 트랜잭션 안에서 같은 회원을 두 번 조회하는 코드의 일부분이 다음과 같을 때,
  JPA를 사용하면 회원을 조회하는 SELECT SQL을 한 번만 데이터베이스에 전달하고 두 번째는 조회한 회원 객체 재사용

String memberId = "helloId";
Member member1 = jpa.find(memberId);
Member member2 = jpa.find(memberId);

데이터 접근 추상화와 벤더 독립성
- 관계형 데이터베이스는 같은 기능도 벤더마다 사용법이 다름
- JPA는 애플리케이션이 특정 데이터베이스 기술에 종속되지 않도록 함
- 데이터베이스 변경 시 JPA에게 다른 데이터베이스를 사용한다고 알려주기만 하면 됨

QnA

✋ ORM 프레임워크를 사용하면 SQL과 데이터베이스는 잘 몰라도 괜찮은가?

️ ORM 프레임워크를 사용할 때 가장 중요한 일은 객체와 테이블을 매핑하는 것.

매핑을 올바르게 하기 위해서는 객체와 관계형 데이터베이스 양쪽을 모두 이해해야 함.

✋ 통계 쿼리처럼 매우 복잡한 SQL은 어떻게 하나?

️ JPA는 통계 쿼리 같이 복잡한 쿼리보다는 실시간 처리용 쿼리에 더 최적화 되어 있음

JPA가 제공하는 네이티브 SQL을 사용하거나, 마이바티스나 스프링의 JdbcTemplate 같은 SQL 매퍼 형태의 프레임워크 혼용하는 것도 좋은 방법

✋ 학습곡선이 높다고 하던데?

️ JPA를 사용하려면 객체와 관계형 데이터베이스를 어떻게 매핑하는지 학습한 후에 JPA의 핵심 개념들을 이해해야 함

JPA가 어려운 근본적인 이유는 ORM이 객체지향과 관계형 데이터베이스의 두 기둥 위에 있기 때문임.

이 둘의 기초가 부족하면 어려울 수 밖에 없음.

무럭무럭 성장일기

[JPA] 자바 ORM 표준 JPA 프로그래밍 #11

목차

개요

다대일

일대다

일대일 [1:1]

다대다 [N:N]

[PyCon] PyCon 2024 후기

소개

1일차

⌜S⌟SDLC - Integrating AI for Proactive Security in Python Development

FastAPI with Dependency Injector

SpringBoot 하던 사람이 Django 찍먹 해 봄 : 저의 적응기를 공유합니다

Django의 DB Connection과 Transaction 관리

거의 모든 파이썬 이용자를 위한 거대언어모델(LLM)의 활용

2일차

자동화된 파이썬 웹 프레임워크 API Schema 제작기: The long way around

Python ASGI 서버 구현기 with Pyo3

Python Backend에 클라우드를 더하다

오픈소스 프로젝트 - 코드 0줄부터 스타 1.3k까지

험난한 암호화폐 세상을 여행하려는 Python 유저들을 위한 안내서

[JPA] 자바 ORM 표준 JPA 프로그래밍 #10

목차

개요

단방향 연관관계

순수한 객체 연관관계 방법

테이블 연관관계

객체관계 매핑

연관관계 사용

양방향 연관관계

연관관계의 주인

양방향 연관관계 저장

양방향 연관관계의 주의점

정리

[JPA] 자바 ORM 표준 JPA 프로그래밍 #9

목차

@Column

@Column 생략

@Enumerated

@Temporal

@Lob

@Transient

@ Access

정리

[JPA] 자바 ORM 표준 JPA 프로그래밍 #8

목차

데이터베이스 기본 키 생성 전략

기본 키 직접 할당 전략

IDENTITY 전략

SEQUENCE 전략

@SequenceGenerator

TABLE 전략

@TableGenerator

AUTO 전략

기본 키 매핑 정리

권장하는 식별자 선택 전략

[JPA] 자바 ORM 표준 JPA 프로그래밍 #7

목차

개요

@Entity

@Table

다양한 매핑 사용

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

DDL 생성기능

[JPA] 자바 ORM 표준 JPA 프로그래밍 #6

목차

플러시

준영속

정리

[JPA] 자바 ORM 표준 JPA 프로그래밍 #5

목차

엔티티 매니저 팩토리와 엔티티 매니저

커넥션 획득 시기

영속성 컨텍스트란?

엔티티 생명주기

✅ 비영속

✅ 영속

✅ 준영속

✅ 삭제