쌓고 쌓다

회원과 사물함 같은 관계에서 일대일 연관관계 매핑을 사용할 수 있다. 테이블에서 주 테이블이든 대상 테이블이든 양 테이블중 한 곳에만 외래 키가 있다면 양쪽으로 조회할 수 있다. 외래 키를 주 테이블, 대상 테이블중 누가 관리할지 선택할 수 있다. 아래의 예시들은 멤버가 주 테이블이고 사물함이 대상 테이블이다. 단방향은 멤버에서 사물함을 참조하는 방향이다. 1. 주 테이블에 외래 키 주 테이블에 외래 키를 두면 주 객체가 대상 객체를 참조하듯이, 주 테이블에서 외래 키로 대상 테이블을 참조할 수 있다. 즉, 객체의 참조와 비슷하게 사용할 수 있다는 것이다. MEMBER 테이블에서 lokcer_id 외래 키로 Locker의 PK를 갖는다. 단방향 Member @Entity @Getter @Setter @N..

게시판이 여러 파일들을 업로드하여 관리하는 연관관계 매핑이 잘 안되어서 아주 흥미롭게 책을 펼쳐 정리해봤다. 연관관계 매핑시 3가지를 고려한다. 1. 다중성 다대일, 일대다, 일대일, 다대다가 있다. 2. 단방향, 양방향 테이블은 외래 키로 어떤 테이블에서든 두 테이블이 조인이 가능하니 양방향이 언제든 가능하다. 객체는 참조 필드를 가지는 객체만 조회가 가능하니, 한쪽만 있으면 단방향 양쪽에 있으면 양방향이다. 3. 연관관계 주인 DB는 외래 키 하나로 두 테이블이 연관관계를 맺을 수 있다. 이때 관리 포인트는 외래 키 하나로 한곳이다. 그런데 엔티티는 양방향으로 매핑했다면 관리 포인트가 두곳이 된다. A->B와 B->A. JPA는 관리 포인트를 한곳을 정해 외래 키를 관리하는데 이 한곳이 연관관계 주인..

게시판을 만들어보다보니 연관관계 부분을 공부할 필요가 느껴졌다! 파일 업로드 부분을 위해...! 그래서 JPA 책을 펼쳐 일부 읽고 조금 아하했다. 다음 챕터에 더 상세한 내용은 다음에 읽고 이해한 부분까지 정리한다. 엔티티는 다른 엔티티와의 관계를 맺는다. 선수는 팀과의 관계를 맺는 예시가 있다. 여기서 객체는 참조(주소)로 관계를 맺고, 테이블은 외래 키를 사용해 관계를 맺는다. 아래의 설명들을 보기전에 Member와 Team의 구조를 보자. Team (1) 테이블 CREATE TABLE team ( id VARCHAR(255) NOT NULL, name VARCHAR(255), PRIMARY KEY (id) ); (2) 클래스 @Entity @Getter @Setter @NoArgsConstruct..

문제의 발견 게시글 정렬의 방법으로 날짜, 댓글 개수를 구현했다. 이상하게 날짜순은 잘 정렬되어 나오는데 댓글 개수로 정렬시 게시글(레코드)의 누락과 중복이 발생했다. JPA의 Paging은 ORDER BY와 Limit를 사용한다. 문제 설명 아래의 결과를 먼저 보자. 게시글에 달린 댓글 개수인 comment_cnt를 내림차순으로 출력한다. limit를 통해 보일 레코드를 조절했다. 네모 박스친 레코드 title이 "수정제목fsfs"인 레코드가 중복되어 나타난다. 사실 MySQL의 버그인가? 생각이 들었다. 내가 버그를 찾은걸까? ㅎㅎ 결과적으로 말하면 버그가 아니다. ORDER BY에는 문제가 없다. 크기순으로 정렬되어 있지 않은가. 즉, 고유한 순서를 보장해주지 않지만 정렬은 보장해줬다. 그럼 LIM..

