제리 devlog

이번에는 엔티티 수정과정을 디버깅해보자. 엔티티를 수정하면 jpa에서는 dirty checking을 하고 update쿼리를 생성해준다. 정확히는 flush과정을 디버깅한다. 수정 과정 @Test @Transactional fun `update order`() { val order = Order(price = 1000) orderJpaRepository.save(order) order.price = 2000 orderJpaRepository.flush() } 먼저, order가 저장되는 부분에서 알고 넘어갈 부분이 있다. entitiy가 영속화되면 영속성 컨텍스트 내부에 entityEntryContext에 entityEntry가 저장된다. 이 entityEntry에는 loadState라는 것이 있다. 이 ..

이번에는 조회 과정을 디버깅해보자. 조회는 2가지 케이스로 나뉜다. 1. 영속성 컨텍스트에 존재하지 않아 db조회가 필요한 경우 2. 영속성 컨텍스트에 값이 존재해 1차 캐시를 반환하는 경우 (db 조회가 필요하지 않은 경우) 조회 과정 @Test @Transactional fun `find order`() { orderJpaRepository.findById(1L) } 먼저 find가 발생하면 DefaultLoadEventListener에 onLoad메서드가 호출된다. 이 메서드는 doOnLoad를 호출한다. 우선 doOnLoad는 session으로부터 EntityKey를 load 하는데, EntityKey는 entity의 id로 구성된 영속성 컨텍스트에서 엔티티를 구분해주는 key이다. 그리고 이어서..

이번 포스팅에서는 트랜잭션상에서 영속성 컨텍스트가 코드상으로 어떻게 사용되는지 확인해보려고 한다. 그전에 디버깅에 유용한 static 메서드를 소개한다. TransactionSynchronizationManager.getResourceMap() 이 메서드는 현재 스레드에 바인딩된 트랜잭션 자원을 확인해볼 수 있다. 예를 들어 아래 코드에서 이 메서드를 실행하면 트랜잭션 실행으로 entityMangerHolder와, datasource가 바인딩될 것을 알 수 있다. 저장 과정 persistanceContext는 entity를 저장하는 환경이다. entityManager를 사용해서 entity를 등록, 조회하는 경우 entityManger는 persistanceContext에 entity를 저장한다. 이제 ..

jpa를 사용해서 개발하다 보면 JpaRepository 인터페이스를 구현한 repository와 queryDsl를 사용하는 repoitory를 사용할 일이 잦다. 나는 간단한 조회, 엔티티 저장은 JpaRepository를 사용하고, 배치성 업데이트나 복잡한 쿼리 등은 querydsl을 사용하는 편이다. 그런데 JpaRepsitory, QuerydslRepository가 각각의 클래스로 분리되어 있다보니 서비스 계층에서 주입받아야 하는 클래스가 늘어났다. @Service class OrderService( private val orderJpaRepository: OrderJpaRepository, private val orderQuerydslRepository: OrderQuerydslRepositor..

JPA를 사용하면서 연관 관계를 갖는 엔티티를 만들어 주기위해 연관된 엔티티를 조회해오는 경우가 있다. 아래 게시글에 댓글을 의미하는 Comment엔티티가 있다. @Getter @NoArgsConstructor @Entity public class Comment { @Id @GeneratedValue(strategy = GenerationType.IDENTITY) private Long id; @ManyToOne(fetch = FetchType.LAZY) private Post post; @Lob private String content; @Builder public Comment(Post post, String content) { this.post = post; this.content = content..

일대일 매핑(1:1) 일대일 관계는 양쪽이 서로 하나의 관계만 가진다. 예를 들어 회원은 하나의 사물함만 사용하고 사물함도 하나의 회원에 의해서만 사용된다. 일대일 관계는 그 반대도 일대일 관계이다. 테이블 관계에서 일대다, 다대일은 항상 다(N)쪽이 외래 키를 가졌다. 반면에 일대일 관계는 주 테이블이나 대상 테이블 둘 중 어느 곳이나 외래 키를 가질 수 있다. 주 테이블에 외래키 주 객체가 대상 객체를 참조하는 것처럼 주 테이블에 외래 키를 설정한다. 외래 키를 객체 참조와 비슷하게 할 수 있어 객체지향 개발자들이 선호한다. 주 테이블이 외래 키를 가지고 있으므로 주 테이블만 확인해도 대상 테이블과 연관 관계를 알 수 있다. 대상 테이블에 외래 키 전통적인 데이터베이스 개발자들은 보통 대상 테이블에 ..

엔티티의 연관관계를 매핑할 때는 3가지를 고려해야한다. 다중성 단방향, 양방향 연관관계의 주인 먼저 두 엔티티가 일대일 관계일지 일대다 관계인지 다중성을 고려한다. 다음으로, 두 엔티티가 단방향과 양방향중 어떤 방식으로 참조하는지 결정한다. 마지막으로 양방향 관계라면 연관관계의 주인을 결정한다. 다중성 다대일(@ManyToOne) 일대다(@OneToMany) 일대일(@OneToOne) 다대다(@ManyToMany) 보통 다대일과 일대다 관계를 많이 사용하고 다대다 관계는 실무에서 거의 사용하지 않는다. 단방향, 양방향 테이블은 외래 키 하나로 조인을 하면 양방향으로 쿼리가 가능해서 방향의 개념이 없다. 반면, 객체는 참조용 필드가 있어 방향이 존재한다. 객체 관계에서 한 쪽만 참조하는 것을 단방향 관계라..

객체의 참조는 단방향이다. 반면 테이블에서의 join은 어느쪽이나 가능한다. member와 team의 관계는 다대일이다. 하나의 team에는 여러 member가 소속될 수 있다. 그렇기에 team의 객체에서는 컬렉션을 사용한다. 테이블의 연관관계는 team의 외래 키 하나로 양방향으로 조회할 수 있다. 양방향 객체의 연관관계를 만든다고해서 테이블에 새로 추가할 것은 없다. 양방향 연관관계 매핑 @Entity public class Member { @Id @Column(name = "MEMBER_ID") private String id; private String username; @ManyToOne @JoinColumn(name="TEAM_ID"); private Team team; //연관관계 설정 p..