현재 내 Poster(게시글) 엔티티의 댓글 개수를 위한 commentCnt 변수가 있다. DB에 만든 poster 테이블의 스키마다. 여기서 보면 댓글 개수를 위해 commentCnt 컬럼을 만들었다. 저번에도 이 문제로 아하!하고 넘어갔는데 또 이런 문제가 발생했다. JPA에서 SELECT시 DB에 컬럼명을 comment_cnt로 조회를한다. 나는 필드명을 commentCnt로 했고 기본값으로 필드명과 동일하게 매핑이 될 줄 알았다...! 하지만 자바의 카멜 표기법은 DB에서는 _(언더바)로 변환된다. 또한 DB에서는 컬럼명을 commentCnt가 아닌 comment_cnt로 표기하는게 국룰이다! 해결하기위해 아래의 방법을 수행하여 정확히 매핑하자. 1. DB의 commentCnt 컬럼명 변경 ALT..

roleType VS role_type 자바는 단어와 단어 구별을 roleType 같은 카멜(Camel) 표기법을 사용한다. 데이터베이스는 관례상 role_type과 같은 언더스코어(_)를 사용한다. 아래와 같이 필드명을 "roleType"를 했다면 DB에 매핑되는 컬럼명은 "role_type"이 된다. @Column(name="role_type") String roleType 게시판 만들며 왜 이렇게 매핑이되나 싶었는데 궁금증 해결...! 데이터베이스 스키마 자동 생성 JPA는 엔티티의 매핑 정보를 통해 어떤 컬럼을 사용하는지 알 수 있으므로 맞는 방언으로 데이터베이스 스키마 자동 생성한다. ( 애플리케이션 실행 시점에 생성함 ) 옵션 설명 create 기존 테이블을 삭제하고 새로 생성 DROP + C..

플러시(flush()) 플러시는 영속성 컨텍스트의 변경 내용을 DB에 반영한다. 절대 보관된 엔티티를 지우는 작업이 아니라 DB에 동기화하는 동작이다. 플러시 실행시 동작 1. 변경 감지가 동작하여 영속성 컨텍스트에 있는 모든 엔티티를 스냅샷과 비교해 수정된 엔티티를 찾는다. 2. 수정된 엔티티는 수정 쿼리를 만들어 쓰지 지연 SQL 저장소에 저장한다. 3. 쓰기 지연 SQL 저장소의 쿼리를 DB에 전송한다. (등록, 수정, 삭제 쿼리) 플러시 방법 1. em.flush()를 직접 호출 2. 트랜잭션 커밋 시 플러시 자동 호출 3. JPQL 쿼리 실행 시 플러시 자동 호출 DB에 변경 내용을 SQL로 보내지 않고 트랜잭션 커밋만하면 DB에 반영되지 않는다. 그래서 트랜잭션이 종료하기전에 JPA는 플러시를..

Entity ManagerFactory, Entity Manager 1. 엔티티 매니저 팩토리의 생성 비용은 매우 크므로 하나만 만들어 애플리케이션 전체에서 공유한다. 2. 엔티티 매니저 팩토리는 여러 스레드가 동시에 접근해도 안전하며 다른 스레드간에 공유가 가능하다, 3. 엔티티 매니저는 동시에 접근하면 동시성 문제가 발생하므로 스레드가 공유가 불가능하다. 4. 엔티티 매니저는 DB 연결이 꼭 필요한 시점까지 커넥션을 얻지 않는다. 보통 트랜잭션 시작할때 획득한다. 영속성 컨텍스트 '엔티티를 영구 저장하는 환경'이라는 뜻이다. 여러 엔티티 매니저가 같은 영속성 컨텍스트에 접근할 수 있지만 현재는 하나에 하나의 영속성 컨텍스트가 생긴다고 알자. 엔티티의 생명주기 1. 비영속: 영속성 컨텍스트와 전혀 관계..